71 | 命令模式：如何利用命令模式实现一个手游后端架构？

不知道老师会不会后面专栏进行functional programming和object oriented programming区别。尽管核心的编程思想和设计原理可能相近，但是还是希望老师能出一篇这样的专栏

请教命令模式可以在进程间实现吗？按照本文的command定义，如果想要在进程间使用该模式，command对象的序列化怎么办？

“整个手游后端服务器轮询获取客户端发来的请求，获取到请求之后，借助命令模式，把请求包含的数据和处理逻辑封装为命令对象，并存储在内存队列中。然后，再从队列中取出一定数量的命令来执行。” ———————————————————— 感觉不需要放入队列呢，直接执行命令对象呢？取出一定数量，指的是线程池里批处理吗？

单例模式和享元模式,缓存,静态工厂方法: 他们的共同点是:对象的复用 不同点: 应用享元模式是为了对象"共享使用"，节省内存 而应用单例/多例模式是为了限制对象的个数 应用缓存是为了提高访问效率 应用对象池(数据库连接池,线程池)是为了对象的"重复使用"和管理,主要是为了节省时间 有一种方法叫 静态工厂方法,例如 Boolean.valueof(),不会在每次调用时返回一个新对象,而是复用已有的,这一点有点像享元模式 适配器,代理,装饰器,桥接,: 他们的共同点是:对方法的增强 不同点: 适配器模式的作用是"适配",通常用于适配不同的组件,新旧系统 桥接模式将接口部分和实现部分分离,使两者可以分别扩展 装饰者模式是对原始类功能进行增强，并且可以支持多次,多种增强 代理模式实现了代理类和原始类的解耦,使代理类可以用于增强不同的功能 策略模式与简单工厂模式,命令模式: 共同点:都有对if/else进行下沉 不同点: 策略模式根据运行时状态返回一个"策略"/"算法",这些"策略"具有相同目的,比如BubbleSort、SelectionSort 都是为了实现排序 命令模式中不同的命令具有不同的目的，对应不同的处理逻辑，并且互相之间不可替换 而简单工厂更侧重返回一个创建的对象 桥接模式与服务提供者框架,静态工厂的辨析(来自effective java): 服务提供者框架是这样一个系统: 多个服务提供者实现一个服务,系统为服务提供者的客户端提供多个实现,并把它们从多个实现中解耦出来 它分为四部分: 服务接口:系统抽象出一个接口,交给服务提供者实现(JDBC中的connection即为服务接口) 提供者注册API:交给服务提供者注册自己的API (Class.forName(),将自己的Driver类加载到JVM中,JDBC会查找该类并注册他的api) 服务访问API:是一个静态方法,供客户端获取服务实例(DriverManager.gtConnection()便是此处的静态工厂,它拿到的connection实例,其实是mysql包里的connection实现) 服务提供者接口:是服务接口实例的工厂对象(在此为mysql包内的Driver类) 在此处,桥接模式和静态工厂方法的使用,共同构成了服务提供者框架

GoF的设计模式脱胎于开发smalltalk的经验，而smalltalk的一大特点是自带图形界面，所以很多设计模式都是脱胎于解决图形界面的开发问题。命令模式在早期图形界面的编辑器中用于解决编辑历史的问题，比如在实现操作的同时还要实现一个反操作用来undo，而重放操作就可以redo。由于现代计算机的存储成本比设计模式刚出现那会低太多了，于是通过快照方式来实现编辑历史也变得可行了

Hystix熔断框架就用到了命令模式。

再比较下命令模式和策略模式，策略模式的意图是封装算法，它认为“行为”是一个完整的、不可拆分的业务，即其意图是让这些行为独立，并且可以相互替换，让行为的变化独立于拥有行为的客户；而命令模式则是对动作的解耦，把一个动作的执行分为执行对象，执行行为，让两者相互独立而不相互影响。二者的关注点不同：策略模式提供多种行为由调用者自己选用，算法的自由选用是其关注点。命令模式关注解耦，将请求的内容封装成命令由接受者执行。二者使用场景不同，策略模式适用于有多种行为可以相互替换的场景；而命令模式适用于解耦两个紧耦合关系的对象或多命令对撤销的场景。

感觉redis就是使用了命令模式来处理指令的

观察者模式和用接口实现的职责链模式，从设计意图来看，观察者重在状态变化时通知所有的观察者，观察者之间是并列关系。职责链模式侧重顺序处理，处理类之间是串行关系

打卡 结束后 开启重刷 第一遍 了解定义 第二遍代码实现 第三遍 实际应用