设计模式6大原则

设计模式6大原则

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。可以说，设计模式是每一个架构师所必备的技能之一。想要精通设计模式，必须要先搞清楚设计模式的六大原则。

(1) 单一职责原则(Single Resoinsibility Principle，简称SRP)

不要存在多于一个导致类变动的原因

通俗地说就是，一个类只负责一项职责

其实在开发中，即使没有听说过单一职责原则的程序员也常常会遵守着一重要原则。其根本原因就在于，在开发中如果不做到一个类尽可能少承担模块中的功能，那么一个功能的变动，很可能就会引起其他功能的故障。

可以说单一职责模式是一种常识，但是并不是说所有的程序都必须遵循单一职责原则，遵守单一职责原则的本质是为了降低类的复杂度，当一个类只负责一项职责时，其逻辑在多数情况下要比负责多项职责更加简单。从而使得当程序需要变更时，可以显著降低对其他功能的影响

(2) 里氏替换原则(Liskov Substitution Principle，简称LSP)

在使用基类的的地方可以任意使用其子类，能保证子类完美替换基类

通俗来说就是，子类能够扩展父类的功能，但是不能改变父类原有的功能

继承作为一种提高代码复用性的办法，很多时候都在确保了代码的完整性的同时完成了功能的扩展，但是我认为继承不是作为提高代码复用性的最佳选择，不做过多的介绍，我会在以后的其他专栏中描述我的理解。

首先，继承了父类的子类方法具有父类中的非私有的属性和方法，也可以自己实现父类的方法，还可以拥有自己的属性和方法以达到对父类的扩展

但是继承也带来了一定的弊端。比如，当一个类需要被修改是时，必须考虑到所有的子类；比如，继承会使程序的可移植性降低。并且，由于多态的特性，使得我们在使用父类类型的子类时，不得不考虑子类无意中重写的父类方法对功能体系造成的影响

(3) 依赖倒置原则(Deoendence Inversion Principle，简称DIP)

高层模块不应该依赖底层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象

通俗来说就是，要针对接口编程，不要针对实现编程。通过抽象(抽象类或者接口)使得各类或者功能模块的实现彼此独立，以达到降低耦合度的目的

依赖倒置的在大型项目中尤为重要，相反在小型项目中很难体会到其重要性，甚至可能使得开发者觉得项目变得更加繁琐

(4) 接口隔离原则(Interface Segregation Principle，简称ISP)

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

建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用

如果接口过于臃肿，只要接口中出现的方法，不管对依赖以它的类有没有用处，实现类都必须去实现这些方法。

采用接口隔离原则时，虽然对接口的细化可以提高程序实际灵活性，但是如果过于细化则会造成接口数量过多，使得设计越发的复杂化。

(5) 迪米特法则(Law of Demeter，简称LoD)

一个对象应该对其他对象保持最少的了解

通俗地说就是，一个类对自己依赖的类知道的越少越好；不管被依赖的类逻辑有多么复杂，都尽量地将逻辑封装在类的内部，除了对外提供public方法，不对外泄露任何信息

(6) 开闭原则(Open Closed Principle，简称OCP)

一个软件的实体应当对扩展开放，对修改关闭

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有的代码进行修改时，可能会给旧的代码中引入错误，也可能使得我们不得不重构整个功能模块。

所以开闭原则的思想就是，当需要对原有的功能进行升级的时候，尽量不要变更其原有的类或者模块，而使用扩展的方式实现其新增或修改又或者维护