SOLID 原则

SOLID

        作为开篇，这篇文章主要来介绍SOLID原则。 SOLID 原则提供了五条指导思想，如果我们遵从它们的话， 将可以显著的提升我们软件可维护性。

        SOLID原则是针对面向对象编程和设计的五大依赖关系管理。SOLID首字母缩写词，是由Robert Cecil Martin （也被称为 “Bob叔叔” ）提出的。每个字母代表另外一个三个字母的首字母缩写， 用来描述一个原则。

        当我们处理在一份依赖关系很糟糕的软件时，代码可能会变得僵化，脆弱，难以重用。我们势必会改变现有功能或添加新的功能，而僵化的代码会让这变得举步维艰。脆弱的代码很容易造成bug的产生，常见的情况是你一个区域的代码发生变化时候，造成你其他模块出现bug。如果你遵从SOLID原则，那么你可以编写出更灵活更健壮的代码，并且具有更高的重用性。

Single Responsibility Principle

        单一职责原则（SRP）声明：“引起类变化的因素永远不要多余一个”。这意味着你需要设计你的类，使得每个类都只有一个目的。这并不意味着每个类应该只有一个方法，而是说类中所有的方法都要与该类的主要功能相关。那些有多个职责的类，应该被分成新的类。

        当一个类具有了多项职责，它需要被更改的可能性也随之增加。每次一个类的修改也会使得bug产生的风险增加。而通过集中职责与一点会使得风险被有效的限制。

Open / Closed Principle

        开闭原则（OCP）指出：“软件实体（classes, modules, functions etc.）应该对拓展开放，对修改关闭”。该规则的“封闭”部分规定，一旦模块被开发和测试完成，代码被修改的原因应该只有修复bug这一种情况。 “开放”部分说，您应该能够扩展现有代码（而不是修改之前的代码）以引入新功能。与SRP一样，该原理通过限制对现有代码的更改来降低引入新错误的风险。

Liskov Substitution Principle

      里氏替换原则（LSP）声明：“所有引用基类的地方必须能透明地使用其子类的对象”。如果你创建了一个给定类型关系的类，那么你应该可以提供该类型或任意该类型子类的对象，而不会出现意外的结果，并且没有依赖的类知道被提供依赖类的确切类型。如果必须检查依赖关系的类型，以便可以根据类型修改行为，或者如果子类型产生意外的规则或副作用，则代码可能变得更加复杂，僵化和脆弱。

Dependency Inversion Principle 

        依赖倒置原则（DIP）有两条声明。第一个是高级模块不应该依赖于低级模块。两者都应该依赖于抽象。第二部分规则是抽象不应该依赖于细节。细节应该依赖于抽象。

        DIP主要涉及到应用中层次化的概念，其中较低级别的模块处理细节的功能，较高级别的模块使用较低级别的类来实现更大的任务。该原则规定了在类之间存在依赖关系的情况下，应使用抽象（如接口）来定义它们，而不是直接引用类。 这减少了由较低级别模块的变化导致的错误，导致较高层的错误。 DIP经常在依赖注入中被使用。

      Interface Segregation Principle  

接口分离原则（ISP）指出：“客户端不应该强制依赖那些他们没有使用到的接口”。这个规则意味着当一个类依赖另一个类时，接口中可以被依赖类显示的成员的数量应该被最小化。通常当您创建一个具有大量方法和属性的类时，该类将被其他类使用，并且只访问其一个或两个成员。随着他们意识到的成员数量的增加，这些类更加紧密地耦合在一起。当您遵循ISP时，大类实现了多个更小的接口，根据用途对功能进行分组。依赖关系与那些相关联用于松耦合，增加健壮性，灵活性以及可复用性。