被说了很多遍的设计模式---这些原则还记得吗？

[把你的理性思维慢慢变成条件反射]

       有一段时间没有更新博客了，倒不是说没有内容可写，而是在选择写什么内容合适。前面的一系列的MQ文章越来越靠近运维的方向。而对于我们开发者的角度，应该关注什么呢？首先，我不是什么大神级的人物，暂时还做不了架构层面知识分享，以免误人子弟。再者，现在各种资料满天飞，几乎无所不包。所以，最近思考了下我们日常开发最核心的问题在哪？目前，我找到的答案是：根据实际情况进行设计建模。当然，这是一个很宽泛的话题，并且家家情况不同。因此，这里我们准备从大部分看官都学习过的设计模式谈起，后续，再根据情况给大家介绍更多关于设计方面的技巧。

       接下来的数篇文章，主要目的是想让各位看官在开发过程中，改变一下思维方式，而非重复的造轮子。遇到问题首先考虑下是否有通用的，技巧性的设计方案等等。知识就在你的脑海里，及时的反应并运用才是真正的学习过程。

       对于参考自其他资料。在此，先对各位开源大神及作者表示感谢。具体资料间文章末尾。

       特别的：在介绍设计模式的过程中，我们先不关注设计模式的概念，作用等等。这些内容先最为预留问题留给各位看官自己发现。在系列文章的最后，我们再进行统一的总结归纳。题外的话：博主习惯上喜欢先学会做一件事，再通过发现问题，解决问题的过程，来构建知识树，这种方法在之前的文章中也一直暗示给大家。鉴于时间的关系，如果各位看官想提前了解这部分知识的话，那就请查阅其他资料吧。

-------------------------------------------------------------------------------------------------------------------------------------

为什么先要说说这些原则？

对于面向对象设计而言，在保证代码正确性之后，更重要的是使得代码可维护，可复用，并且正确的反应核心问题。后面接受的诸多设计模式其实都是设计原则的不同角度的实现过程。并且，在后续的文章中，我们会经常使用“....符合....原则”或者“.....违反.....原则”。在此，先特别说明。

常见的面向对象设计原则

1. 单一职责原则(Single Responsibility Principle)：一个类只负责一个功能领域中的相应职责。或者说：就一个类而言，应该仅有一个引起它变化的原因。（如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合的设计会导致非常脆弱的结构。当发生变化时，设计会遭受到意想不到的破坏。）
2. 开闭原则(Open-Closed Principle)：软件实体（类，模块，函数等）应对扩展开放，对修改关闭。在软件开发中，无论设计的模块是多么的封闭，都会存在一些无法封闭的变化。既然无法做到完全封闭，设计人员就必须对于他设计的模块应该对那种变化封闭做出选择。必须先猜测出最有可能发生变化的种类，然后构造抽象来隔离那些变化。然后在发生变化是可以立即采取行动。我们在编写代码之初，假设不会发生变化，但是，当发生变化时就应该创建抽象，来隔离这些同类型的变化。对于这些变化，应该是通过增加新代码进行，而不是更改现有的代码。该原则是面向对象设计的核心所在。遵循这个变化可以带来可维护，可扩展，可复用等诸多好处。但是，实际应用时，建议初学者谨慎处理，防止滥用。
3. 里氏代换原则(Liskov Substitution Principle)：所有引用父类对象的地方能够透明的替换为其他子类对象。原始的表述方式非常的晦涩，在此，我们以通俗的方式解释如下：准备工作，父类BaseClass，子类SubClass，实际方法调用时method（baseClass）。在这种情况下，我们调用method传入的参数也可以是Subclass，及method（subClass）。这种书写方法的实际作用是：在实际运行才确定子类的类型。实际应用时，建议在父类中声明所有方法，具体实现位置可以按照实际需求进行实现。
4. 依赖倒转原则(Dependence Inversion Principle)：抽象不应该依赖于细节，细节应该依赖于抽象。换句话说，就是针对接口变成，不要针对实现编程。还需要注意的细节是，高层模块不应该依赖于底层模块，两个都应该依赖于抽象。换句话说，依赖关系终结于抽象类或者接口。
5. 接口隔离原则（Interface Segregation Principle）:使用多个专门的接口，而不使用单一的总接口。换句话说，当一个接口太大时，应当尝试将其分割成为更加细小的接口，使得这些接口满足使用者的需求即可。常见的使用场景是，系统内部外部调用同一服务时的接口内容大小问题。特别注意的是：谨慎设计接口粒度。过大，过小都会导致实际使用时发生问题。
6. 合成复用原则（Composite Reuse Principle）:尽量使用对象组合，而不是继承来达到复用的目的。通过组合的方式能够降低类之间的耦合度，一个类的变化基本不会对另一个类产生影响。相反的，如果采用继承的方式，那么前文采用的里氏代换原则就会发生错误。其次，新对象内部组合起来的旧对象的变化对于新的对象是透明的。内部的重构，优化等操作不会发生扩散。常见的场景是：在使用数据库时，connection的建立与关闭应该与某个具体的Dao保持组合关系。而不是将建立与关闭操作放置在父类当中。
7. 迪米特法则（Law of Demeter）：一个软件实体应当尽可能少的与其他实体发生相互作用。该原则的作用非常明显，降低耦合度，保持松散关系。具体的讲，对于当前对象本身及成员变量，传入的参数，以及由当前对象创建的对象都算作为本身的交互。除此之外，都算作发生耦合关系。此时，就应该通过引入第三方来降低这种对象间的耦合关系。举个例子：现在流行的异步消息系统，事件通知，监听等等，都可以算作是该法则的应用。

-------------------------------------------------------------------------------------------------------------------------------------

至此，被说了很多遍的设计模式---这些原则还记得吗？ 结束

特别备注：上面的这些原则仅作为指导方法，实际应用时，建议各位看官时常反思设计是否符合要求。优秀的代码都是一次次的重构，毫无捷径。共勉！

参考资料：

图书：《大话设计模式》

其他博文：http://blog.csdn.net/lovelion/article/details/7563445