面向对象设计原则

面向对象设计原则是OOPS（Object-Oriented Programming System，面向对象的程序设计系统）编程的核心.

众所周知，Java编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。

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

即不要写重复的代码，而是用“abstraction”类来抽象公有的东西。如果你需要多次用到一个硬编码值，那么可以设为公共常量；如果你要在两个以上的地方使用一个代码块，那么可以将它设为一个独立的方法。SOLID设计原则的优点是易于维护，但要注意，不要滥用,重复不是针对代码，而是针对功能。

原则2：封装变化

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

原则3：开闭原则

一个软件实体应当对扩展开放，对修改关闭
抽象化是开闭原则的关键
这是另一种非常棒的设计原则，可以防止其他人更改已经测试好的代码。理论上，可以在不修改原有的模块的基础上，扩展功能。这也是开闭原则的宗旨。

原则4：单一职责原则

在软件系统中，一个类只负责一个功能领域中的相应职责
类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题。

原则5：依赖注入或倒置原则

以抽象方式耦合是依赖倒转原则的关键
实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段
这个设计原则的亮点在于任何被DI框架注入的类很容易用mock对象进行测试和维护，因为对象创建代码集中在框架中，客户端代码也不混乱。有很多方式可以实现依赖倒置，比如像AspectJ等的AOP（Aspect Oriented programming）框架使用的字节码技术，或Spring框架使用的代理等。

原则6：优先利用组合而非继承

尽量使用对象组合，而不是继承来达到复用的目的
如果可能的话，优先利用组合而不是继承。一些人可能会质疑，但我发现，组合比继承灵活得多。组合允许在运行期间通过设置类的属性来改变类的行为，也可以通过使用接口来组合一个类，它提供了更高的灵活性，并可以随时实现。

原则7：里氏代换原则（LSP）

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

原则8：接口分离原则

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

原则9：针对接口编程，而不是针对实现编程

代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程该原则可以使代码更加灵活，以便可以在任何接口实现中使用。因此，在Java中最好使用变量接口类型、方法返回类型、方法参数类型等.

原则10：委托原则

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

总之，希望这些面向对象的设计原则能帮助你写出更灵活更好的代码。理论是第一步，更重要的是需要开发者在实践中去运用和体会。



面向对象关注的是对象的内在属性，只要内在属性一致，我们在建立对象模型的时候都将其抽象成一类对象，所以内在属性的是描述对象的不可更改要素。这种特性使得OOAD 的方法非常适合用于建立系统内部数据模型，通过对系统内部实体的抽象和描述，我们可以获得系统完整的数据结构和模型，而系统的功能就通过对这些对象的增删改查和计算等动作来完成。

而面向服务则不然，面向服务并不关心服务的内在逻辑，反而更关心服务的外在表象，只要对外的表现是一致的，我们在建立服务模型的时候就将其抽象为一类服务。比如缴费类服务，无论是缴水费还是缴电费，其外在的表象都是一致的，从行为模式上我们就可以抽象一个缴费的服务。面向对象中对象内在的属性是不可更改的要素，那么面向服务中构成行为的输入输出内容则成为不可更改的要素，比如打球这种行为，必须要有球也必须要有参与者。服务的这种特性使得SOAD 的方法更适合于在系统间建立交互模型，这样通过一个外在的流程引擎就可以通过合理的组织行为的顺序就达成了业务的目标。