设计模式基本原则

　　看设计模式看了一段时间了，应该说在大学里面已经针对设计模式上课学习过一遍，记得初次看学习设计模式的时候，感觉很强大，有太多新的自己想象不到的设计思路，一个个在接受，毕竟学生的时候只是觉得新颖在看看，对于他的灵魂－－设计模式的几个基本原则，也就只能达到随口而出的一个“开－闭原则”吧，呵呵，这段时间再细看了一遍，理解比以前深了一点，持续学习中。。。，先把几大基本原则记录下来先
1、开－闭原则
　　模块应对扩展开放，而对修改关闭，简而言之，我们要新增或修改功能的时候，尽量达到不要修改原来的代码，而通过模块扩展去实现，具体到我们平时的现实应用中，可以描述如下：
　　1).客户的需求是不稳定的，通过扩展已有的软件系统而不是通过修改软件系统来满足客户的需求，这样的软件系统就满足开－闭原则，即软件系统要有一定的灵活性和适应性。

　　2).已有的模块，特别是抽象层的模块不能修改，保证软件系统的稳定性和延续性。 解决问题的关键是抽象化，把它与具体实现分离开来。接口（interface），抽象类的应用 对可变性封装：将可变性封装到一个对象里。

2、里氏代换原则
　　如果调用的是父类的话，那么换成子类也完全可以运行。里氏代换原则是继承复用的一个基础。体现为：
　　当两个具体类关系违反里氏代换原则时，一种办法是抽象出一个基类，作为这两个类的父类， 一种是应用组合聚合关系建立关系。 不要为了使用某些类的方法（功能）而滥用继承。

3、合成复用原则
　　就是说要少用继承，多用合成关系来实现
　　这个原则当初看起来比较虚，一直没有理解到其中内含，直至今日，虽然有了更深一点的体会，但实际应用中还是把握得不是很好。Prefer composition to inheritance.这句话的背景是OO初期大家都把继承看作是万能的,并过度使用继承来实现多态->可扩展.
　　体现为：比如说你项目中的很多类都要和数据库做交互，这种情况下我们都往往会抽象一个数据库操作类出来，然后把自己觉得公用的方法一脑子在这个操作类里面实现，然后其中的和数据库有交互的类都继续这个类，看起来这个没有多大问题，但是如果操作类这个公用性抽象不好，某天你需要改操作类的某个方法，你会发现你下面的各个类都需要做相应的修改，变动那是相当大呀。当然这个例子可能不是很好，意会一下...

4、依赖倒转原则
　　抽象不应该依赖与细节，细节应当依赖与抽象。 要针对接口编程，而不是针对实现编程。 传递参数，或者在组合聚合关系中，尽量引用层次高的类。 主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉

5、接口隔离原则
　　定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干

6、抽象类
　　抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同属性和方法。
注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类
是不被继承的。将尽可能多的共同代码放到抽象类中。

7、迪米特法则
　　最少知识原则。不要和陌生人说话。