设计模式之间互为陷阱的问题!为模式而模式的疑问!

04-03-28 javer6
系统各个模块之间独立,松耦合是OOD根本原则!

但是很多设计模式却在引领我们背叛这个原则!举一下我碰到的问题!

在我设计的项目里,coding阶段碰到了很多instanceof使用,为了效率考虑,我不得不重新调整了设计思路,采用了visitor模式,但是采用了这种模式之后,发现这个模式把我们引入了背叛模块之间独立原则,导致我的低层次模块(被观察者)不得不依赖高层次(可以说是观察者)具体实现,两者之间独立性被完完全全破坏了!(这里的高低层次其实是分别位于两个不同模块,高低之分可以用一句话来说明:应该由我来调用你,而不是你来调用我),真的害死人啊!!!55555555555555555555555555555555555555555555555555555555

banq 兄,你说说咋办涅????!!!!!我真是滥用设计模式阿!!有苦自己吃啦!自己只是不够丰富,考虑问题不够周到!哎!

    

banq
2004-03-31 09:19
这是两种思维纠缠不清的结果,visitor模式经常会起到伤筋动骨的作用,应该属于另外一种思维。

因为你是从原来的代码重整到设计模式,因此,你引入一种新的模式或新的思维方式时,你考虑新旧的过渡方式,也就是试图寻找焊接口,实际中我认为这是很痛苦和烦恼的。这是阴阳不和,水火不容的问题。

抛弃原来的思维,从需求出发,完全使用新的思维,以visitor模式为核心的思维重新分析和设计需求,这样,就可以从一种高度来认识这个需求到底是否可以用visitor模式。

banq
2004-03-31 09:21
btw:在我的书籍 Java实用系统开发指南第一章中,有类似你这样案例,我也使用了visitor模式,使得程序对不同的对象类型有了拓展性。

javer6
2004-03-31 22:20
>>抛弃原来的思维,从需求出发,完全使用新的思维,以visitor模式为核>>心的思维重新分析和设计需求,这样,就可以从一种高度来认识这个需>>求到底是否可以用visitor模式。

时间上不允许了!

我只能尽量减少instanceof上考虑了

感觉java基于接口的耦合特性决定了使用instanceof必要性,而此也带来了java本身固有的性能瓶劲呢??

youngS
2004-04-03 00:33
我认为不能一开始就考虑模式,而应该重点放在系统耦合上,然后把系统耦合又分解为对象的耦合,要尽量的理清接口的边界条件,设计出最小的、完备的对象接口集合和系统接口集合,这样一来,松耦合的要求就水到渠成的满足了。

猜你喜欢
2Go 1 2 下一页