mvc
复合模式引入
我们从一大堆 Quackable 开始.........
有一只鹅出现了,它希望自己像一个 Quackable。
所以我们利用适配器模式,将鹅适配成 Quackable。现在你就可以调用鹅适配器的 quack。方法来让鹅咯喀叫。
然后,呱呱叫学家决定要计算呱呱叫声的次数。
所以我们使用装饰者模式,添加了 一个名为 QuackCounter 的装饰者。它用来追踪 quack。
被调用的次数,并将调用委托给它所装饰的 Quackable 对象。
但是呱呱叫学家担心他们忘了加上 QuackCounter 装饰者。
所以我们使用抽象工厂模式创建鸭从此以后,当他们需要鸭子时,就直接跟工厂要, 工厂会给他们装饰过的鸭£。(别忘了,如果他们想取得没装饰的鸭户,用另一个鸭子 工厂就可以!)
又是鸭子,又是鹅,又是 quackable 的……我们有管理上的困扰。
所以我们需要使用组合模式,将许多 quackable 集结成一个群。这个模式也允许群中有群, 以便让呱呱叫家来管理鸭子家族。我们在实现中通过使用 ArrayList 中的 java.ulil 的迭代器 而使用了迭代器模式。
当任何呱呱声响起时,呱呱叫学家都希望能被告知。
所以我们使用观察者模式,让呱呱叫学家注册成为观察者。现在,当呱呱声响起时,呱呱 叫学家就会被通知了。在这个实现中,我们再度用到了迭代器。呱呱叫学家不仅可以当某个 鸭了•的观察者,甚至可以当•整群的观察者。
FAQ
所以,设计模式真正漂 亮的地方在于,遇到问题时,我可以 拿模式逐一地解决问题,直到所有的 问题都被解决。我这样说对吗?
错!我们在鸭子的例子 中之所以这么做,主要的目的是展 示许多模式可以合作。在真实的设 计过程中,你不会想要这么做的。r 实上,离子模拟器的许多部分都可以 用模式解决,只是有一点“杀鸡焉用宰牛刀”的感受。有时候,用好的 oo 设计原则就可以解决问题,这样 其实就够了。
在下一章,我们将讨论更多这方面的 问题。现在我只能告诉你,采用模式 时必须要考虑到这么做是否有意义. 绝对不能为了使用模式而使用模式。 有了这样的观念,鸭子模拟器的设计 看起来就显得做作。但是,这个例子 有趣,而且在过程中还让我们体会到 多个模式是如何携手解决一个问题 的。