面向对象设计原则

什么是设计原则？ 

设计原则是基本的工具，应用这些规则可以使你的代码更加灵活、更容易维护，更容易扩展。

基本原则

• 封装变化Encapsulate what varies.
• 面向接口编程而非实现 Code to an interface rather than to an implementation.
• 优先使用组合而非继承 Favor Composition Over Inheritance

SRP: The single responsibility principle 单一职责

系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。

Every object in your system should have a single responsibility ,and all the object s services should  be focused on carrying out that single responsibility .

 

1. 每一个职责都是一个设计的变因，需求变化的时候，需求变化反映为类职责的变化。当你系统里面的对象都只有一个变化的原因的时候，你就已经很好的遵循了SRP原则。
2. 如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候，设计会遭到意想不到的破坏。
3. SRP 让这个系统更容易管理维护，因为不是所有的问题都搅在一起。
4. 内聚Cohesion 其实是SRP原则的另外一个名字.你写了高内聚的软件其实就是说你很好的应用了SRP原则。
5. 怎么判断一个职责是不是一个对象的呢？你试着让这个对象自己来完成这个职责，比如：“书自己阅读内容”，阅读的职责显然不是书自己的。
6. 仅当变化发生时，变化的轴线才具有实际的意义，如果没有征兆，那么应用SRP或者任何其它的原则都是不明智的。

DRY : Don't repeat yourself Principle

通过抽取公共部分放置在一个地方避免代码重复.

Avoid duplicate code by abstracting out things that are common and placing those thing in a single location .

 

1. DRY 很简单，但却是确保我们代码容易维护和复用的关键。
2. 你尽力避免重复代码候实际上在做一件什么事情呢？是在确保每一个需求和功能在你的系统中只实现一次，否则就存在浪费！系统用例不存在交集，所以我们的代码更不应该重复，从这个角度看DRY可就不只是在说代码了。
3. DRY 关注的是系统内的信息和行为都放在一个单一的，明显的位置。就像你可以猜到正则表达式在.net中的位置一样，因为合理所以可以猜到。
4. DRY 原则：如何对系统职能进行良好的分割！职责清晰的界限一定程度上保证了代码的单一性。
   

OCP : Open-Close Principle开闭原则

类应该对修改关闭，对扩展打开；

Classes should be open for extension ,and closed  for modification .

 

1. OCP 关注的是灵活性，改动是通过增加代码进行的，而不是改动现有的代码；
2. OCP的应用限定在可能会发生的变化上，通过创建抽象来隔离以后发生的同类变化
3. OCP原则传递出来这样一个思想：一旦你写出来了可以工作的代码，就要努力保证这段代码一直可以工作。这可以说是一个底线。稍微提高一点要求,一旦我们的代码质量到了一个水平，我们要尽最大努力保证代码质量不回退。这样的要求使我们面对一个问题的时候不会使用凑活的方法来解决，或者说是放任自流的方式来解决一个问题；比如代码添加了无数对特定数据的处理，特化的代码越来越多，代码意图开始含混不清，开始退化。
4. OCP 背后的机制：封装和抽象；封闭是建立在抽象基础上的，使用抽象获得显示的封闭；继承是OCP最简单的例子。除了子类化和方法重载我们还有一些更优雅的方法来实现比如组合；

怎样在不改变源代码（关闭修改）的情况下更改它的行为呢？答案就是抽象，OCP背后的机制就是抽象和多态

5. 没有一个可以适应所有情况的贴切的模型！一定会有变化，不可能完全封闭.对程序中的每一个部分都肆意的抽象不是一个好主意，正确的做法是开发人员仅仅对频繁变化的部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。
6. OCP是OOD很多说法的核心，如果这个原则有效应用，我们就可以获更强的可维护性 可重用 灵活性 健壮性 LSP是OCP成为可能的主要原则之一

LSP: The Liskov substitution principle

子类必须能够替换基类。

Subtypes must be substitutable  for their base types.

 

1. LSP关注的是怎样良好的使用继承.
2. 必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。
3. LSP清晰的指出，OOD的IS-A关系是就行为方式而言，行为方式是可以进行合理假设的，是客户程序所依赖的。
4. LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。而假设是难以预测的，直到设计臭味出现的时候才处理它们。
5. 对于LSP的违反也潜在的违反了OCP

DIP：依赖倒置原则

高层模块不应该依赖于底层模块 二者都应该依赖于抽象

抽象不应该依赖于细节 细节应该依赖于抽象

1. 什么是高层模块？高层模块包含了应用程序中重要的策略选择和业务模型。这些高层模块使其所在的应用程序区别于其它。
2. 如果高层模块依赖于底层模块，那么在不同的上下文中重用高层模块就会变得十分困难。然而，如果高层模块独立于底层模块，那么高层模块就可以非常容易的被重用。该原则就是框架设计的核心原则。
3. 这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口，而服务者从这些抽象接口派生。
4. 这就是著名的Hollywood原则:"Don't call us we'll call you."底层模块实现了在高层模块声明并被高层模块调用的接口。
5. 通过倒置我们创建了更灵活 更持久更容易改变的结构
6. DIP的简单的启发规则：依赖于抽象；这是一个简单的陈述，该规则建议不应该依赖于具体的类，也就是说程序汇总所有的依赖都应该种植于抽象类或者接口。
7. 如果一个类很稳定，那么依赖于它不会造成伤害。然而我们自己的具体类大多是不稳定的，通过把他们隐藏在抽象接口后面可以隔离不稳定性。
8. 依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方
9. 依赖倒置原则是实现许多面向对象技术多宣称的好处的基本底层机制，是面向对象的标志所在。

ISP:接口隔离原则

不应该强迫客户程序依赖它们不需要的使用的方法。

 

1. 接口不是高内聚的，一个接口可以分成N组方法，那么这个接口就需要使用ISP处理一下。
2. 接口的划分是由使用它的客户程序决定的，客户程序是分离的接口也应该是分离的。
3. 一个接口中包含太多行为时候，导致它们的客户程序之间产生不正常的依赖关系，我们要做的就是分离接口，实现解耦。
4. 应用了ISP之后，客户程序看到的是多个内聚的接口。

－－－－－－－－－针对java的面向对象设计原则－－－－－－－－－－－－－－－－－－－－－－－－－－

面向对象设计原则是OOPS（Object-Oriented Programming System，面向对象的程序设计系统）编程的核心，但大多数Java程序设计人员不重视面向对象的分析和设计。甚至还有经验丰富的Java程序员没有听说过OOPS和SOLID设计原则，他们根本不知道设计原则的好处，也不知道如何依照这些原则来进行编程。接下来有博洋教育帮助大家补充这方面的知识点。

众所周知，Java编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。查看Apache和Sun的开放源代码能帮助你发现其他Java设计原则在这些代码中的实际运用。Java Development Kit则遵循以下模式：BorderFactory类中的工厂模式、Runtime类中的单件模式。

虽然实际案例是学习设计原则或模式的最佳途径，但通过博洋教育的介绍，没有接触过这些原则或还在学习阶段的Java程序员也能够了解这10个面向对象的设计原则。

1：封装变化

在软件领域中唯一不变的就是“Change”，因此封装你认为或猜测未来将发生变化的代码。OOPS设计模式的优点在于易于测试和维护封装的代码。如果你使用Java编码，可以默认私有化变量和方法，并逐步增加访问权限，比如从private到protected和not public。有几种Java设计模式也使用封装，比如Factory设计模式是封装“对象创建”，其灵活性使得之后引进新代码不会对现有的代码造成影响。

2：DRY（Don't repeat yourself）原则

即不要写重复的代码，而是用“abstraction”类来抽象公有的东西。如果你需要多次用到一个硬编码值，那么可以设为公共常量；假设你要在两个以上的地方使用一个代码块，那么可以将它设为一个独立的方法。设计的原则就是要易于维护，使用公共代码来实现两个不同的功能，其实就是近似地把这两个功能永远捆绑到了一起。

3：单一职责原则

类被修改的几率是非常大的，因此应该注重于设计单一的功能类进行封装。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题。

4：依赖注入或倒置原则

这个设计原则的亮点在于任何被DI框架注入的类很容易用mock对象进行测试和维护，因为对象创建代码集中在框架中，客户端代码也不混乱。有很多方式可以实现依赖倒置，比如像AspectJ等的AOP（Aspect Oriented programming）框架使用的字节码技术，或Spring框架使用的代理等。

5：开闭原则

即对扩展开放，对修改关闭。这是另一种非常棒的设计原则，可以防止其他人更改已经测试好的代码。使用这项原则上可以在不修改原有的模块的基础上，扩展功能。这也是开闭原则的宗旨。

6：接口分离原则

设计采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。设计接口很棘手，因为一旦释放接口，你就无法在不中断执行的情况下改变它。在Java中，该原则的另一个优势在于，在任何类使用接口之前，接口不利于实现所有的方法，所以单一的功能意味着更少的实现方法。

7：针对接口编程，而不是针对实现编程

该原则是程序设计过程中的一个要点，可以使代码更加灵活，以便可以在任何接口实现中使用。因此，在Java中最好使用变量接口类型、方法返回类型、方法参数类型等。

8：优先利用组合而非继承

在开发过程中应该尽可能优先利用组合而不是继承。一些人可能会质疑，但观察发现，组合比继承灵活得多。组合允许在运行期间通过设置类的属性来改变类的行为，也可以通过使用接口来组合一个类，它提供了更高的灵活性，并可以随时实现。

9：里氏代换原则（LSP）

根据该设计原则，子类必须能够替换掉它们的基类，也就是说使用基类的方法或函数必须能够顺利地引用子类对象。为了遵循该设计原则，派生类或子类必须增强功能。LSP原则与单一职责原则和接口分离原则密切相关，如果一个类比子类具备更多功能，很有可能某些功能会失效，这就违反了LSP原则。

10：委托原则

该原则最典型的例子是Java中的equals() 和 hashCode() 方法。为了平等地比较两个对象，我们用类本身而不是客户端类来做比较。这个设计原则的好处是没有重复的代码，而且很容易对其进行修改。