[翻译]每个开发人员都应该知道面向对象设计的原则

翻译SOLID Principles every Developer Should Know

面向对象编程为软件开发带来了新的模式。

这使开发人员能够将具有相同用途或功能的数据组合在一个类中，来处理单一的问题，而不用管整个应用程序。

但是，这种面向对象的编程还是会让开发者写出混淆或不好维护的程序。

因此，罗伯特·c·马丁(Robert C. Martin)制定了五项准则。这五个准则/原则可以让开发人员轻松的写出可读性和可维护性高的程序。

这五个原则被称为S.O.L.I.D原则(首字母缩写是迈克尔·费瑟[Michael Feathers]提出的)。

  • S: 单一职责原则
  • O: 开闭原则原则
  • L: 里氏替换原则
  • I: 接口隔离原则
  • D: 依赖反转原则

我们将在下面详细讨论它们。

提示
本文中的大多数示例，可能不足以说明实际情况或不适用于实际需求。这完全取决于您自己的设计和用例。最重要的是理解并知道如何应用/遵循这些原则。

提示:
SOLID原则是为构建模块化、封装、可扩展和可组合的组件而设计的。Bit是将这一原则付诸实践的有力工具：它帮助您轻松地隔离、共享和管理团队中不同项目中的此类组件。试试看!

单一职责原则

_“……你只有一份工作”——《雷神3:诸神黄昏》中洛基和斯克雷斯的合作
一个类应该只负责一件事情

一个类应该只负责一件事。如果一个类有多个职责，它就会耦合。对一个职责的更改会导致对另一个职责的更改。

  • 提示: 这一原则不仅适用于类，而且也适用于软件组件和微服务架构。

例如，思考这样的设计：

class Animal {  
    constructor(name: string){ }  
    getAnimalName() { }  
    saveAnimal(a: Animal) { }  
}

Animal类违反了单一职责原则（SRP）。

它怎么违反SRP的?

SRP声明类应该只有一个职责，在这个类里，我们可以看到有两个职责：Animal数据管理和动物属性管理。这个类的构造函数和getAnimalName方法管理Animal的属性，而saveAnimal方法管理Animal的数据存储。

这个设计在以后会引起什么样的问题?

如果应用的更改影响到了数据库的操作，那么使用Animal属性的类必须做相应的修改。

这个系统缺乏弹性，就像多米诺骨牌效应，触摸一张牌就会影响到其他所有的牌。

为了符合SRP，我们创建了另一个类，它的职责是存储animal到数据库:

class Animal {  
    constructor(name: string){ }  
    getAnimalName() { }  
}

class AnimalDB {  
    getAnimal(a: Animal) { }  
    saveAnimal(a: Animal) { }  
}

当我们在设计类时，应该把特性相关的放在一起。同时，我们应该把特性不同的分开。-史蒂夫芬頓

遵循这些原则会让我们的应用程序变得高内聚。

开闭原则原则

软件实体(类、模块、函数)应该是可以扩展的，而不是修改。

继续我们的Animal类。

class Animal {  
    constructor(name: string){ }  
    getAnimalName() { }  
}

我们想要遍历动物列表并设置它们的声音。

...  
const animals: Array<Animal> = [  
    new Animal('lion'),  
    new Animal('mouse')  
];

function AnimalSound(a: Array<Animal>) {  
    for(int i = 0; i <= a.length; i++) {  
        if(a[i].name == 'lion')  
            log('roar');  
        if(a[i].name == 'mouse')  
            log('squeak');  
    }  
}  
AnimalSound(animals);

AnimalSound方法不符合开闭原则，因为有新动物出现时，需要修改AnimalSound方法。

如果我们添加一个新的动物，蛇：

...  
const animals: Array<Animal> = [  
    new Animal('lion'),  
    new Animal('mouse'),  
    new Animal('snake')  
]  
...

我们必须修改AnimalSound方法：

...  
function AnimalSound(a: Array<Animal>) {  
    for(int i = 0; i <= a.length; i++) {  
        if(a[i].name == 'lion')  
            log('roar');  
        if(a[i].name == 'mouse')  
            log('squeak');  
        if(a[i].name == 'snake')  
            log('hiss');  
    }  
}

AnimalSound(animals);

对于每个新的animal，就需要在AnimalSound方法中添加新的逻辑。这是一个相当简单的例子。应用复杂时，每当你新增一个动物时，AnimalSound方法中if语句就会不停的重复。

我们如何使它(AnimalSound方法)遵循OCP?

class Animal {  
        makeSound();  
        ...  
}

class Lion extends Animal {  
    makeSound() {  
        return 'roar';  
    }  
}

class Squirrel extends Animal {  
    makeSound() {  
        return 'squeak';  
    }  
}  
class Snake extends Animal {  
    makeSound() {  
        return 'hiss';  
    }  
}

...  
function AnimalSound(a: Array<Animal>) {  
    for(int i = 0; i <= a.length; i++) {  
        log(a[i].makeSound());  
    }  
}  
AnimalSound(animals);

现在，Animal有一个makeSound方法。我们让每个animal都继承Animal类，并且实现makeSound方法。

让每个animal实现自己的makeSound方法。AnimalSound方法遍历animal数组，然后调用每个animal的makeSound方法即可。

现在，如果我们增加一个新的animal，不需要去更改AnimalSound方法，只需要将新的animal添加到animal数组中。

AnimalSound现在遵循了OCP原则。

另外一个例子：

假设你有一家商店，给你喜欢的顾客打20%的折扣：

class Discount {  
    giveDiscount() {  
        return this.price * 0.2  
    }  
}

当你决定为VIP顾客提供40%的折扣时。你可以这样修改类：

class Discount {  
    giveDiscount() {  
        if(this.customer == 'fav') {  
            return this.price * 0.2;  
        }  
        if(this.customer == 'vip') {  
            return this.price * 0.4;  
        }  
    }  
}

这违背了OCP原则。OCP不允许这样做。如果我们想给不同类型的顾客不同的折扣，giveDiscount方法中将会增加新的逻辑。

为了让其遵循OCP原则，我们将添加一个新的类，让它继承Discount类。让我们来一起实现它：

class VIPDiscount: Discount {  
    getDiscount() {  
        return super.getDiscount() * 2;  
    }  
}

如果你想给超级VIP客户80%的折扣，应该是这样的:

class SuperVIPDiscount: VIPDiscount {  
    getDiscount() {  
        return super.getDiscount() * 2;  
    }  
}

这就是拓展而不是修改。

里氏替换原则

子类必须能够替换成它们的基类

这个原则的目的是确保子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。如果发现代码在检查类的类型，那么它一定违反了这个原则。

让我们以Animal类为例。

...  
function AnimalLegCount(a: Array<Animal>) {  
    for(int i = 0; i <= a.length; i++) {  
        if(typeof a[i] == Lion)  
            log(LionLegCount(a\[i\]));  
        if(typeof a[i] == Mouse)  
            log(MouseLegCount(a\[i\]));  
        if(typeof a[i] == Snake)  
            log(SnakeLegCount(a\[i\]));  
    }  
}  
AnimalLegCount(animals);

这违反了LSP原则(以及OCP原则)。它必须知道每种Animal类型，并调用相应的leg-counting方法。

对于每一个新创建的animal，必须修改函数以接受新animal。

...  
class Pigeon extends Animal {  
          
}

const animals[]: Array<Animal> = [  
    ...,  
    new Pigeon();  
]

function AnimalLegCount(a: Array<Animal>) {  
    for(int i = 0; i <= a.length; i++) {  
        if(typeof a[i] == Lion)  
            log(LionLegCount(a[i]));  
        if(typeof a[i] == Mouse)  
            log(MouseLegCount(a[i]));  
         if(typeof a[i] == Snake)  
            log(SnakeLegCount(a[i]));  
        if(typeof a[i] == Pigeon)  
            log(PigeonLegCount(a[i]));  
    }  
}  
AnimalLegCount(animals);

为了使该函数遵循LSP原则，我们来看下Steve Fenton假设的LSP要求:

  • 如果超类(动物)具有接受超类类型(Animal)参数的方法。它的子类(Animal类型)应该接受超类类型(Animal类型)或子类类型(Pigeon类型)作为参数。

  • 如果超类返回一个超类的类型（Animal）。它的子类应该返回一个超类类型（Animal类型）或子类类型（Pigeon）；

现在，我们可以重新实现下AnimalLegCount方法：

function AnimalLegCount(a: Array<Animal>) {  
    for(let i = 0; i <= a.length; i++) {  
        a[i].LegCount();  
    }  
}  
AnimalLegCount(animals);

AnimalLegCount方法不用关心参数Animal的类型，它只是去调用LegCount方法。它只要求参数必须为Animal类型，要么是Animal类，要么是它的子类。

现在，Animal类必须实现或者定义一个LegCount方法：

class Animal {  
    ...  
    LegCount();  
}

而它的子类必须实现LegCount方法：

...  
class Lion extends Animal{  
    ...  
    LegCount() {  
        ...  
    }  
}  
...

当在AnimalLegCount方法中调用时，会返回lion的腿数。

AnimalLegCount方法在不需要知道Animal类型的情况下，只调用每个Animal的LegCount方法，来获得Animal的腿数，因为根据约定，Animal的子类实现了LegCount方法。

接口隔离原则

创建特定于客户端的细粒度接口

不强制客户端依赖他们不使用的接口。

这个原则避免了大接口的缺陷。

让我们一起来看IShape接口：

interface IShape {  
    drawCircle();  
    drawSquare();  
    drawRectangle();  
}

这个接口绘制正方形、圆形和矩形。实现IShape接口的类必须定义drawCircle, drawSquare, drawRectangle方法。

class Circle implements IShape {  
    drawCircle(){  
        ...  
    }

    drawSquare(){  
        ...  
    }

    drawRectangle(){  
        ...  
    }      
}

class Square implements IShape {  
    drawCircle(){  
        ...  
    }

    drawSquare(){  
        ...  
    }

    drawRectangle(){  
        ...  
    }      
}

class Rectangle implements IShape {  
    drawCircle(){  
        ...  
    }

    drawSquare(){  
        ...  
    }

    drawRectangle(){  
        ...  
    }      
}

上面的代码非常有趣。Rectangle类实现了它不使用的方法(drawCircle和drawSquare) ，同样，Square类实现了drawCircle和drawRectangle方法，Square类实现了drawSquare和drawSquare方法。

如果我们需要在IShape接口中添加另外一个方法drawTriangle，

interface IShape {  
    drawCircle();  
    drawSquare();  
    drawRectangle();  
    drawTriangle();  
}

类必须实现新的方法，否则会抛出错误。

我们可以看到，不可能实现一个形状类，它可以画圆，但是不能画矩形，正方形或三角形。我们可以实现一些方法来抛出一个错误，表明操作无法执行。

ISP反对这种IShape接口的设计。客户端（这里指Rectangle、Circle和Square类）不应该被强制依赖他们不需要或不用的方法。并且，ISP声明接口应该只负责一个任务（就像SRP原则），任何额外的行为都应该抽象到另一个接口上。

这里，我们的IShape接口中的多个操作，应该由别的接口独立负责。

为了让我们的IShape接口遵循ISP原则，我们将不同的操作隔离到不同的接口上：

interface IShape {  
    draw();  
}

interface ICircle {  
    drawCircle();  
}

interface ISquare {  
    drawSquare();  
}

interface IRectangle {  
    drawRectangle();  
}

interface ITriangle {  
    drawTriangle();  
}

class Circle implements ICircle {  
    drawCircle() {  
        ...  
    }  
}

class Square implements ISquare {  
    drawSquare() {  
        ...  
    }  
}

class Rectangle implements IRectangle {  
    drawRectangle() {  
        ...  
    }      
}

class Triangle implements ITriangle {  
    drawTriangle() {  
        ...  
    }  
}  
class CustomShape implements IShape {  
   draw(){  
      ...  
   }  
}

ICircle接口只绘制圆，IShape接口绘制任意形状，ISquare接口只绘制正方形，IRectangle接口只绘制矩形。

或者

类（Circle、Rectangle、Square、Triangle等）只继承IShape接口，并且实现它们自己的绘画行为。

class Circle implements IShape {  
    draw(){  
        ...  
    }  
}  
  
class Triangle implements IShape {  
    draw(){  
        ...  
    }  
}  
  
class Square implements IShape {  
    draw(){  
        ...  
    }  
}  
  
class Rectangle implements IShape {  
    draw(){  
        ...  
    }  
}

然后，我们可以使用I-接口创建特定的形状，如半圆、直角三角形、等边三角形、钝边矩形等。

依赖倒置原则

依赖关系应该是抽象的，而不是具体的。

A. 高级模块不应该依赖于低级模块。两者都应该依赖于抽象。

B. 抽象不应该依赖于细节。细节应该依赖于抽象。

在软件开发中，我们的应用程序最终主要由模块组成。当这种情况出现时，我们必须使用依赖注入来解决。高级组件依赖于低级组件发挥作用。

class XMLHttpService extends XMLHttpRequestService {}

class Http {  
    constructor(private xmlhttpService: XMLHttpService) { }  
    get(url: string , options: any) {  
        this.xmlhttpService.request(url,'GET');  
    }

    post() {  
        this.xmlhttpService.request(url,'POST');  
    }  
    ...  
}

这里，Http是高级组件，而HttpService是低级组件。这种设计违反了DIP A：高级模块不应该依赖于低级模块。它应该依赖它的抽象。

这个Http类被强制依赖XMLHttpService类。如果我们要更改Http连接服务，可能需要通过Nodejs连接到互联网，或者模拟http服务。我们将必须修改每个Http实例，这违背了OCP原则。

Http类应该更少的去关心你用的Http服务类型。
让我们来实现一个Connection接口：

interface Connection {  
    request(url: string, opts:any);  
}

Connection这个接口有一个request方法。有了这个接口，我们可以给我们的Http类传入一个Connection类型的参数：

class Http {  
    constructor(private httpConnection: Connection) { }

    get(url: string , options: any) {  
        this.httpConnection.request(url,'GET');  
    }

    post() {  
        this.httpConnection.request(url,'POST');  
    }  
    ...  
}

现在，不管给Http类传入什么类型的Http服务连接参数，在不用关心网络连接类型的情况下，连接到网络也是很容易的。

我们可以重新实现下我们的XMLHttpService类，来实现Connection接口：

class XMLHttpService implements Connection {  
    const xhr = new XMLHttpRequest();  
    ...  
    request(url: string, opts:any) {  
        xhr.open();  
        xhr.send();  
    }  
}

我们可以创建许多Http Connection类型，并将其传递给我们的Http类，而无需担心错误。

class NodeHttpService implements Connection {  
    request(url: string, opts:any) {  
        ...  
    }  
}

class MockHttpService implements Connection {  
    request(url: string, opts:any) {  
        ...  
    }      
}

现在，我们可以看到高级模块和低级模块都依赖于抽象。Http类（高级模块）依赖于Connection接口（抽象），而Http服务类型（低级模块）也依赖Connection接口（抽象）。

此外，DIP原则会强制我们遵循里氏替换原则：Connection类型 Node-XML-MockHttpService可以替换它们的父类型连接。

结论

我们在这里介绍了每个软件开发人员都必须遵守的五个原则。遵循所有这些原则一开始可能会令人畏惧，但是随着不断的实践和坚持，它将成为我们的一部分，并对应用程序的维护产生巨大的影响。

关于这些原则，如果你觉得有需要增加，纠正或删除的地方，请在下面的评论区留言，我非常乐意与您探讨！

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 159,569评论 4赞 363
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,499评论 1赞 294
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 109,271评论 0赞 244
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 44,087评论 0赞 209
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,474评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,670评论 1赞 222
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,911评论 2赞 313
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,636评论 0赞 202
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,397评论 1赞 246
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,607评论 2赞 246
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,093评论 1赞 261
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,418评论 2赞 254
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,074评论 3赞 237
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,092评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,865评论 0赞 196
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,726评论 2赞 276
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,627评论 2赞 270