系统各个模块之间独立，松耦合是OOD根本原则！
但是很多设计模式却在引领我们背叛这个原则！举一下我碰到的问题！
在我设计的项目里，coding阶段碰到了很多instanceof使用，为了效率考虑，我不得不重新调整了设计思路，采用了visitor模式，但是采用了这种模式之后，发现这个模式把我们引入了背叛模块之间独立原则，导致我的低层次模块（被观察者）不得不依赖高层次（可以说是观察者）具体实现，两者之间独立性被完完全全破坏了！（这里的高低层次其实是分别位于两个不同模块，高低之分可以用一句话来说明：应该由我来调用你，而不是你来调用我），真的害死人啊！！！55555555555555555555555555555555555555555555555555555555
banq 兄，你说说咋办涅？？？？！！！！！我真是滥用设计模式阿！！有苦自己吃啦！自己只是不够丰富，考虑问题不够周到！哎！
这是两种思维纠缠不清的结果，visitor模式经常会起到伤筋动骨的作用，应该属于另外一种思维。
因为你是从原来的代码重整到设计模式，因此，你引入一种新的模式或新的思维方式时，你考虑新旧的过渡方式，也就是试图寻找焊接口，实际中我认为这是很痛苦和烦恼的。这是阴阳不和，水火不容的问题。
抛弃原来的思维，从需求出发，完全使用新的思维，以visitor模式为核心的思维重新分析和设计需求，这样，就可以从一种高度来认识这个需求到底是否可以用visitor模式。
btw:在我的书籍 Java实用系统开发指南第一章中，有类似你这样案例，我也使用了visitor模式，使得程序对不同的对象类型有了拓展性。
>>抛弃原来的思维，从需求出发，完全使用新的思维，以visitor模式为核>>心的思维重新分析和设计需求，这样，就可以从一种高度来认识这个需>>求到底是否可以用visitor模式。
时间上不允许了！
我只能尽量减少instanceof上考虑了
感觉java基于接口的耦合特性决定了使用instanceof必要性，而此也带来了java本身固有的性能瓶劲呢？？
我认为不能一开始就考虑模式，而应该重点放在系统耦合上，然后把系统耦合又分解为对象的耦合，要尽量的理清接口的边界条件，设计出最小的、完备的对象接口集合和系统接口集合，这样一来，松耦合的要求就水到渠成的满足了。
>java基于接口的耦合特性 .. instanceof
instanceof我感觉现实中很少碰到，一般是由于其它环节设计不当造成。建议看看struts源码，它用了很多instanceof，也是对基本类型的判断，这是目前无法逃避的，其它场合应用就很少 了。
youngS的心得有道理，如何做，取决于是否利于自己的实践了，没有必然过程。