设计模式六大原则_设计模式之六大原则-CSDN博客

总原则：开放闭合原则(Open-Closed Principle or OCP)

定义：开放闭合原则又叫开闭原则，即软件实体应当对扩展开放，对修改封闭。开闭原则就是指软件实体应当尽量保证在不修改原有代码的情况下，对软件进行扩展。开闭原则是面向对象设计的基石。

一、单一职责原则(Single Responsibility Principle or SRP)

定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。简而言之就是每个类只担任一个职责,即每个类只有一个引起它变化的原因。

二、里氏替换原则(Liskov Substitution Principle or LSP)

定义：所有引用基类的地方必须透明的使用其子类的对象。在代码中将基类对象转换成其子类对象，不应当产生任何错误或异常。里氏替换原则根据“运行时子类对象覆盖父类对象”的特点，可以很方便的对系统进行扩展，只需要增加子类而无需更改任何现有代码，即申明基类变量，实例化子类，并将变量当做参数使用。

三、依赖倒置原则(Dependence Inversion Principle DIP)

定义：高层模块不应该依赖低层模块，他们都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。面向接口(抽象)编程，不要面向实现编程。

四、接口隔离原则(Interface Segregation Principle or ISP)

定义：客户端不应该依赖它不需要的接口。一个类对另外一个类的依赖性应当是建立在最小的接口上的。接口功能最小化，每一个接口只负责与其自身相关的功能，防止功能过多导致的“接口污染”问题，符合接口隔离原则，并且有利于未来的扩展，同时符合开闭原则。

五、合成复用原则(Composite Reuse Principle or CRP)

定义：尽量使用对象组合，而不是继承来达到复用的目的。合成复用原则是鼓励优先使用对象的组合，而不是使用继承。

示例：

合成复用原则

以上这种设计将银行卡的大部分功能封装在抽象基类BankCard中，建设银行普通银行卡类CCBCard类继承这个基类，但是建行的普通银行卡显然没有透支功能，导致导致不得不为这个没有透支功能的银行卡添加一个默认的透支实现，这显然是不合理的。另外如果修改基类中任何一个功能，所有继承自BankCard的类可能都要重写，这显然也不符合开闭原则。转账方法使用BankCard类型的参数，显然不符合里氏替换原则。以下给出一个解决方案以供参考：

经过以上的代码改造之后，银行卡基类BankCardBase只包含银行卡的基本功能，银行卡接口ICard只包含银行卡相关的业务操作，而信用卡接口ICreditCard则只包含与信用卡相关的业务操作，相互之间没有影响，修改普通银行卡或信用卡的功能，不会影响到其它类型的银行卡的业务逻辑，符合开闭原则。转账方法使用基类参数BankCardBase，运用在“运行时子类对象替代父类对象”的特点，使得代码的可扩展性极高，符合里氏替换原则。在这个示例中，我们优先使用各种类和接口的组合来代替之前的单一基类的继承关系来打造普通银行卡和信用卡的功能，使得整个设计更干净利落，可维护性高，并且这些类和接口还可以被无限合理的复用，这就是合成复用原则。

六、迪米特法则(Law of Demeter or LoD)

定义：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过中间类(MeDiator)来转发这个调用。

示例：

购物类OnlineShopping包含5个方法，分别是添加至购物车、确认订单信息、结算付款、收货和购物，调用方Person类由于无法准确知道购物类的功能，可能会写出以下代码：

这个显然是不合理的，Person类的实例重复购物了。导致这种情况出现的原因是，购物类公开了本不应当公开的方法，而调用方却不知道这一情况，所以我们可以按以下方法重构此购物类。

购物类将无需公开的方法变成私有方法，并在Person类中维持对购物类的引用，这样可以很方便的调用购物类中的Shopping方法，并且由于访问级别的限制，Person类无法访问购物类的私有成员，不会生成重复购物的问题。但是Person类直接调用购物类，具有强耦合关系，根据迪米特法则，我们应当引用中间类来中转操作。于是我们得到以下代码：