软件设计原则

设计的流行趋势转瞬即逝，但是设计原则确是永恒的，以下则是我们程序设计的七大设计原则：
1. 开-闭原则(Open-Closed Principle, OCP)
一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。
2. 里氏代换原则(Liskov Substitution Principle,常缩写为.LSP)
1. 里氏代换原则（LiskovSubstitution Principle，简称LSP）说的是：一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且它根本不能够察觉出基类对象和子类对象的区别。也就是说，在软件实体里面，把父类都换成其子类，程序的行为是不会发生变化的。
2. 里氏代换原则（LSP）：子类型必须能替换掉它的父类型，反过来代换原则不成立。
3. 里氏代换原则是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不会受到影响的时候，基类才能真正被复用，而衍生类也才能够在基类的基础上添加新的行为。

1. 依赖倒置原则
   所谓依赖倒置原则（Dependence Inversion Principle ）就是要依赖于抽象，不要依赖于具体。简单的说就是对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合
   定义如下：
   
   1. 高层模块不应该依赖低层模块，两者都应该依赖于抽象（抽象类或接口）
   2. 抽象（抽象类或接口）不应该依赖于细节（具体实现类）
   3. 细节（具体实现类）应该依赖抽象
2. 接口隔离原则(Interface Segregation Principle, ISP)
   
   1. 一个类对另外一个类的依赖是建立在最小的接口上
   2. 使用多个专门的接口比使用单一的总接口要好.根据客户需要的不同,而为不同的客户端提供不同的服务是一种应当得到鼓励的做法.就像”看人下菜碟”一样,要看客人是谁,再提供不同档次的饭菜
   3. 胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系.当一个客户程序要求该胖接口进行一个改动时,会影响到所有其他的客户程序.因此客户程序应该仅仅依赖他们实际需要调用的方法
3. 合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
   在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.

4. 迪米特法则(Law of Demeter LoD)又叫做最少知识原则(Least Knowledge Principle,LKP)
   就是说,一个对象应当对其他对象有尽可能少的了了解.
   迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,与1987年秋天由Ian Holland在美国东北大学为一个叫做迪米特(Demeter)的项目设计提出的,因此叫做迪米特法则[LIEB89][LIEB86].这条法则实际上是很多著名系统,比如火星登陆软件系统,木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则.
   没有任何一个其他的OO设计原则象迪米特法则这样有如此之多的表述方式,如下几种:

   1. 只与你直接的朋友们通信(Only talk to your immediate friends).
   2. 不要跟”陌生人”说话(Don’t talk to strangers).
   3. 每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位.

   就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用.

5. 单一职责原则(Simple responsibility pinciple SRP)
   就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责.