设计模式六原则解析-CSDN博客

本文链接：https://blog.csdn.net/wzh402/article/details/44131743

设计模式这本书已经看完了，但是感觉自己对于这本书的理解还是“不识庐山真面目，只缘身在此山中”的感觉，在看书的过程中就属开始看和最后看的时候纠结了。刚开始时，还没有感觉，理解前两个模式就费了大劲；看过一两个例子以后感觉有点入门了，下面再看就如行云流水般；到了最后，这本书的总结部分，看过以后又是晕头转向，感觉自己的理解不到位。我知道这不是终点，仅仅是设计模式的一个开始。

师傅告诉我，学习设计模式分三个阶段：1、初级阶段：理解这敲代码，但不会用。2、中级阶段：分析实际问题，知道套用哪个设计模式。3、高级阶段：灵活运用设计模式来解决问题。很显然，估计自己连初级阶段的水品都达不到。设计模式中让我感觉最难的就是类与类之间的调用了，经常调来调去，一会儿自己就陷入了漩涡之中，跳进去就出不来了。当然了，说这些只是表达个人的感受，这是每个人的必经阶段，别人都过去这个坎了，自己为什么不行呢！于是乎，自信心油然而生。

设计模式中的六芒星

大话设计模式这本书讲了六大原则和23个设计模式，就好像父亲和孩子的关系一样，23设计模式体现了六个原则，有分别有着自己不同的特点。这么说起来，感觉好像继承似的。今天就先看看设计模式中的”六芒星“吧，他们各有特色，但都是为面向对象而服务的。

首先是一张简单的导图：

单一职责原则：顾名思义，单一职责就是类的功能尽可能的唯一，就是说，一个类在设计的时候要考虑以后是否有其他原因会导致类的内部发生改变，应该仅有一个引起这个类变化的原因，如果有其他原因导致类的改变，则说明这个类多与一个动机去改变类，这个类就多于一个职责，需要进行职责分离。就拿手机做例子，手机的照相功能和摄像机的照相功能，肯定是没法比的。但手机的功能需求决定了他要这么做，即能接听电话、又能照相、还能听音乐。手机的发展有它自己的特点，编程中要在职责分离上多思考，尽量做到职责单一，但还是要在用户需求的基础上来分析。视情况来使用！

开放-封闭原则：开放封闭原则是面向对象设计的核心所在。遵循这个原则可以实现面向对象中的可维护、可扩展、可复用和灵活性好的优点。对于扩展是开放的，对于更改是封闭的。但是绝对的对修改关闭是不可能的，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。这就需要设计人员在设计之初就尽可能的猜测出最有可能发生的变化，然后通过抽象来隔离那些变化。也就是说，对于程序的改动是通过增加代码进行的，而不是更改现有的代码。

依赖倒转原则：依赖倒转是面向对象设计的标志。它告诉我们高层模块不应该依赖低层模块，两个都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。说白了吧，就是要我们面向接口编程，不要对实现编程。让我记忆最深刻的观察者模式就是遵循了这一点，该模式举了前台小姐监督老板的例子。其中抽象出了“抽象观察者”和“抽象通知者”。这样就避免了前台小姐直接和观察者的交流，达到了解耦合的作用。

里氏代换原则：子类型必须能够替换掉它们的父类型。说白了，就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。有一个例子，在面向对象设计时，一个是鸟类，一个是企鹅类，鸟是可以飞的，但企鹅不会飞。那么企鹅继承鸟类就是一个错误的例子。真是因为这个原则，使得继承复用成为了可能。

迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的互相作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。在类的设计上，每一个类都应当尽量降低成员的访问权限，也就是一个类要包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。迪米特法则的根本思想就是强调了类之间的松耦合。类的耦合越弱，越有利于复用，这样类在被修改的时候，不会对有关系的类造成波及。也就是说信息的隐藏促进了软件的复用。

举个例子：如果需要找IT管理部的人员修电脑，那就不应该指派给IT部中的某个人去修，如果这个人不在的话，别人是不会主动去修的。这时就应该找IT部中的主管，把主管当做接口，让主管去安排人去修理，至于安排谁，你不用关心。

合成-聚合功能：尽量使用合成/聚合，尽量不要使用类继承。优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。为什么要少用继承呢，因为如果子类太多，继承的层次会变得特别多，那就会造成子类和父类之间的耦合度非常高，一旦父类改变那么子类也会受到影响，使得代码可维护性和可扩展性变低。