设计之禅-读书笔记

针对变化，针对接口，组合胜于继承

设计模式原则（SOLID）

1：单一责任原则（Single Responsibility Principle）

应该有且仅有一个原因引起变更--责任如何划分是个大问题，不要让别人猜测这个方法可能是原来处理什么逻辑的。

这就是专业化。

简洁就是美

单一责任原则是从业务角度的划分，若一类责任过多，可以分多个专门的接口！

      嘿，美女！---都回头了！

     嘿，穿裙子的美女！--部分回头了！

2：里氏替换原则（Liskov Substitution Principle）

上层能干的事，底层也可以干；反之则未必

枪可以杀敌，但是玩具枪就不行，其之间不能是继承关系！

上层可干，下层可干

3：依赖倒置原则（Dependency Inversion Principle）

底层的变动不影响上层--之间加一个抽象

下不影响上

4：接口隔离原则（Interface Segregation Principle）

建立单一接口，不要建立臃肿庞大的接口，接口尽量细化同时接口中的方法尽量少！

接口尽量简单

5：迪米特法则（最少知道原则）

类间关系尽量简单

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6：开闭原则（Open/Closed Principle）

对扩展（添加）开放，对修改关闭

能填不改！改还要读别人的代码。

基本的方法：分层（层与层之间才能通讯），模块化。

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

GOF将模式分为3类23种，但是要注意的是各种模式必然涉及模式元素及元素之间的关系（之间的作用，相互间的交互，动作等）；创建模式涉及到元素，涉及到关系（创建），结构模式则侧重于应该有那些元素，而行为模式则侧重于元素之间的关系。

这里的元素是指模块，功能单元等的意思，组成的成分等。

创建模式

1.建造者模式：做部件，在组合

”将一个复杂对象的构建与它的表示分类，使得同样的构建过程可以创建不同的表示“

材料（功能、动作）有限，但是其组合排列无限，每一套组合就重新写组合一遍？在材料（功能、动作）与组合之间加上一层建造者，由其实现组合，管理组合，而上层通知其采用何种组合。建造者中一般保存由一个队列，记录其组合。

机器人运动控制中有几种运动方式：直线、圆，旋转等，只有有限得几种，其不同得运动形式实际上其其不同得组合，那么就要构造一个建造者了：告诉它 先走直线、在走圆弧、在拐弯.....,将做直线、圆弧、拐弯等和先干什么、在干什么分开，建造者中维护一个队列，这个队列中时其动作序列--有点像《游戏人工智能案例精粹》第九章目标驱动智能体行为中得层次化目标方式。

画1千匹不同的马！怎么办？首先画一皮，然后，改耳朵：长的，短的，方的、圆的....,然后改腿：....这就简单了！

这让我想到了这次的疫情：过年的那大半个月，没法买菜，家里有效的材料如何做出不同的花样，每天每顿菜不重样，可费了老劲了！实际会做的菜就那么几样，每次搭配改几个，又是一道新菜。至少说孩子没觉得家里没菜了，花样挺多，他吃得还挺开心，没有腻得慌。

2.原型模式：作弊模式，做一个样子，再修改

"用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象"

3.工厂模式：找个人给我做

土豪模式：太多了，记住名字即可

4.抽象工厂模式：找很多人，帮我做不同东西

超级土豪模式：仅仅记住名字还不够，在分类吧

5.单例模式：用到很少，大家合伙用吧

土豪也撑不住啊

结构模式

1.适配器模式--想想外国老板-翻译--我

“将一个类的接口变换成客户端所期待的接口，从而使原本因接口不匹配而无法在一起的两个类能够在一起工作。”

圆形和方形如何组合在一起?加入第三者：适配器。适配器一头是方的，一头是圆的。不过这个适配器可不好做！

异构如何配合？

2.组合模式--各个部门

"将对象组合成树形结构以表示部分-整体的结构层次，使得用户对单个对象和组合对象的使用具有一致性"

就是树形结构

但是叶子和节点是一样的

组合模式中的角色：

抽象构件：定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性

叶子构件：叶子对象，其下再也没有其他的分支，也是遍历的最小单位

树枝构件：树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。

为什么叶子和树枝不合并？在数据结构课程中它们和在一起啊？

作者认为叶子节点尽管简单，但是“它是每个树枝节点的代表，相同扩容的时候你就会发现它是多'栋梁'”。目前还没啥体会。

3装饰器模式：动态地给一个对象添加一些额外的职责。比生成子类更为灵活。

面向对象的设计中，如果超过两层继承，你就应该想想是不是出设计问题了，继承层次越多以后谓的维护成本越多。

4享元模式：池技术的重要实现方式。”使用共享对象可有效地支持大量的细粒度的对象。“

大家能共享使用的就共享使用，每人一个太浪费资源，单例模式是享元模式的一种极端。

小车班

5.桥接模式：单位秘书就是这个角色，不管收到的是电话、微信、电报还是口头通知，都要转化为领导能够理解的信息，也要把老板的意思转化成其他部门能够理解的意思，他就是老板和外界的桥梁。

“将抽象和实现解耦，使得两者可以独立地变化”。“因为可能希望多个用户界面对应一个操作（例如，你既可以用一个页按钮，也可以用一个菜单项来表示翻页）。你可能以后也会改变界面。”（GOF）

一对一模式变为多对一模式

我希望实现一个功能：可能采用语音、键盘、手术、鼠标，如果每一个都实现一边的化就把人搞死了，可以把上述信息都转化为一个信息INFO，然后对INFO处理就简单多了

秘书

6.外观模式(门面模式）：”要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。“

邮局代发广告信（你告诉我发给谁，内容是什么就可以了，打印信封、粘信封、邮寄等工作交给我），快递公司代发货(发什么货、发给谁你告诉我就行了，打包、邮寄、仓储都有我来完成)。

很像代理模式

办公室

7.代理模式:后勤部分，所有杂事就交给他办了，怎么办，老板不管，只要干出来就行，老板只享受结果！代理打游戏、游戏外挂等

“为其他对象提供一种代理以控制对这个对象的访问”

许多其他的模式本质上是在更特殊的场合采用的代理模式。

代理模式也叫委托模式。

这种实际是生活中的中介模式，将一对多的方式变为一对一对多，中间的就是代理。被代理人省事了。

国外的代理人和我们的意思不一样，中国好像很少说代理人的这句话，代理人是代表”我“的利益，中介只是撮合，中国的房产中介好像也不是完全的中介的意思。

私人助理

行为模式

1.中介模式

“用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。”

这个中介模式是将网站结构变为星型结构，中心的”星“就是中介，这是将多对多变为多对一对多结构

在设计之禅中举了一个采购-销售-库管的例子，这三者是互相联系的，修改一个就要改一片，为进一步说明，还举了采购-销售-库管-物流-资产-供应商管理的例子，整个就是一张蜘蛛网。这时候就有必要加入一个第三者：中介者。参与方不再互相交流，要交流就通过中介者，每个参与方之复杂自己的业务逻辑，不属于自己的则丢给中介来处理，简化了结构，降低了各部分之间的耦合。

从另一方面来说，中介模式也是一种代理模式。对某一参与方来说，其从一对多变为了一对一对多。

linux设备驱动中的总线，比如platformbus

2.状态模式

“当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类”

有点像"状态机模式",但是要比状态机更复杂，适用范围更广，可以说状态机使状态模式的一种实现。适用的场合就是有大量的判断if-else或swith-case，在什么样的状态下只能做什么等等。

此处涉及3个角色，环境角色，抽象状态角色，具体状态角色

环境角色：定义客户端需要的接口，并且负责具体状态的切换（FSM.update）

抽象状态角色：负责对象状态定义，并且封装环境角色以实现状态切换FSM

具体状态角色：每个具体状态必须完成两个职责-本状态的行为管理以及趋向状态处理，通俗地说就是本状态下要做的事情，以及本状态如何过渡到其他状态。（state）

3.责任链模式

"使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关心。将这些对象连成一条链，并沿着这条链条传递改请求，直到有对象处理它为止。“

一个请求有多个对象可以处理，或处理其中一部分，请求者可以到处理者处一个一个问：一对多的关系。

也可以这些处理者排成一排，前一个处理完可以向下传，或将结果返回给上一个处理者，而请求者只需面对第一处理者：一对一关系。

书中用女人的“三从四德”来分析，有趣！

有点像首问负责制。有人说责任链模式是击鼓传花，这也不错！

4.命令模式

有点像司令员指挥作战，其可以直接指挥到每个部队，布置任务，比如：独立团打下碾庄，但是这样司令累，下面的部队也累；另一种方式就是司令发布命令：消灭敌人，打下碾庄。然后由参谋长负责安排部队执行任务，司令负责宏观战略，参谋长负责调兵遣将，基层部队负责执行。这样司令换了没关系，部队换了没关系，甚至参谋长换了也没关系，请求方与执行方分开了，扩展性也有很好的保障。一对多，变成了一对一对多。有点像代理模式和责任链模式

5.模板模式

”定义一个操作在的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。“

Linux中是否就体现了模板模式的思想？其VFS系统表现尤为明显。Linux中”一切皆文件“，不管是普通的数据文件也好，还是复杂的设备文件，其接口都是open、read、write...但是底层的实现各不相同。一套方法解决所有问题。

封装不变部分，扩展可变部分，提取公共部分代码，行为由父类控制，子类实现。

上层实现公共部分，下层实现差异部分。

公共部分上提，细节下沉！

缺点：难以阅读理解-下层影响上层结果，拐的弯道太多----Linux内核中的体现就是指针到处飞！