SOLID原则

2017/05/10 SOLID原则

SOLID

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

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

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

Single Responsibility Principle

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

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

img

Open / Closed Principle

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

img

Liskov Substitution Principle

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

img

Dependency Inversion Principle

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

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

img

Interface Segregation Principle

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

img

Search

    Table of Contents