共计 3211 个字符，预计需要花费 9 分钟才能阅读完成。
本文章转自：乐字节
文章次要解说：10 个面向对象设计准则
获取更多 Java 相干常识能够关注公众号《乐字节》发送：999
面向对象设计准则是 OOPS 编程的外围，但我见过的大多数 Java 程序员热心于像 Singleton (单例)、Decorator(装璜器)、Observer(观察者) 等设计模式，而没有把足够多的注意力放在学习面向对象的剖析和设计下面。学习面向对象编程像“形象”、“封装”、“多态”、“继承”等基础知识是重要的，但同时为了创立简洁、模块化的设计，理解这些设计准则也等同重要。我常常看到不同教训程度的 java 程序员，他们有的不晓得这些 OOPS 和 SOLID 设计准则，有的只是不晓得一个特定的设计准则会带来怎么的好处，甚至不晓得在编码中如何应用这些设计准则。
(设计准则)底线是永远谋求高内聚、低耦合的编码或设计。Apache 和 Sun 的开源代码是学习 Java 和 OOPS 设计准则的良好范例。它们向咱们展现了，设计准则在 Java 编程中是如何应用的。Java JDK 应用了一些设计准则：BorderFactory 类中的工厂模式、Runtime 类中的单例模式、java.io 类中的装璜器模式。顺便说一句，如果您真的对 Java 编码准则感兴趣，请浏览 Joshua Bloch 的 Effective Java，他编写过 Java API。我集体最喜爱的对于面向对象设计模式的是 Kathy Sierra 的 Head First Design Pattern(深入浅出设计模式)，以及其它的对于深入浅出面向对象分析和设计。这些书对编写更好的代码有很大帮忙，充分利用各种面向对象和 SOLID 的设计模式。
尽管学习设计模式 (准则) 最好的办法是事实中的例子和了解违反设计准则带来的不便，本文的主旨是向那些没有接触过或正处于学习阶段的 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() 办法。为了比拟两个对象的内容是否雷同，咱们让用于比拟的类自身实现比照工作而非它们的调用方。这种设计准则的益处是：没有反复编码而且很容易批改类的行为。
总结
以上所有面向对象的设计准则能够帮忙您写出灵便、优雅的代码：具备高内聚低耦合的代码构造。实践只是第一步，更重要的是咱们要习得一种能力去发现什么时候应用这些设计准则。去发现咱们是否违反了什么设计准则和影响了代码的灵活性，然而世界上没有什么是完满的，咱们解决问题时不能总去应用设计模式和设计准则，它们大多用于有较长保护周期的大型企业我的项目
感激大家的认同与反对，小编会继续转发《乐字节》优质文章
