设计模式基本原则

1.单一职责

  对于一个类而言，应该只有一个引起它变化的原因。

  对于一个类来说，只做这个类本身需要做的事情，例如类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。：

• 遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

  应当把不同的业务，拆分成独立的两个类。

适用于方法

   往往我们对用户信息修改的时候，通常会提供一个方法，这个方法参数为一个用户的实体对象，用户在进行修改信息的时候，全都调用这个方法修改。

其实这种方法不可取，这样会导致这个方法的职责不明确，到底是修改用户密码，还是手机，还是其他信息？

单一职责优点

• 类的复杂度降低、每个类的职责都有明确的定义
• 可读性高
• 复用性高
• 变更引起的风险低
• 可维护性高
• 提高代码的扩展性

2.开放封闭原则

  软件实体、对扩展开放、对修改封闭。面对需求，对程序的改动是增加新代码完成，而不是修改现有代码，例如策略模式(摘自大话设计模式),如果在有一种打折、积分只需要添加对应的子类就可以完成扩展，而不是修改现有代码！

开放封闭优点

  通过扩展已有软件系统，可以提供新的行为，用来满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。

  已有软件模块，特别是最重要的抽象层模块不能在修改，保证我们的系统具有一定的稳定性和延续性。

3.里氏代换原则

  子类必须能够替换他们的父类。（协变）

优点

  增强程序健壮性，增加子类不会影响原来的子类。

4.依赖倒置原则

  要依赖于抽象，不应该依赖于具体的某个类,应当面向接口编程，而不是面向实现。

原始译文

1.高层模块不应该依赖低层模块，两者都应该依赖其抽象

2.抽象不应该依赖细节

3.细节应该依赖抽象。

反面例子:

public void User()
{
    Role role=new Role();
}
public class Role
{
    public void Add()
    {
        ...
    }
}

缺点：耦合太密切，Role发生变化将会影响User类

优点

• 降低类与类之间的耦合。
• 插拔式设计提高代码的可扩展性
• 代码层次更加清晰

迪米特法则

  最少知识法则，一个对象应当对其他对象有尽可能少的了解。减少类与类之间的耦合。

接口隔离

  客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。

反例:

 public class user:Iuser
 {
     public void AddUser()
     {}
     public void AddRole()
     {}
 }
 public interface IUser
 {
     
     void AddUser();
     void AddRole();
 }

缺点：用户类只需要添加user相关的行为，不需要角色的行为，这种方式是不符合迪米特法则，应该user、role都建立独立的接口