设计原则

代码的质量判定：

1，可阅读性（命名和注释）

2，可扩展性

3，可维护性

4，可测试性

面向对象设计原则：

它是设计和编码的指导思想，通过设计原则可以提升代码的扩展性和灵活性。

1，单一职责原则（SRP）：一个类只负责一个功能领域中的相应职责，或者定义为，就一个类而言，应该只有一个引起它变化的原因。

单一职责原则是实现高内聚，低耦合的知道方针，它是最简单又是最难运用的原则，他需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关相互实践经验。

单一职责原则告诉我们：一个类不能太“大”，职责太多，在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责越多，就相当于这些职责耦合到一起，但其中一个职责变化了，可能影响其他职责的运作，因此要讲这些职责进行分离，将不同的职责封装到不同的类中，如果多个职责总是同时发生变化这可以将他们封装成同一个类中“。

2，开闭原则（OCP）；一个软件实体（可以是一个模块，或者一个独立的类）应该对扩展开放，对修改关闭，即软件实体应当尽量不在修改原有代码的情况下进行扩展。

任何软件都需要面临一个很重要的问题，即需求会随时改变，当软件系统需要面临新的需求是，我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计原则，那么可以非常方便的对系统进行扩展，而且在扩展是无需修改现有代码，是得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计瞒住开闭原则的软件系统可以便得越来越重要

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。我们通过接口，抽象类可以定义系统的抽象层，再通过具体类进行扩展，如果需要修改系统的行为，无需对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

3，里氏替换原则（LSP）：所以引用超类（父类）的地方必须能透明的使用子类的对象。

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法

子类中可以增加自己的特有的扩展方法

当子类的方法要重载父类的方法时，方法的前置条件（及方法的参数）要比父类方法的参数更宽泛。

当子类的方法实现父类的抽象方法时，方法的后置条件（方法返回值）要比父类更严格。

里氏替换原则告诉我们尽量不要重写父类已经实现的方法，可以通过增加新的方法或者实现接口扩展子类的功能。

4，依赖倒置原则（DIP）：抽象不应该依赖于细节，细节应当依赖于抽象，换言之，要针对接口编程，而不是针对具体实现编程。

依赖倒置原则要求我们在程序代码中传递参数或者关联关系是，尽量应用层次高的抽象层类，既使用接口和抽象类进行变量类声明，而不要用具体类来做这些事情，为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过得方法。而不要给出多余的方法，否则将无法调用到子类中增加的方法。

在实现依赖倒置原则时，需要针对抽象层编程，而将具体类的对象通过依赖注入（DI）的方法注入到其他对象中。

5，接口隔离原则（ISP）：使用多个专门的接口，而不是使用单一的总接口，既客户端不应该依赖那些它不需要的接口。

根据接口隔离原则，但一个接口太大时候，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需要知道与之相关的方法即可。每一个接口应当承担一种相对独立的职责。在使用接口隔离原则时候，我们需要注意控制接口的颗粒度，接口不能太小，如果太小会导致系统中的接口泛滥。不利于维护，接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便，一般而言，接口中仅包含为每一功能的定制方法即可，不应该强迫客户端依赖于那些他们的方法。

6，迪米特法则（LOD）：一个软件实体应当尽可能减少与其他软件实体发生相互关系。

如果一个系统符合低密特法则，那么当其中某一个模块发生修改时候，就会尽量少的影响其他模块，扩展会相对容易，这是对软件实体之间的通信的限制。

迪米特法则要求限制软件实体之间的通信的宽度和深度。迪米特法则可降低系统的耦合度，让类与类之间保持松散的耦合关系。

六个设计原则之间是存在相互关系只是侧重点不一样，在软件设计开发时候，需要综合考虑这些原则，最终得到一个平衡。