设计模式学习笔记（0）-设计原则

对于设计模式，我一直认为在开发过程中是比较重要的。学习设计模式，有助于使代码的架构更合理，提高开发的效率。

之前，曾经看过设计模式的书籍，但是看完就忘，现在想想，可以通过写博客的形式一方面让自己的学习不中断，另一方面能在学习时，对所学的东西做一个总结。

学习设计模式，其实设计的原则也是挺重要的。设计的原则在设计模式中也能很好的体现。

今天就先记录一下学习的设计原则的内容。

-------------------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------正文：设计原则-------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------

设计原则：
1、单一职责原则
定义：就一个类而言，应该只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其他的职责。
理解：单一类的的功能要简单。以人员操作类为例，这个类的功能就是人员增删查改。如果要增加人员的其他操作，可以通过继承来实现。毕竟多数的功能的基本就是增删查改而已。


2、开闭原则
定义：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化是，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。
符合开闭原则的最好方式是提供一个固有的接口，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。
理解：这点在后台服务开发的时候，体现的比较明显。比如，某个接口服务因为一些原因，需要修改参数或者返回值，这时候需要新增一个方法，重新定义参数和返回值，而不是修改原有的方法。尤其APP的后台接口，如果修改原有方法会影响旧版本的使用。


3、里氏代替原则
定义：Liskov Substitution Principle,LSP(里氏代替原则)指的是子类必须替换掉他们的父类型。也就是说，在软件开发过程中，子类替换父类后，程序的行为是一样的。只有子类替换掉父类后，此时软件的功能不受影响时，父类才能真正的被复用，而子类也可以在父类的基础上添加新的行为。
理解：这点其实也是和开闭原则想符合的。不去修改任何软件实体，包括父类，可以扩展而不是去修改。当然前提是父类的设计是合理的前提下。
我们在设计过程中，一定要谨慎的去进行每个类的设计。不然如果修改某个父类，那引起的麻烦就很大了。


4、依赖倒置原则
定义：依赖倒置（Dependence Inversion Principle, DIP）原则指的是抽象不应该依赖于细节，细节应该依赖于抽象，也就是提出的“面向接口变成，而不是面向实现编程”。这样可以降低客户与具体实现的耦合。
理解：这个针对的是抽象的原则。也可以理解为抽象是基于共性抽象，而不是基于某个个性抽象。其实也可以理解为3中的意思。抽象一旦定义，就不能去修改了，不然会给其他的继承带来麻烦。
比如著名的白马非马的故事，马是共性，马的特点有很多，比如四条腿，有蹄子，有尾巴，善于奔跑，脸是长的等等，但是如果把白色也作为马的抽象，那就没法扩展了。


5、接口隔离原则
定义：接口隔离原则（Interface Segregation Principle, ISP）指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。
理解：这个原则符合单一职责原则。最底层的接口功能一定要简单。如果实现复杂的功能，那么这个功能，可以说不会是普遍使用的。接口的简单更加有利于功能的扩展。比如表头的新增方法和明细的新增方法，在设计时一定要分开。如果要实现某一单据的新增，调用表头和明细的方法即可，而不需要把表头和明细新增的实现过程再写一遍。这样，有利于代码的简洁性。


6、合成复用原则
定义：合成复用原则（Composite Reuse Principle, CRP）就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。
理解：其实，我也对这句里的尽量不要使用继承比较疑惑。继承肯定有一定的好处，子类可以拥有父类的所有属性。什么时候使用继承才合适呢？
在网上找了一下这个原则的资料，这个说法我感觉还是挺不错的：
-------------------引用自http://www.cnblogs.com/shaosks/archive/2012/02/08/2342593.html---------
只有当以下的条件全部被满足时，才应当使用继承关系。
         1. 子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分“Has-A”和“Is-A”.只有“Is-A”关系才符合继承关系，“Has-A”关系应当使用聚合来描述。
注解：白马才能继承马这个类，而龙有马一样的脸只是拥有马的其中一个属性，这时候就不能继承马类了。


         2 .永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。
注解：白马可以继承马这个类，要是四不像，开始看着像马，但是看着又想别的生物，不确定的情况下，就不能使用继承了。


         3 .子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。
注解：继承是为了更好的使用父类，如果要改掉父类的多数东西，那使用继承也就不好了。
-----------------引用完毕----------------------------------------------------------------------


7、迪米特法则
定义：迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。


　　关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。


理解：迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
    迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。


下边这段内容，我认为有助于加深对这一原则的理解：
-------------------引用自http://www.cnblogs.com/wisdo/p/4178723.html-----------
 在运用迪米特法则到系统的设计中时,要注意以下几点:
     第一：在类的划分上，应当创建弱耦合的类，类与类之间的耦合越弱，就越有利于实现可复用的目标。
    第二：在类的结构设计上，每个类都应该降低成员的访问权限。
    第三：在类的设计上，只要有可能，一个类应当设计成不变的类。
    第四：在对其他类的应用上，一个对象对其他类的对象的应用应该降到最低。
    第五：尽量限制局部变量的有效范围。
---------------------引用完毕---------------------------------------------------

下周，将开始对具体的设计模式进行学习。

知行办公，专业移动办公平台 https://zx.naton.cn/
【总监】十二春秋之，[email protected]；
【Master】zelo，[email protected]；
【运营】运维艄公，[email protected]；
【产品设计】流浪猫，[email protected]；
【体验设计】兜兜，[email protected]；
【iOS】淘码小工，[email protected]；iMcG33K，[email protected]；
【Android】人猿居士，[email protected]；思路的顿悟，[email protected]；
【java】首席工程师MR_W，[email protected]；
【测试】土镜问道，[email protected]；
【数据】fox009521，[email protected]；
【安全】保密，你懂的。