回复 #29 sliuhao 的帖子
你看我更新的贴，Abstract Class可以用interface来代替，其实Abstract Class里面我用了template模式，这篇文章的例子是我为了表达3个模式的演变过程想出来的，真实系统会有很多模式混用的时候。写这篇文章不是讨论要不要用模式，是假设要用，如何用，在什么场景下用。
就行HF里面strategy模式，很多人都说bridge，因为模式就是在设计原则下推导的结果的经验总结，懂得原则可以推断出好多类似GoF的模式。我写的目的是尽量反映GoF。不是根据原则去推导出各种各样不同的模式，算是学习的总结。
关于实现细节的一点不同看法
原帖由 procoder 于 24-4-2009 21:48 发表 http://www.freeoz.org/forum/images/common/back.gif这是我自己的一些想法，论坛里有好多高手，请指教。
Simple Factory
先从Simple Factory开始讲起，假设模拟一个电玩店的试玩系统，这个电玩店专卖出售PS3的游戏机和提供试玩服务，当一个用户想试玩的时候，需要选择 ...
pro的文章很不错，我看到得益很大（这不是客气话，是实话，真的很感谢）。。。。
不过我对照了GoF的Diagram后，有一点不同的看法。我觉得，如果参照原始的GoF，
采用Abstract Factory，我会得到下面第二个图的Diagram。
而我也觉得，以你所举的例子来看，这个Abstract Factory的“实现”可能更合适。
1. 虽然没有这样的假设，但从你的整个解说过程中，我发现，每种Game都有Racing,
Shooting, Fighting这三种分类。所以，你的Factory类/接口中，定义了三种Game
的产生实现。个人认为，采用Switch和采用explicit method的做法有其相似之处。
当然，Switch有自己的优势；我画成method只是为了更接近GoF的原图。
2. 第一层的Game抽象和Racing...等三种Game是继承关系，这个关系我觉得不需要表示
在所有的类图中，因为过多的线条会影响阅读和理解；在其他图中去掉这种继承关系，我们
可以更清楚地看到Abstract Factory在这里更合适，也更接近GoF的原图。
3. Player应该是一个client。这一点在你文章的最后有所反映。但你选择AbstractPlayer
来做为Creator的名称，可能不是太合适。
原文中，你提到Joystick，GameConsole等元素，我在这里没有涉及。
认同关于演变的过程
原帖由 procoder 于 30-4-2009 22:35 发表 http://www.freeoz.org/forum/images/common/back.gif你看我更新的贴，Abstract Class可以用interface来代替，其实Abstract Class里面我用了template模式，这篇文章的例子是我为了表达3个模式的演变过程想出来的，真实系统会有很多模式混用的时候。
写这篇文章不是讨 ...
pro同学关于设计的演变过程，我很欣赏。其实我自己也一直在想这个问题：
拿到一个需求，因为某些原因，如经验，灵感，等，会有一些东西不期然的跑
到我们的脑子里。而这个东西很可能是简单的、不完美的。
更重要的是，需求是不断的清晰化的，是过程化的。这个时候我们必须不断演化
我们的系统，加入新的变化，加入新的元素。
谢谢你的分享。
不过，可能是我理解上的问题，我觉得从Simple Factory到Abstract Factory，
这个过程应该是不同的选择过程，而不是一个“升级”“进化”的过程。在不同的场合下，
选择更合适的“模式”，使我们的实现更容易、更直观。
回复 #31 procoder 的帖子
你要说是 学习的总结 ， 那就没什么好讨论的啦，呵呵.....我的经验是， 要学pattern,就该忘记pattern。建议你看看GoF之前的开山之著， 亚历山大的 "永恒建筑之道" - the endless building.一本在恒建筑业没什么名气的书，确是模式的开山之书...... 原帖由 key 于 1-5-2009 01:01 发表 http://www.freeoz.org/forum/images/common/back.gif
pro的文章很不错，我看到得益很大（这不是客气话，是实话，真的很感谢）。。。。
不过我对照了GoF的Diagram后，有一点不同的看法。我觉得，如果参照原始的GoF，
采用Abstract Factory，我会得到下面第二个图 ...
非常感谢你认真的看，谢谢你。
我写这篇文章的时候，一直运用了原有的代码，例如Factory Method用来了Simple Factory的工厂类，这样导致了设计和GoF的有不同，我认为我实现的不同的在GoF的基础上扩展了，例如把某个直接生成的过程使用了工厂类。当然这样做的好处是有连续性，坏处明显就是增加了阅读的难度，因为实现比GoF的经典实现多了一两步。还有你的建议很好，在实现不同模式的时候把class名字改一下，而不是只是沿用原先的class的名字。
关于你“第一层的Game抽象和Racing...等三种Game是继承关系”的实在，我觉得是refactoring里面replace conditional to polymorphism 的做法，am i right?
其实如果只是描述Abstract Factory的话，应该把各个游戏碟类型去掉，concrete class只有PS3GameDisk和WiiGameDisk。Joystick，GameConsole我还是会保留，因为 Abstract Factory 用在生产产品族的需求，各个产品族之间的产品不能替换，一个产品族内部的产品相互协作。 原帖由 procoder 于 1-5-2009 09:29 发表 http://www.freeoz.org/forum/images/common/back.gif
其实如果只是描述Abstract Factory的话，应该把各个游戏碟类型去掉
你果然看出来了，在描述一个模式的时候，最好把不直接相关的关系省略掉，突出重点，另外就是给类和接口起名最好贴切一点。 原帖由 key 于 1-5-2009 01:14 发表 http://www.freeoz.org/forum/images/common/back.gif
pro同学关于设计的演变过程，我很欣赏。其实我自己也一直在想这个问题：
拿到一个需求，因为某些原因，如经验，灵感，等，会有一些东西不期然的跑
到我们的脑子里。而这个东西很可能是简单的、不完美的。
更 ...
关于演变的过程，每个引入新模式的时候的大前提是需求变化，做Simple Factory的时候是完全不知道会有Wii的需求，需求是在实现Simple Factory添加的，我们做设计设计的时候会把变化的尽量多想，在这个case，可能一开始想到Abstract Factory或者其他，有对“实例化过程的封装”的需求，产生Simple Factory。由于加入Wii的对象“实例化过程的封装”的需求，有出现”面向抽象优于面向具体“，出现了Factory Method。有对产品族（加入GameConsole，joystick）的“实例化过程的封装”的需求，出现了Abstract Factory。
Simple Factory不是必然演变成Abstract Factory，如果这样真是为了模式而模式。而是在需求的驱动下，场景符合的情况下进行演变，这文章想表达就是这个意思。
回复 #34 sliuhao 的帖子
我写这个表达在什么场景下用，如何用。我的用法尽量忠于GoF的经典实现。实际工作心中应该是设计原则，而不是模式，推倒过程中，觉得这个场景符合某个模式，然后就模式一下，然后再扩展一下。
回复 #36 hoopoos 的帖子
说实在，我开始就发现这个问题，这是我延续性（为了原先Simple Factory等已有的实现）和简化性的权衡。其实演变过程中，我忘记了一个重要的refactoring实在，rename。如果我在表达一次，可能会更清楚和更好了，这也我的写东西的目的：多想，多写，多总结，多交流。 不知楼主的程序库规模有多大？20万行的代码有没有？
以我15万行有效代码的经历，觉得设计模式根本用不着。
页:
1
[2]