设计原则

  面向对象设计原则
1.SRP(单一职责原则) 就一个类而言，应该仅有一个引起它变化的原因。
    好处：提高内聚  降低耦合
    缺点：造成资源文件增多，管理不便
   
    SRP说的其实是类设计时的职责划分和粒度问题。
    在软件开发中使用SRP原则时，一个类承担一个职责，过多互不相关的职责集中在一个类中会导致高耦合性。
    但要根据具体的情况设计，避免因过度追求单一职责而将类的结构设计的过度复杂，过犹不及。
   
    策略模式，

2.OCP(开-闭原则)  (对扩展开放，对修改关闭) 即在不修改原码的情况下对其进行扩展。
    好处：提高灵活性、可重用性、可维护性
    难点：OCP的关键是抽象(抽象父类或接口)，创建正确的抽象花费时间和精力，也增加了软件设计的复杂性。
          正确的做法是 只对程序中频繁变化的部分做出抽象，拒绝不成熟的抽象和抽象一样重要。
         
   
    OCP是OO设计原则中高层次的原则，其余的原则对OCP提供了不同程度的支持
    对OCP的追求也应该适可而止，不要陷入过渡设计。
   
    策略，装饰器，模板

3.LSP(里氏替换原则) 任何基类可以出现的地方，子类一定可以出现。反之不成立。

    LSP是使OCP成为可能的主要原则之一。
    正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。
   
    附A：
    基于契约设计（DBC：Design By Contract）
        使用DBC，类的编写者能够显式的规定针对该类的契约。客户代码的编写者可以通过该契约获悉可以依赖的行为方式。
        契约是通过为每个方法声明的前置条件（preconditions)和后置条件（postconditions)来指定的。
        要使一个方法得以执行，前置条件必须要为真。执行完毕后，该方法要保证后置条件为真。
   
    附B：
    use-a 依赖  A与B use-a关系   A中持有B的实例，B实例是在A之外创建，通过传参被A使用，可以调用B的方法或属性。
        例如：我使用电脑。
       
    has-a 组合  A与B has-a关系   A持有B的实例，A负责B的创建。
        1.静态Has-A关系。这在UML中叫做组合（composition）
            例如：我有一双手
        2.动态Has-A关系。这在UML中叫做聚合（aggregation）
            例如：Ant-Team拥有5名成员。
           
    is-a  继承  A与B is-a 关系    B是A的父类
   
    工厂模式，策略，模板，装饰器

4.DIP(依赖倒置原则) 
    A.高层模块不应该依赖于低层模块。它们都应该依赖于抽象。
    B.抽象不应该依赖于细节，细节应当依赖于抽象
   
    缺点：将导致大量的类文件。给维护带来不必要的麻烦。所以，正确的做法是只对程序中频繁变化的部分进行依赖倒置
   
    附A：
    启发式规则:
    1.任何变量都不应该持有一个指向具体类的指针或者引用.
    2.任何类都不应该从具体类派生(始于抽象,来自具体)
    3.任何方法都不应该覆写它的任何基类中的已经实现了的方法.

    这个原则对于那些虽然具体但是却稳定的类来说似乎并不是很合适， 如果一个类不太会改变，
    而且也不太可能创建其他的派生类，那么依赖它似乎并没有太大的危害。比如java的String类。
   
    DIP的关键其实在于找到系统中“变”与“不变”的部分，并利用接口将其隔离。
   
    附B：
    IoC就是Inversion of Control，控制反转。
    在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。
   
    模板模式
   
5.ISP(接口隔离)
    使用多个专门的接口比使用单一的总接口要好。
    一个类对另外一个类的依赖性应当是建立在最小的接口上的。
    一个接口代表一个角色，不应当将不同的角色都交给一个接口。
    没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
   
    观察者模式

6.LKP(最少知识原则) 又叫迪米特法则(Law of Demeter),LoD
    一个对象应当对其他对象有尽可能少的了解,不和陌生人说话
    这是一个关于如何松耦合（Loosely-Coupled）的法则
    缺点：
　　    在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关
   
    用迪米特法则到系统的设计中时,要注意以下几点:
    * 在类的划分上,应当创建有弱耦合的类.类之间的耦合越弱,就越有利于复用.
    * 在类的结构设计上,每一个类都应当尽量降低成员的访问权限.
    * 在类的设计上,只要可能,一个类应当设计成不变类.
    * 在对其他类的引用上,一个对象对其他对象的引用应降到最低.
    * 尽量限制局部变量的有效范围. 
   
    例:门面模式

   
    米特法则又叫作最少知识原则（Least Knowledge Principle或简写为LKP），就是说一个对象应当对其他对象有尽可能少的了解。

 

如何实现迪米特法则

迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：

1) 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。

2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。

3) 在类的设计上，只要有可能，一个类应当设计成不变类。

4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。