面向对象设计的SOLID原则

标签：

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

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

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

开放封闭原则 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机将在您取款时收取一些费用，您同意吗”。你会如何解决？

面向对象设计的SOLID原则

标签：

原文地址：http://blog.csdn.net/sergeycao/article/details/51336578