模式包括问题和解决方案

极客时间《如何落地业务建模》学习笔记

题图来自：refactoring.guru

说点题外话 02｜模式并不是解决方案

比较喜欢题外话，相对轻松一些。

模式至少包含问题和解决方案。

策略模式 Strategy Pattern

问题：对于某个类需要施加不同的算法，以完成不同的功能。

解决方案：通过接口表示算，将不同的算法封装到不同的对象中，让对象实现表示算法的接口，实现算法替换。

状态模式 State Pattern

问题：某个类的行为随着内部状态的改变而改变，如何封装不同内部状态下的行为，并在状态改变时做出与之对应的变化？

解决方案：通过接口表示状态，将不同状态下的行为，封装到不同的对象中，让对象实现这个表示状态的接口，实现在内部状态改变的时候，行为也随之变化。

适配器模式 Adapter Pattern

问题：原本由于接口不兼容而不能一起工作

解决方案：将不兼容的接口转换为可兼容的接口，类适配器使用继承关系实现，对象适配器使用组合关系来实现。

备忘录模式 Memento Pattern

Captures and externalizes an object's internal state so that it can be restored later, all without violating encapsulation

问题：应用场景用来防止丢失、撤销、恢复等

解决方案：捕获一个对象的内部状态，并且在该对象之外保存这个状态，以便之后恢复对象为先前的状态。

装饰器模式 Decorator Pattern

问题：继承关系过于复杂

解决方案：通过组合来替代继承

如果我有时间，能把所有的设计模式都这样梳理一下就更好了。

“问题先行”，说起来容易，其实无论是做一个项目还是其他更宏观的事情，大部分的时候，我们面对的都是结果先行或者是解决方案先行，有点类似于手里有锤子，所以不管是否需要拧螺丝。

当问题以坏味道的方式明显出现的时候，就可以考虑通过重构获得模式。

我有点回忆不出来前面的专栏讲了那些模式，看了一下课代表 @Oops! 的留言，确实总结的很好。

@码农戏码 说的“程序员不是在编写代码，而是在摸索业务领域知识”，也是一针见血