现实生活中的SOLID原则

作者：Erik Dietrich

译者：java达人

来源：https://www.infragistics.com/community/blogs/erikdietrich/archive/2016/01/26/the-solid-principles-in-real-life.aspx（点击文末阅读原文前往）

(如有侵权，请联系删除)

S是单一职责原则

单一责任原则（SRP）是说一个类或模块只能做一件事。但这是一种主观的判断，所以我们通过启发式的方法深化该原则，规定类或模块只有一个改变的原因。

举一个反例，某一个类它打开与数据库的连接，拉出一些表数据，并将数据写入文件。这个类有多个改变的可能：采用新的数据库，修改文件输出格式，决定使用ORM等。从单一职责角度来看，这个类做得太多了。

在日常生活中，您偶尔会在湖边城镇看到一些“鸭子”车。它们是可以在街道合法行驶，并且在水中也可以行驶，所以在鸭子车上旅游为您提供独特和超现实的体验，一辆汽车，到达水面也能如履平地，继续前行。很有趣，不是吗？

但是，这样的车不常见。有几百万家庭拥有汽车和船只，很少有家庭买这些“鸭子”。你知道为什么吗？这很可能是因为没有人希望他们的船舵被打破而无法开车上班的事发生。“鸭子”很有趣，但它是一个坑，而单一职责原则可以帮助您避开这个坑。

O是开闭原则

开闭原则规定，代码实体应该对扩展开放，对修改关闭。更具体地说，你应该编写一个类能够完美完成所需任务，而不是希望人们进来改变它。它将对修改关闭，但是可以通过继承、覆盖或扩展某些行为来改变它。违反开闭原则的一个例子是添加一个菜单到应用程序时，还需要添加一个switch语句。

举一个很好的例子，比如你口袋里的智能手机。所有这些手机都有应用商店，这些应用商店可让您扩展手机的基本功能。当然，它附带基本功能：相机操作，实际通话，短信等。但是通过应用商店，您可以扩展手机的功能，让您管理自己的待办事项列表，把玩无意义的视频游戏，甚至可以当作手电筒或无线接入点。

然而，允许你这样做的机制纯粹是扩展。它不像苹果，谷歌和微软，将操作系统源代码放在github上，并邀请您深入研究，构建游戏和手电筒功能。相反，它们使手机核心功能对修改关闭，对扩展开放。

L是里氏代换原则

里氏代换原则(LSP)是面向对象编程中最独特的一个。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。

换句话说，如果你有一个Animal类，带有MakeNoise()方法，那么Animal的任何子类应该合理地实现MakeNoise()。猫应该喵，狗应该吠等等。但你不必定义一个抛出IDontActuallyMakeNoiseException的MuteMouse类，这违反了LSP，理由是这个类没有需要从Animal类继承的业务逻辑。

想象一下自己做烹饪，你只会把可食用的东西放进去，因为你不想每咬一口就挑选一下，然后反复问自己，“这是可以吃的吗？

I是接口隔离原理

接口隔离原则（ISP）表示，相对于一个较大，较全面的接口，您更应该支持多个的，更小的，特定于客户端的接口。简而言之，你不想强迫客户依赖他们实际上不需要的东西。想象一下你的代码使用了一些大的接口后，不得不频繁地重新编译/部署，而这仅仅是因为一些不相干方法换了一个签名。

假如你到当地的餐厅，打开菜单，你会看到所有常见的菜单主食，然后就是所谓的“特色汤”。为什么他们这样写？因为汤变化很大，而餐厅不会每天重新打印菜单。对汤不感兴趣的客户不需要被关注，而且他们通过访问服务方使用不同的接口。

D是依赖倒置

依赖性倒置原则（DIP）鼓励您编写依赖于抽象而不是具体细节的代码。您可以通过在代码中查找某个类或方法来识别这一特性，该类或方法采用像“Stream”这样的通称，并在上面执行方法，而不是实例化一个特定的Filestream或Stringstream或者其他任何类。这给相关的代码带来了更多的灵活性 - 你可以替换成任何符合Stream规范的类，它依旧可以运行。

联想一下现实生活，假如你到当地的商店，用信用卡付款。店员不会等看到您的卡是维萨后才检查您的卡，并取出“维萨机”。他只是取卡刷卡，而不用管这是什么卡。您和店员都只是关注抽象意义上的信用卡，而不用担心细节。

这就是SOLID!

希望这些可见的场景可以帮助您。如果您在编写代码时始终牢记SOLID，谁维护这些代码都会感到快乐。如果你有一个简单的方法来描绘、记住这些原则，那么它们将融入你知识的血液中。