面向对象设计的SOLID原则

S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。

SRP	The Single Responsibility Principle	单一责任原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
DIP	The Dependency Inversion Principle	依赖倒置原则
ISP	The Interface Segregation Principle	接口分离原则

单一责任原则：The Single Responsibility Principle 
当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。 

在类中的一切都与该单一目的有关，即内聚性。这并不是说类只应该含有一个方法或属性。

类中可以包括很多成员，只要它们与单一的职责有关。当类改变的一个原因出现时，类的多个成员可能多需要修改。也可能多个类将需要更新。

开放封闭原则 The Open Closed Principle 
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。

这个原则的两个部分似乎是对立的。但是，如果正确地设计类和他们的依赖关系，就可以增加功能而不修改已有的源代码。

通常来说可以通过依赖关系的抽象实现开闭原则，比如接口或抽象类而不是具体类。通过创建新的类实现接口来增加功能。

在项目中应用OCP原则可以限制代码的更改，一旦代码完成，测试和调试之后就很少再去更改。这减少了给现有代码引入新bug的风险，增强软件的灵活性。

里氏替换原则 The Liskov Substitution Principle
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系 

因此，所有的子类必须按照和他们父类相同方式操作。子类的特定功能可能不同，但是必须符合父类的预期行为。要成为真正的行为子类型，子类必须不仅要实现父类的方法和属性，也要符合其隐含行为。

一般来说，如果父类型的一个子类型做了一些父类型的客户没有预期的事情，那这就违反LSP。比如一个派生类抛出了父类没有抛出的异常，或者派生类有些不能预期的副作用。基本上派生类永远不应该比父类做更少的事情。

一个违反LSP的典型例子是Square类派生于Rectangle类。Square类总是假定宽度与高度相等。如果一个正方形对象用于期望一个长方形的上下文中，可能会出现意外行为，因为一个正方形的宽高不能(或者说不应该)被独立修改。

解决这个问题并不容易：如果修改S

依赖倒置原则The Dependency Inversion Principle
1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象 
2. 抽象不应该依赖于细节，细节应该依赖于抽象 

方法是将类孤立在依赖于抽象形成的边界后面。如果在那些抽象后面所有的细节发生变化，那我们的类仍然安全。这有助于保持低耦合，使设计更容易改变。DIP也允许我们做单独测试，比如作为系统插件的数据库等细节。

接口分离原则 The Interface Segregation Principle
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 

当你应用ISP时，类和他们的依赖使用紧密集中的接口通信，最大限度地减少了对未使用成员的依赖，并相应地降低耦合度。小接口更容易实现，提升了灵活性和重用的可能性。由于很少的类共享这些接口，为响应接口的变化而需要变化的类数量降低，增加了鲁棒性。

基本上，这里的教训是“不要依赖你不需要的东西”。下面是例子：

想象一个ATM取款机，通过一个屏幕显示我们想要的不同信息。你会如何解决显示不同信息的问题？我们使用SRP,OCP和LSP想出一个方案，但是这个系统仍然很难维护。这是为什么？

想象ATM的所有者想要添加仅在取款功能出现的一条信息，“ATM机将在您取款时收取一些费用，您同意吗”。你会如何解决？