标签：设计模式原则
1、何为设计模式？
设计模式不是工具，它是软件开发的哲学，它能指导你如何去涉及一个优秀的构架、编写一段健壮的代码、解决一个复杂的需求；
一、单一职责原则
2、定义：
“There should neverbe more than one reason for a class to change.”
——应该有且仅有一个原因引起类的变更。
一个职责映射一个接口，多个接口组成一个实现类，完成一个完整的功能过程；
3、单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异；
4、对于接口，设计是要做到单一，但对于实现类，既要考虑单一职责原则，又要考虑系统的复杂度，强行把一个类拆成两个类，再使用聚合或组合的方式耦合在一起是不可取的，会增加系统的复杂度；
5、单一职责原则适用于类、接口和方法；方法和接口一定要做到单一，类的设计尽量做到单一；
二、里氏替换原则
6、定义：
“Functions that usepointers or references to base classes must be able to use objects of derivedclasses without knowing it. ”
——所有引用基类的地方必须能透明地使用其子类的对象；
只要父类能出现的地方，子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者根本就不需要知道是父类还是子类；反过来，子类出现的地方父类未必就能适合；
7、如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸形”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承；
8、子类覆盖（override）或重载（overload）父类方法；覆盖时，要求两者类型范围一致；重载时，要求子类类型范围应宽于父类类型范围，即子类应扩大父类的前置条件；
9、前置条件与后置条件：前者就是你要让我执行，就必须满足我的条件；后者就是我只信完了需要反馈，标准是什么。
三、依赖倒置原则
10、定义：
“High level modulesshould not depend upon low level modules. Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend uponabstractions ”;
——高层模块不应该依赖于底层模块，两者都应该依赖其抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
——（具体化）模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象产生的。接口或抽象不依赖于实现类，反之，实现类依赖于接口或抽象类；
——（本质）通过抽象（接口或抽象类）使各个实现类或模块的实现彼此独立，不互相影响，实现实现类或模块间的松耦合；
——利用抽象间的关系代替人们思维中事物之间实在的联系，即“面向接口或抽象编程”；
底层模块：指不可分割的原子逻辑；每一个逻辑的实现都是由许多的原子逻辑组成的；
高层模块：指原子逻辑的再组装的产物；
抽象：指接口或抽象类，来年跟着都不能被实例化；
细节：指实现类，实现接口或继承抽象类而产生的类，它可以被实例化；
11、证明一个定理的方法：顺推证明和反证明；
12、其优点：减少实现类之间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性；
13、五点规则：
（1）每个类尽量都有接口或抽象类，或者两者都具备；
（2）变量的表面类型尽量是接口或抽象类；
（3）如何类都不应该从具体类派生；
（4）尽量不要覆写基类的方法；
（5）结合里氏替换原则使用；
通俗的规则：接口定义public属性和方法，并且声明与其他变量的依赖关系；抽象类负责公共构造部分的实现；实现类准确地实现业务逻辑，同时在适当的时候对父类进行细化；
四、接口隔离原则
14、定义：
“The dependency of one class to another one should depend on thesmallest possible interface.”
——类间的依赖关系应该建立在最小的接口上；
——接口尽量细化，接口中的方法尽量少，使接口趋向专门化；
15、接口有两种：实例接口（类是一种接口）和类接口（interface）
16、接口隔离原则是对接口进行规范约束：
（1）接口尽量小，但“小“是有限度的，首先不能违反单一职责原则；
（2）接口要高内聚，即提高接口、类、模块的处理能力，减少对外的交互；
（3）定制服务，针对不同的对象，尽量设计专门的服务接口；
五、迪米特法则（又称：最少知识原则）
17、定义：
“Only talk to your immediate friends ”
——只与直接的朋友通信；即降低耦合，提高健壮性；解耦和、弱耦合；
——一个对象应该对其他对象有最少的了解，即一个类应该对自己需要乘或调用的类知道得最少，只要知道其提供多少public 方法，就调用多少就好；
18、类鱼类之间的关系是建立在类间的，而不是建立在方法间，一个方法尽量不要引用一个类中不存在的方法；
19、迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和静态的public变量，尽量内敛，多使用private、package-private、protected 等访问权限；
20、对于一个方法放置在哪里的问题：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中；
六、开闭原则
21、定义：
“Software entities like classes , modulesand functions should be open for extension but closed for modifications.”
——一个软件实体如类、模块和函数应该对扩展开放，对修改关闭；
——一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化；它是为软件实体的未来事件而制定的对现行开放设计进行约束的一个原则；
22、一个项目的基本路径：开发、重构（对原有的设计和代码进行修改）、测试、投产、运维（尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性）；
23、三类变化类型：
（1）逻辑变化
（2）子模块变化
（3）可见视图变化
本文出自 “读书笔记” 博客，请务必保留此出处http://xiexiao.blog.51cto.com/10173801/1641122
标签：设计模式原则
原文地址：http://xiexiao.blog.51cto.com/10173801/1641122
