琴鸟 - 博客园

2019年7月8日

摘要：基本上就是必须把元素和句子，都要是为符号。所以需要一个他们的抽象类。就可以出来解释器模式了。为什么元素和句子要一个通用意图？因为解释器的句子，可能就是某个句子的符号。整个代码就是树结构。任何一个点都是一个树。个人感觉，基本不会自己独立去实现这个模式，java,c#都是一种更高级语言，如果非要开启解释模式，那么肯定可以找到某一领域的库，或者干脆换个专用的语言就好了。. //感觉解释器模式的难点在... 阅读全文

posted @ 2019-07-08 08:00 琴鸟阅读(361) 评论(0) 推荐(0)

2019年7月7日

访问者模式

摘要：是我没有理解正确还是？这个模式为什么要单独出来。不就是状态模式的广度增加版而已嘛？个人感觉非常少的合适的场景。看状态模式就好了。一样的思想。多个状态的状态模式 =》多个元素需要分别处理状态=》多个元素需要有各自的操作=》访问者模式。阅读全文

posted @ 2019-07-07 18:13 琴鸟阅读(152) 评论(0) 推荐(0)

模板模式

摘要：模板模式是非常容易看懂的。以前用了所谓的桥接模式，我也会认为我用了模板模式。其实把桥接模式叫做模板模式的接口版也没有任何问题。模板模式全部虚函数，固定起来。而桥接模式。加了一个接口。把意图的实现放的更自由，脱离了虚类。但是又如何啊。桥接多难懂的一个词。我想叫桥接模式为自由的模板模式。个人总阅读全文

posted @ 2019-07-07 09:05 琴鸟阅读(234) 评论(0) 推荐(0)

策略模式

摘要：用了也不知道用了的典型。就是接口存在的意义，意图和实现分离。就好像1+1=2，实现了一个简单加法一样。。。阅读全文

posted @ 2019-07-07 08:41 琴鸟阅读(121) 评论(0) 推荐(0)

状态模式（理解此模式了）

摘要： v2第二次复习：基本上看第一次总结，是正确的，还有一个补充就是，如果状态的判定又涉及到多个字段的话，那么用状态模式的附带的好处就是把状态用单独key表示出来了。就是每个状态的派生类。这样更简洁。另外状态类，都是包含行为的，而行为一般是会对状态类的母体做修改。所以状态类的方法一般会传递this过去。第一次学习官方的一句话：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的... 阅读全文

posted @ 2019-07-07 08:09 琴鸟阅读(385) 评论(0) 推荐(0)

观察者（订阅者）模式（已理解此模式）

只有注册用户登录后才能阅读该文。阅读全文

posted @ 2019-07-07 06:27 琴鸟阅读(7) 评论(0) 推荐(0)

备忘录模式

摘要：就是存档。把关键数据，存在一个列表中。所以需要一个存档中心类，一个执行存档的类。和一个被存档的类。可以和命令模式，配合。并加上原型。会比较配。阅读全文

posted @ 2019-07-07 05:39 琴鸟阅读(237) 评论(0) 推荐(0)

中介模式。

摘要：比较简单，现实例子太常见了。比如租房，如果没有房屋中介，你必须亲自各个小区自己转，找房东的电话。而有中介了，你找中介一个就可以了，就可以和其他房东联系。有句总结说的很好，把网状的关系，化为了更简单的中心发散关系。阅读全文

posted @ 2019-07-07 05:31 琴鸟阅读(230) 评论(0) 推荐(0)

2019年7月6日

迭代器模式（完全理解此模式）

摘要：重要的思想：对容器项目遍历从容器本身中分离出来，而放入单独的迭代器中。其实有种java内部类的意思。个人总结，迭代器非常简单直接，超级实用，但是一般流行语言，容器都已经实现了。list, array. 等都已经实现了。其他大部分实际开发中不用的模式都是因为场合少，这个是个反例，是因为实在太实用阅读全文

posted @ 2019-07-06 19:02 琴鸟阅读(310) 评论(0) 推荐(0)

命令模式（基本了解的程度）

摘要：命令模式总不得要领。做了3次迭代。个人直觉，这个模式不会太常用，完全可以用数字或字符来代替命令，解耦和简洁之间并非每次都是解耦胜出。做菜这个场合，我站简洁。也可能网上例子都是做菜，所以才会让人觉得命令模式没有必要。应该是例子本来就不适合标准的命令模式。要不是 GOF他们4个人设计过度。而且阅读全文

posted @ 2019-07-06 10:41 琴鸟阅读(330) 评论(0) 推荐(0)

琴鸟

公告