Keep It Simple and Stupid
KISS原则就是保持代码可读和可维护
代码足够简单，也就意味着容易读懂，bug比较难隐藏。即便出现bug,修复也比较简单
如何写出满足 KISS 原则的代码
关于如何写出满足KISS 原则的代码，前面已经讲了一些方法，这里总结一下。
1)慎重使用过于复杂的技术来实现代码，如复杂的正则表达式、编程语言中过于高级的 语法等。
2)不要“重复造轮子”,首先考虑使用已有类库。根据作者的经验，如果自己实现类库，那么产生bug的概率更高，维护成本也更高。
3)不要过度优化。尽量避免使用一些“奇技淫巧”(如使用位运算代替算术运算、使用复杂的条件语句代替if-else等)来优化代码。
单一职责原则 (Single Responsibility Principle,SRP) 的描述：
一个类或模块只负责完成一个职责(或功能)(A class or module should have a single responsibility)。
注意，单一职责原则描述的对象有两个：类 (class) 和模块 (module)。
单一职责原则是指一个类负责完成一个职责或功能。
也就是说，我们不要设计大而全的 类，要设计粒度小、功能单一的类。
换个角度来讲，如果一个类包含两个或两个以上业务不相 干的功能，
那么我们就可以认为它的职责不够单一，应该将其拆分成多个粒度更小的功能单一 的类。
例如，某类既包含对订单的一些操作，又包含对用户的一些操作。而订单和用户是两个独
立的业务领域模型，将两个不相干的功能放到同一个类中，就违反了单一职责原则。
为了满足 单一职责原则，我们需要将这个类拆分成粒度更小的功能单一的两个类：订单类和用户类。
开闭原则 (Open Closed Principle,OCP),又称为 “对扩展开放、对修改关闭”原则。
开闭原则既是 SOLID 原则中最难理解、最难掌握的，又是最有用的。
如何理解“对扩展开放、对修改关闭”
添加一个新功能时应该是在已有代码基础上扩展代码(新增模块、 类和方法等),而非修改已有代码(修改模块、类和方法等)。
>>>多态就是对开闭原则，最好的诠释<<<
如何在代码中灵活应用开闭原则？
一：重复的代码可以抽成方法
二：重复的代码可以抽成抽象父类
二：思考是否需要定义接口(接口的使用熟练度需要时间的积累)
里氏替换原则 (Liskov Substitution Principle,LSP)
(使用父类对象的函数可以在不了解子类的情况下替换为使用子类对象)
我们将里氏替换原则描述为：
子类对象 (object of subtype/derived class)
能够替换到程序 (program) 中父类对象 (object of base/parent class)出现的任何地方，
并且保证程序原有的逻辑行为 (behavior) 不变和正确性不被破坏。
大白话就是，子类覆写父类的方法后，不应该做不符合父类方法本意的事情
接口隔离原则（Interface Segregation Principle，ISP）
接口隔离原则指导我们在设计接口时应该保持接口的粒度小、高内聚、不耦合，避免定义大而全的接口。
接口隔离原则与单一职责原则有些相似，接口隔离原则提供了一种判断接口是否职责单一的方法:
依赖反转原则主要用来指导框架的设计
举例子：
一：我们写的动物类，应不应该关心某个具体子类如Cat类的方法？不应该，因为抽象不要依赖具体实现细节
应该是Cat作为具体实现类，依赖抽象类动物类。具体实现细节依赖抽象。(继承、抽象的知识点)
二：一个Java支付系统分为 用户-->订单-->对接银行 三个模块
用户是订单的上层，用户模块需要感知订单模块的细节吗？不需要，直接调用订单模块的方法就够了
订单模块是用户模块的下层，订单模块需要感知用户模块的细节吗？需要，不然订单模块就没法拿到需要的信息
订单-->对接银行的上下层关系同理