设计模式就该这样学（手撸golang 行为型设计模式 委派模式）

本文目录

• 手撸golang 行为型设计模式 委派模式
• 设计模式—关于提高可扩展性（方法层面）的学习（更加从容的应对需求变更）
• 大家对于学习C#设计模式有没有好的建议
• 求教，设计模式什么时候学习啊
• 如何学习设计模式

手撸golang 行为型设计模式 委派模式

最近复习设计模式
拜读谭勇德的《《设计模式就该这样学》》
本系列笔记拟采用golang练习之

委派模式（Delegate Pattern）又叫作委托模式，基本作用就是负责任务的调用和分配，是一种特殊的静态代理模式，可以理解为全权代理模式，但是代理模式注重过程，而委派模式注重结果。
委派模式有3个参与角色。
（1）抽象任务角色（ITask）：定义一个抽象接口，它有若干实现类。
（2）委派者角色（Delegate）：负责在各个具体角色实例之间做出决策，判断并调用具体实现的方法。
（3）具体任务角色（Concrete）：真正执行任务的角色。
_

delegate_pattern_test.go

定义消息接口

消息的基类, 实现IMsg接口

表示原样返回的消息, 用于PING/PONG心跳. 继承自BaseMsg

表示获取服务器时间的消息. 继承自BaseMsg

消息处理器接口. 调度器和具体消息处理器, 均需要实现此接口.

全局消息调度器, 是所有客户端消息的统一入口. 用于注册消息处理器, 按类型分发消息. 实现IMsgHandler接口.

专门处理EchoMsg消息的处理器. 实现IMsgHandler接口.

专门处理TimeMsg消息的处理器, 实现IMsgHandler接口.

委派模式的优点
通过任务委派能够将一个大型任务细化，然后通过统一管理这些子任务的完成情况实现任务的跟进，加快任务执行的效率。
委派模式的缺点
任务委派方式需要根据任务的复杂程度进行不同的改变，在任务比较复杂的情况下，可能需要进行多重委派，容易造成紊乱。
_
(end)

设计模式—关于提高可扩展性（方法层面）的学习（更加从容的应对需求变更）

设计模式——关于提高可扩展性的学习。

方法是组成程序的基础单元，基础单元的可扩展性是整个程序的可扩展性保障，可扩展性顾名思义是保证代码、程序能够更好地进行扩展。再厉害的程序员都会写bug，再好的产品经理都会改需求。

在遇到需求变更的时候不能总是跟产品硬怼，一个好的程序员需要随时做好改需求的准备，不要遇到问题就想着砍死产品经理，先思考是不是因为自己的代码可扩展性方面没做好，所以导致改需求才这么难。改代码的时候难免会发现之前的代码思考得不够全面，在这个过程中写第一行代码的时候稍微注意一下可扩展性，就可以极大地减少后面修改代码的难度。

提高可扩展性的目的？

面临需求更改时，方便更改需求。

减少代码修改的难度。

什么是好的可扩展？

1、当发生需求变更的时候，不需要把之前的所有代码推倒重写。好的可扩展性组成的程序就像一块橡皮泥，当你要改变的时候只需要重新捏一下形状即可。

2、代码修改不会引起大规模变动。很多人在改代码的时候改了一个bug引起十个bug，按理来说改一个问题只需要加一个解决问题的代码就行了，但因为前期代码设计的不好，导致要修改很多之前的代码才能让这一个功能的代码加上去，这样就会引起大规模修改。

3、方便加入新模块。从模块的角度讲，比如产品要加一个新模块的时候，我们整个模块之间的组合就像积木一样，加入一个新模块就像加入一个新积木，拼上去就完事了，这样加入整个模块就非常方便。

一、提高可扩展性的设计模式

1.1.更好地更改代码的设计模式

这两种模式都是为了让我们更好地更改代码，它们更像是一种技巧，当我们的方法需要变更的时候能够让我们更好地进行变更。

1.1.1.适配器模式

适配器模式：适配器顾名思义，就是用来做适配的，比如我的电脑只支持typeC的耳机，但是我现在只有圆孔的耳机，我要用圆孔的耳机插上电脑来听歌怎么办？第一种方案就是买个typeC的耳机，但是买新的太贵了不划算，所以第二种方案就是买个转接头，把圆孔的耳机转接成typeC的，这个转接头就是适配器，适配器模式针对的是调用的接口的名字产生了不通用的问题。

目的：通过写一个适配器，来代替直接替换老代码。

应用场景：当接口不通用的时候解决接口不通用的问题。比如我们要调用一个a接口，但实际上这个接口名叫b，两个接口就不适配了，这时候肯定不能把a改成b，改了就相当于重写源代码了，通过写适配器，把a接口适配到b接口就不用去改写老代码了。

1.1.2.装饰者模式

装饰者模式：装饰者模式针对的是方法本身的作用，当一个方法的作用不够用了，需要添加新功能，但是又不能直接去修改之前的方法，使用装饰者模式就能更优雅地扩展我们的方法。

目的：不重写方法的扩展方法

应用场景：当一个方法需要扩展，但又不好去修改方法。

1.2.解耦方法与调用的设计模式

1.2.1.命令模式

命令模式：命令模式针对的是代码设计，命令模式的使用是在设计方法的时候，而不是更改方法的时候，设计之初就要开始考虑这个模式

目的：解耦实现和调用，让双方互不干扰

应用场景：调用的命令充满不确定性时，可以考虑使用命令模式。（功能比较单一的时候不要使用，命令层要写很多代码，增加复杂性）

什么是实现？实现就是方法的功能，比如我们有一个a方法，a方法里面的操作就是实现，而调用就是直接调用a()

什么是解耦实现和调用？像上面代码示例中定义a方法和调用a方法相当于：调用》方法，而命令模式相当于在调用和方法之间加上一层命令层：调用》命令层》方法，调用时不用直接去调用方法，而是通过输入命令输入到命令层，然后由命令层来解析命令再去调用具体方法：命令》命令层》方法

这样做的好处是：

1、对比于之前直接调用》方法，通过命令层来调用就不需要关心具体应该调用哪个方法，也不用去了解有哪些方法，只需要关心输入的命令就好

2、对比于之前直接调用》方法，之前的方式使用方法的人和方法本身是直接的关系，而在中间加入命令层之后，方法本身和要用方法的人就解耦了，这个时候方法就算发生变动，不用说命令也要跟着变动，只需要在命令层中改变一下对命令的解析即可，所以说方法的变动就不会影响到命令。同样的，当命令发生变化之后也不会影响到方法，中间都有一层命令层来作为缓冲，我们可以在命令层做一个调配和调度，这样它们双方发生变动都不会影响到彼此。

3、我们写代码其实就相当于命令模式，写好的代码最终在电脑上是怎么用二进制执行的不需要我们关心，只需要关心我们输入的代码就好，输入的代码就像命令，解析器V8引擎相当于命令层，它负责把命令解析成计算机能够执行的二进制语言，方法本身就是计算机去执行的代码。为什么要把写代码变成命令模式？因为编程的方向是多元化的，有可能编写成任何一个效果，可以编写很多效果，所以采用命令模式非常合适。

二、基本结构

2.1.适配器模式的基本结构

需求：每次都写console.log太麻烦了，项目里要用log来代替console.log。

适配器模式使用非常简单，就是在新接口里面调用老接口，适配器模式的应用场景就是在接口不通用的时候做个适配器，解决这个需求只需要在log函数中调用console.log就可以了。

2.2.装饰者模式的基本结构

需求：有一个他人写好的a模块，内部有一个方法b，不能修改他人模块的情况下，扩展b方法。

装饰者模式三步走：

1、封装新方法。

2、调用老方法。

3、加入扩展操作。

所以我们新建一个自己的方法，在其内部调用b方法，然后加入要扩展的功能，这样就可以在不修改原对象的情况下扩展b方法的功能了，代码示例：

2.3.命令模式的基本结构

代码示例：

上面代码创建一个匿名自执行函数，函数里面有一个action，它是方法的实现，excute就是我们的命令层，通过这个匿名自执行函数拿到的command就是命令层，要调用action里面的方法时，通过给command输入命令，这些命令就会在excute命令层进行解析来调用action里面的实现，使用者不需要关心具体要调用action里面哪个方法。

命令模式有两个要素：

一个是行为action

一个是命令执行层excute

三、应用示例

3.1.适配器模式的示例

3.1.1.框架的变更

需求：目前项目中使用A框架，A框架和jQuery非常类似，但是A框架对进公司的新人很不友好，新人进入团队还需要学一下这个框架的使用，所以现在要改成jQuery，这两个框架虽然时分类似，但存在少数几种方法不同。

比如在jQuery中css的调用是$.css()，而在A框架中是A.c()，在jQuery中绑定事件是$.on()，而A框架中是A.o()，这就是问题所在，如果这两个框架中的方法名没有任何不一样的话，直接把A赋值为jQuery就OK了，现在存在方法名不一样，直接把jQuery赋值给A就会导致旧代码中调用A.css(）报错

解决这个问题很多人的处理方式是一个个去找这些方法改掉，过程很明显就是重写老代码，这就是典型的适配器应用场景，我们只需要写一个适配器，不用改动老代码，让这两个接口名能够适配就好了。根据适配器模式的步骤，在新接口中调用老接口即可，代码示例：

3.1.2.参数适配

需求：为了避免参数不适配产生问题，很多框架会有一个参数适配操作。

在JavaScript中，健壮性非常重要，健壮性的基础保障就是判断参数类型赋予默认值，比如通过typeof判断，这种判断对于简单的数据类型是好使的，但如果参数是一个配置对象怎么办？比如Vue，在new Vue时传入的不是一个简单的参数，而是一整个的配置对象，它里面包含了很多内容，如template、data、methods等等，这些内容里面肯定会有一些内容是必填的，比如template、data，像这样一个对象怎么去保障别人使用的时候传的配置对象里面该必填的都必填呢？

如果使用typeof判断只能判断这个配置参数是一个对象，但是配置参数里面的东西有没有必填判断不出来，对于这样的配置对象形式的参数，我们最好给它做一个参数适配，参数适配就可以理解为适配器模式的变更，当你遇到一些方法它接收的参数是一个配置对象的时候，一定要养成一个习惯，给这个配置对象做一个参数适配，怎么去保障它里面必传的参数都传了呢？很简单，在函数里面写一个默认的配置对象，在这个默认的配置对象中将必传的属性都写上，比如name属性必传、color属性必传，代码示例：

然后当参数传进来的时候先不急着操作，先做一下适配，循环这个参数，如果传入的参数自身有必专项就用自身的，否则就用默认的代替，这样就保障了必专项起码会有一个默认值，不会因此报错。

当你写的方法要接收的参数是一个配置对象时，就通过这种参数适配的方式去保障必传的参数都有值，这是一个好的习惯，在工作中一定要保持。

3.2.装饰者模式的示例

3.2.1.扩展已有的事件绑定

需求：项目要进行改造，需要给dom已有的事件上增加一些操作。

假设你进入一家新公司，接手了前同事的代码，他在dom上绑定了很多事件，比如删除按钮绑定了点击事件，点击就进行删除操作，你接手之后产品跟你说觉得之前这种点击就删除没有提示的方式不太友好，需要你在点击确定或者删除的同时给出一个提示，这时候你会怎么做？

很多人会这么做

1、不去找他之前的代码写在哪了，直接重写整个绑定事件。

2、找到老代码，然后改一下。

这两种方式都是错的，如果采用第一种方案，势必要把它之前的删除功能代码再写一遍，非常麻烦，如果采用第二种方案，去找老代码这个找的过程也很麻烦，最好的方式就是采用装饰者模式，装饰者模式是用来干嘛的？就是当你发现一个方法它的原功能不适用、要扩展，但你又不能直接去修改原方法的时候就可以派上用场了。

所以我们用装饰者模式来做这个事情，考虑到要做这个事情的按钮有很多，就不一个个装饰了，采用工厂模式的思维，直接封装一个装饰工厂，使用时告诉我你要装饰哪个dom，要扩展什么操作就可以了，代码示例：

上面代码中，首先出于健壮性考虑，先判断一下dom上面有没有绑定事件，有的话再装饰，没有就不管。根据装饰者模式三步走：

1、封装新方法。

2、调用老方法。

3、扩展新功能。

先给click事件赋值为新方法，提取出dom的老方法，然后在click事件的新方法中调用老方法，然后加入我们要扩展的操作。

在使用的时候比如说要装饰删除按钮，然后要扩展提示功能，删除之后打印删除成功，这样既不用去找老代码也不用去重新写整个事件绑定，只需要调用装饰工厂就好了，扩展起来的速度就快多了。

3.2.2.Vue的数组监听

需求：Vue中使用defineProperty可以监听对象，那么数组监听是怎么实现的？

vue响应式面临一个困境，整个vue2里面双向绑定是用defineProperty来实现的，而这个方法针对的是对象的某个属性，对于数组而言，实现双向绑定比较困难。你会发现，在vue2里面直接修改数组下标是没办法触发响应式的，所以vue重新封装了数组的方法，如push、replace、shift等等，通过调用这些方法来触发数组的响应式，怎么让数组的方法能够触发响应式呢？尤雨溪是这么做的：

数组的方法是原生方法，对于设计原则来讲，不能够直接进行修改，所以尤雨溪利用装饰者模式扩展的原生的数组方法功能，使其能够触发响应式。代码示例：

首先把要装饰的方法名放进数组，到时候直接循环数组生成方法就可以了，不用一个个的改动，例如将push、pop、shift等进行扩展

在循环开始前先获取一下数组的原型链，因为到时候要装饰的方法全都在原型链上，但是不能直接修改原型链上的方法，所以先拷贝一份

循环数组，拿到我们要装饰的方法名，然后把我们要装饰的方法重写于拷贝对象上，装饰者模式三步走，①重写新方法②调用老方法③扩展新功能；这里的新功能就是调用dep.notify(）来触发vue的响应式，这个方法封装在vue的源码里面

最后就是将重写的arrayMethods对象给到vue的data上面所有数组原型链上，这样data里面的数组原型链上的push等方法就有了触发响应式的功能，它也不会影响到原生的数组和方法。

前面两种设计模式都是指导我们更好的扩展方法，而命令模式是指导我们更好的设计方法。

3.3.命令模式的示例

3.3.1.绘图命令

需求：封装一系列的canvas绘图命令

canvas画图比较困难，用过canvas的人都知道，canvas提供了点、线等api，绘制图形需要一个个点连接，很麻烦，为了更方便地使用canvas画图，就有大牛对canvas进行封装，提供了一些画图形的api，这样比较方便。

假设我们自己封装一个canvas，提供画圆和画矩形两个api，如果不用命令模式，代码可能会这样写：

上面代码适用于固定的状态，比如只调用api画一个图形或者两个图形，但整个canvas的行为是不能够固定的，它可能会需要画n个图形，这就很符合命令模式调用命令充满不确定性的场景，使用命令模式改写如下：

代码中首先创建命令模式封装，定义好实现层，返回命令层，命令层接收具体的命令，然后跟使用者约定好传什么命令，比如传一个数组，数组中包含要画的图形，假如要画两个圆，数组格式为。命令层负责解析具体的命令，自动调用实现层里面的方法来完成功能。

而在使用者的角度，使用者只需要调用canvasCommand传入相应的命令即可完成功能，他不用去关心有哪些api，这样就实现的方法与调用的解耦。其实webpack就是一个封装的命令模式，要使用webpack的某个功能，不需要去了解webpack要调用哪个api，只需要在配置中配置一下要使用的功能就可以了。

3.3.2.绘制随机数量图片

需求：做一个画廊，图片数量和排列顺序随机

这是一个典型的不确定性应用场景，使用命令模式来封装非常合适，代码如下：

首先创建命令模式的结构

然后约定一下命令，首先格式是一个对象，对象中有一个imgArr数组，这个数组存放图片内容，还有一个排序方案字段，假设用type字段，normal为正序，reverse为倒序，还有一个target属性，这个属性代表创建好的图片要插入到哪个元素里面。

命令约定好之后搭建实现层的架子，假设有一个创建html结构的create方法，一个显示的方法display。display方法接收要创建的东西，通过create方法创建一个html结构并插入到target当中。create方法先不写，先看命令层，命令层接收的是一个对象，对于对象格式的参数我们最好先做一下参数适配防止不必要的错误；然后调用action.display方法传入参数。

然后补充create方法，这个方法的作用是生成html字符串，字符串生成可以采用类似vue的模板引擎来完成，这里做个简单的示例：

这种组织方式的好处在于：

1、对使用者而言不需要了解调用哪个api，只需要输入命令即可完成功能。

2、对于代码变更而言，假设命令变了只需要在命令解析层更改一下解析方式就好了，不会影响实现层，同理，如果实现层变了，也不会影响到命令层，只需要更改一下解析就好了。

3.4.小结

当面临两个新老模块间接口api不匹配，可以用适配器模式来转化api。

当老的方法不方便直接修改时，可以通过装饰者模式来扩展功能。

使用命令模式解耦实现与具体命令，让实现端和命令端扩展的都更轻松。

大家对于学习C#设计模式有没有好的建议

说一下自己的感受吧，希望对你有用。
1、可以先了解一下所谓的23种设计模式，但开始时并一定要用到自己的项目当中。
2、要独立或对某个项目有很好的了解，在参与项目时，允许自己走一些弯路，但要有思考，在保证正常工作的情况下，让自己更少的去维护自己的代码，提高自己代码的重用度，就是别让代码左右自己
3、回过头来再学习设计模式，一边对照自己的项目一边学习，同时考虑自己项目当中有哪些需要优化，哪些可以更合理一些，但并不要求能马上改。但在这次学习后，要时刻提醒自己，以后写的代码能尽可能的向设计模式上靠
4、此时在是在一边学习一边向设计模式上靠，允许自己的代码对设计模式的错误使用
5、活学活用，即脱离设计模式，发挥一些自己总结的经验去做项目，此时自己已经有一定的基础，这时可能做出的东西，就相对不错

现在自己也在学习这个设计模式，在一边做项目一边思考，怎么对项目进行优化，整理，怎么在下次写代码时设计的更合理。还要再去学习设计模式。
有个建议：
找个较好的开源项目去学习，画出其中的UML类图，并且学习其中的优秀写法，同时还要对面向对象有一定的了解。接口、抽象类、组合关系、聚合关系、封装、继承、多态，真的要了解了之后对设计模式才能理解的更好。

求教，设计模式什么时候学习啊

1. 应该怎么学习：自己要学会总结，积累设计开发经验。设计模式都是在经验中获得的。

2. 2. 什么时候学：这个要看个人的想法，如果想在这一行深造，有所建树，当然是越早学习越好了！

3. 3. 要什么基础作为前提：需要具备一定的设计、封转以及抽象的思想。学会接口编程，接口隔离解耦等。

4. 4. 还有那些常用：常用的设计模式主要有单例模式、抽象工厂模式、工厂方法模式、模板方法模式、责任链模式、策略模式等等。这还要看具体的项目情况而定的。

5. 5. 学习的曲线：首先，应该积累设计经验，在项目实践中总结、归纳，悟出一定的设计思想，还有就是要有设计模式书籍的辅助。个人《秘笈-设计模式那点事》一书，当中例举23个实例讲解23种设计模式，还有综合实战应用，并附各个模式的静态类图、适用场合等等，对于学习设计模式帮助很大！
   

如何学习设计模式

  如果是初学软件设计的话，最好不要先看书。设计这个东西不像是做二元一次方程，给出固定解法和步骤就能得到唯一的解。而设计的精髓在于“在多个相互矛盾的目标中找到权衡”。设计的上下文对设计是非常的重要的，上下文变一点点，都有可能造成设计方案完全不同。所以，首先要熟悉领域知识、主机硬件、编程语言、网络、数据存储等内容。当把这些内容都能熟练掌握，再来谈设计。

  首先，你可以在你工作的领域中，找到最常用的设计模式。比如做Web的，MVC、MVVM这类应该很常见。然后去思考和分析，为什么这种模式适合这个场景，好处在哪里，代价在哪里。再阅读一些设计的书籍，与你面临的现实对照。如果有不明白的，可以去问问别人为什么，多于别人探讨学习。之后，进一步阅读一些设计模式的资料，分析他们出现的上下文和背景，思考下你用的编程语言，那些设计思路编程语言可以帮助你快速完成。当你以上掌握的差不多了，可以开始看看其他领域和其他编程语言的设计。当然，为了面试，还是把23种设计模式背牢。

  设计模式基于六大原则。开闭原则，一个软件实体如类、模块和函数应该对修改封闭，对扩展开放；单一职责原则：一个类只做一件事，一个类应该只有一个引起它修改的原因；里氏替换原则，子类应该可以完全替换父类。也就是说在使用继承时，只扩展新功能，而不要破坏父类原有的功能；依赖倒置原则，细节应该依赖于抽象，抽象不应依赖于细节。把抽象层放在程序设计的高层，并保持稳定，程序的细节变化由低层的实现层来完成；迪米特法则，一个类不应知道自己操作的类的细节，换句话说就是，只和朋友谈话，不和朋友的朋友谈话；接口隔离原则，客户端不应依赖它不需要的接口。如果一个接口在实现时，部分方法由于冗余被客户端空实现，则应该将接口拆分，让实现类只需依赖自己需要的接口方法。