Java程序员应当知道的10个面向对象设计原则

Java程序员应当知道的10个面向对象设计原则
面向对象设计原则是OOPS编程的核心， 但我见过的大多数Java程序员热心于像Singleton (单例) 、 Decorator(装饰器)、Observer(观察者) 等设计模式，而没有把足够多的注意力放在学习面向对象的分析和设计上面。学习面向对象编程像“抽象”、“封装”、“多态”、“继承” 等基础知识是重要的，但同时为了建立简洁、模块化的设计，了解这些设计原则也同等重要。我常常看到不一样经验水平的java程序员，他们有的不知道这些OOPS 和SOLID设计原则，有的只是不知道一个特定的设计原则会带来怎样的益处，甚至不知道在编码中如何使用这些设计原则。

(设计原则)底线是永远追求高内聚、低耦合的编码或设计。 Apache 和 Sun的开源代码是学习Java和OOPS设计原则的良好范例。它们向咱们展现了，设计原则在Java编程中是如何使用的。Java JDK 使用了一些设计原则：BorderFactory类中的工厂模式、Runtime类中的单例模式、java.io 类中的装饰器模式。
虽然学习设计模式(原则)最好的方法是现实中的例子和理解违反设计原则带来的不便，本文的宗旨是向那些没有接触过或正处于学习阶段的Java程序员介绍面向对象设计原则。我我的认为OOPS 和SOLID设计原则须要有文章清楚的介绍它们，在此我必定尽力作到这点，但如今请您准备浏览如下设计模式(原则) :)

DRY – Don’t repeat yourself

咱们第一个面向对象设计原则是：DRY ，从名称能够看出DRY(don’t repeat yourself)意思是不写重复代码，而是抽象成可复用的代码块。若是您有两处以上相同的代码块，请考虑把它们抽象成一个单独的方法；或者您屡次使用了硬编码的值，请把它们设置成公共常量。这种面向对象设计原则的优势是易于维护。重要的是不要滥用此原则，重复不是针对代码而是针对功能来讲。它的意思是，若是您使用通用代码来验证OrderID和SSN，这并不意味着它们是相同的或者他们从此将保持不变。经过把通用代码用于实现两种不一样的功能，或者您把这两种不一样的功能密切地联系在一块儿；当您的OrderID格式改变时，您的SSN验证代码将会中断。因此要小心这种耦合，并且不要把彼此之间没有任何关系却相似的代码组合在一块儿。

封装常常修改的代码 Encapsulate What Changes

在软件领域永远不变的是“变化”，因此把您认为或怀疑未来要被修改的代码封装起来。这种面向对象设计模式的优势是：易于测试和维护恰当封装的代码。若是您在用Java编程，那么请遵照如下原则：变量和方法的访问权限默认设置为私有，而且逐步放开它们的访问权限，例如从“private”到“protected ”、“not public”。Java中的一些设计模式使用了封装，工厂设计模式就是一个例子，它封装了建立对象的代码并且提供了如下灵活性：后续生成新对象不影响现有的代码。

打开/关闭设计原则 OpenClosed Design Principle

类、方法/函数应当是对扩展(新功能)开放，对修改闭合。这是另一个优雅的SOLID 设计原则，以防止有人修改经过测试的代码。理想状况下假如您添加了新功能，那么您的代码要通过测试，这就是打开/关闭设计原则的目标。顺便说一句，SOLID中的字母“O”指的是打开/关闭设计原则。

单一职责原则 Single Responsibility Principle(SRP)

单一职责原则是另一个SOLID设计原则，SOLID中的字母“S”指的就是它。按照SRP，一个类修改的缘由应当有且只有一个，或者一个类应当老是实现单一功能。若是您在Java中的一个类实现了多个功能，那么这些功能之间便产生了耦合关系；若是您修改其中的一个功能，您有可能就打破了这种耦合关系，那么就要进行另外一轮测试以免产生新的问题。

依赖注入/反转原则 Dependency Injection or Inversion principle

不要问框架的依赖注入功能将会给你带来什么益处，依赖注入功能在spring框架里已经很好的获得了实现，这一设计原则的优雅之处在于：DI框架注入的任何一个类都易于用模拟对象进行测试，而且更易于维护，由于建立对象的代码在框架里是集中的并且和客户端代码是隔离的。有多种方法能够实现依赖注入，例如使用字节码工具，其中一些AOP(面向切面编程)框架如切入点表达式或者spring里使用的代理。想对这种SOLID设计原则了解更多，请看IOC 和 DI设计模式中的例子。 SOLID中的字母“D”指的就是这种设计原则。

优先使用组合而非继承 Favor Composition over Inheritance

若是能够的话，要优先使用组合而非继承。大家中的一些人可能为此争论，但我发现组合比继承更有灵活性。组合容许在运行时经过设置属性修改一个类的行为，经过使用多态即以接口的形式实现类之间的组合关系，而且为修改组合关系提供了灵活性。甚至 Effective Java也建议优先使用组合而非继承。

里氏替换原则 Liskov Substitution Principle LSP

根据里氏替换原则，父类出现的地方能够用子类来替换，例如父类的方法或函数被子类对象替换应该没有任何问题。LSP和单一职责原则、接口隔离原则密切相关。若是一个父类的功能比其子类还要多，那么它可能不支持这一功能，并且也违反了LSP设计原则。为了遵循 LSP SOLID设计原则，派生类或子类(相对父类比较)必须加强功能，而非减小。SOLID中的字母“L”指的就是 LSP设计原则。

接口隔离原则

接口隔离原则指，若是不须要一个接口的功能，那么就不要实现此接口。这大多在如下状况发生：一个接口包含多种功能，而实现类只须要其中一种功能。接口设计是一种棘手的工做，由于一旦发布了接口，您就不能修改它不然会影响实现该接口的类。在Java中这种设计原则的另外一个好处是：接口有一个特色，任何类使用它以前都要实现该接口全部的方法，因此使用功能单一的接口意味着实现更少的方法。

编程以接口(而非实现对象)为中心

编程老是以接口(而非实现对象)为中心，这会使代码的结构灵活，并且任何一个新的接口实现对象都能兼容现有代码结构。因此在Java中，变量、方法返回值、方法参数的数据类型请使用接口。这是许多Java程序员的建议， Effective Java 以及 head first design pattern 等书也这样建议。

代理原则

不要指望一个类完成全部的功能，能够适当地把一些功能交给代理类实现。代理原则的典范是：Java 中的equals() 和 hashCode() 方法。为了比较两个对象的内容是否相同，咱们让用于比较的类自己完成对比工做而非它们的调用方。这种设计原则的好处是：没有重复编码并且很容易修改类的行为。
喜欢这样文章的能够关注我，我会持续更新，大家的关注是我更新的动力！须要更多java学习资料的也能够私信我！
祝关注个人人都：身体健康，财源广进，福如东海,寿比南山，早生贵子，从不掉发!