海马渔人

这是最后一篇有关电子书的了哦 学习新的东西不少类似 https://flutter.cn/docs https://dart.cn/guides 这样的网址上面不少文档要读

按照概念的理解，我曾经实现过的 一套自动控制手机系统里面有对不同配置文件的解释engine， 可以理解为解释模式吧。这里不做赘述，后面开放 这个 手机的 robot 代码 在gitee上。

意图：将抽象部分与实现部分分离，使它们都可以独立的变化。 主要解决：在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。 何时使用：实现系统可能有多个角度分类，每一种角度都可能变化。

意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。 主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，

意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理

意图：运用共享技术有效地支持大量细粒度的对象。 主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。 何时使用

意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后

意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。 主要解决：不同的方式来遍历整个整合对象。 何时使用：遍历一个聚合对象。 如何解决：把在元素之间游走的责任交给迭代器，

意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。 主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等