OOP设计原则

1、单一职责原则

一个类或者模块，应该仅有一个引起其变化的原因。如果一个类承担的职责过多就等于将这些职责耦合在一起，一个职责的变化就有可能影响其他职责的能力。
缺点：会造成类的数量增多。
破坏了封装的原则：若将目标类中将含有私有数据访问逻辑的业务行为分离出去，则会造成外部类或方法访问目标类的私有数据，破坏封装的特性。
例子：比如在我们日常的使用手机银行支付的场景中，它需要用户登陆系统并且用户登陆成功后才能进行支付的业务。若我们将这些业务都放在System类中时，那么这些业务其中任何一个需求发生变化时，我们都需要来修改System类 ，这将会使得系统的稳定性降低。我们完全可以将登陆行为封装在User类中，将支付行为封装在Pay类中，这样使得每一个类仅有一个引起其变化的原因，进而使得系统稳定性提高。

2、开放封闭原则

是说软件实体（类、模块、函数）应该可以扩展，但不可以修改。其特征为：对于扩展是开放的，对于更改是封闭的。
例子：比如我们经常遇到让我们去实现一个简单的计算器程序。我们给出了Operation类，这个类实现了加、减、乘、除后等简单的运算，之后老板又提出让我们实现幂运算的操作，接着我们需要去修改Operation。过了不久老板又提出实现开方的运算，那有需要我们去修改Operation类。那么每当boss提出一个需求时，我们就得不断的去修改Operation类，着就违背了开放封闭的原则。一个可行的方案是，我们定义Opeation接口，在这个接口中给出getResult方法。让不同的运算规则去实现该接口，这样每当需求来时，我们不再去修改原先的Operation类，而是给该运算规则生成新的类，该类实现Operation接口就行。

3、依赖倒转原则

高层模块不应该依赖低层模块，两个都应该依赖抽象。
抽象不依赖细节，细节应该依赖抽象。
换句话说就是面向接口编程。
比如，我们在业务场景里需要调用支付订单时，我们在业务中直接使用具体的支付方式（比如：银行卡）。但在之后我们需要添加新的支付方式（如：微信支付、支付宝支付），那么我们就需要重新写我们的业务逻辑，这违背的依赖倒置原则和开放封闭原则。我们可以将支付方式抽象出来作为一个接口，我们在高层调用时，直接调用接口而不用掉具体的支付方式。
例子：还是我们第一个例子中的支付行为的例子，我们在Pay类中定义了pay方法，但是在支付时有中不同的方法，比如使用支付宝、微信、银行卡等方式。如果pay方法调用的支付的实现类，那么每次在有新的支付方法产生时，我们就不得不去修改我们的pay方法，以添加新的支付方式，这与开闭原则相违背。一个可行的方案是。pay中调用的是支付方式的接口方法，在使用不同的支付方式时，我们只需要将实现了支付方式接口的实现类传入即可。

4、里氏代换原则

子类型能够替换掉他们的父类型。
例子：就是依赖倒置原则中的将实现了支付接口的实现类传入，这就是里氏代换原则

5、接口隔离原则

如果某个接口不是内聚的，就应该按照业务分组，并将分组后的业务行为通过隔离的接口单独定义。
例子：比如我们定义一个猫科的接口Felidae，接口中有两个方法isFelidae()判断是猫科动物和canMeow()可以喵喵喵喵叫的两个方法。当对于实现了该接口老虎Tiger类和猫Cat类来说，显然对于Tiger类来说canMeow()是多余的行为。那么为了解决上述问题，我们可以将上述接口Felidae接口进行分组，分为IsFelidae和CanMeow两个接口。让老虎Tiger去实现IsFelidae该接口，而猫Cat去实现IsFelidae和CanMeow两个接口。
缺点：如上所述，会出现接口数量过多。代码的抽象度高但可读性差。