以Visitor设计模式应对需求变化

hoopoos

原帖由 coredump 于 30-4-2009 16:14 发表

                               
登录/注册后可看大图

你这样的观点完全的是钻牛角尖了，别忘了还有重构这一说

不太明白为什么会引起你这样的看法，我说这是极致化，本身就肯定在现在的大多数项目里面是做不到的，因为最初的设计分析水平就有限，但是这是趋势，为什么重构？是因为，原先的设计和框架存在问题，和先进的OO原则冲突。重构是修补，但不是必须的。

假设一个项目经历这样的生命周期，类只增加不修改，那么，质量是可控制的，如果在某个节点，有若干个BUG，至少可以大部分认定，这些是最近新增加的class造成的，原先的是可靠的。100%的按照这个原则去做，我也同意你的说法，很傻很天真，为何我就钻牛角尖了？

yuba

原帖由 coredump 于 30-4-2009 16:14 发表

                               
登录/注册后可看大图

别忘了还有重构这一说

亡我之心不死啊

再加上一条：

销毁源代码

coredump

按照你这个说法，我啥OO也不要，就要个VCS就行了，某个BUG肯定是某个changeset导致的，代码随便写

ok，不是你钻牛角尖，是我钻牛角尖了，以至于我以为你和我一起钻了

hoopoos

原帖由 yuba 于 30-4-2009 15:58 发表

                               
登录/注册后可看大图

一直以为主人只是不在家

是等他回来呢好呢？还是找有钥匙的朋友好呢？

现在才知道，主人不是不在家，是不在人世了

你这个回复完全牛头不对马嘴，一个谈技术的帖子，也能有这样的回复，真是可笑。如果你是想嘲笑我，那我告诉你，你没资格。

coredump

讨论技术，不要抱着太这强烈的个人情绪。再次提醒，大家注意风度。

每个人的个人经历，性格都很不同，对技术的见解和观察角度也很不一样，希望大家在这里的探讨能够互相取长补短就好。相信大家都是很有素质的人，不要坏了这样纯技术探讨的气氛，谢谢。

hoopoos

原帖由 coredump 于 30-4-2009 16:33 发表

                               
登录/注册后可看大图

按照你这个说法，我啥OO也不要，就要个VCS就行了，某个BUG肯定是某个changeset导致的，代码随便写

ok，不是你钻牛角尖，是我钻牛角尖了，以至于我以为你和我一起钻了

你还没理解我的意思，并不是说要查哪个BUG是什么造成的，而是因为模块化的需要，质量的需要，我请问：你的手机要加GPS功能，你是愿意拆开加芯片改电路好还是买个蓝牙模块好？你可以选择前一个方案，但是容易把手机弄坏。

coredump

参见#24和#35

hoopoos

很好， 到了下班的时间了。

明白你的意思，行业和技术background不同的人不大可能对事物有一致的看法，reasonable。一般来说只有同一家公司同一个team的人最容易对一些东西产生共鸣和共识。

至于个人情绪么，只要是就技术论技术我总是欢迎讨论的，可惜总有些人文不对题，旁敲侧击。

yuba

主人，朋友，钥匙的说法都取自一楼

如果即使主人回来了，也不能改变（修改）什么，和出不出门没有什么关系。所以不用因为“今天有事要出门”，才需要“有你房子后门钥匙的朋友”。

代码“永久冻结”了，不发展了，和不在人世有什么区别？后面的销毁源码是同样的意思。

本以为“很清晰易懂”，确还是让你误会了

yuba

原帖由 hoopoos 于 30-4-2009 16:33 发表

                               
登录/注册后可看大图

如果你是想嘲笑我，那我告诉你，你没资格。

刚看到这句

我没有嘲笑任何人，上面的解释希望你和大家都能看懂

我一直以为无论如何都不能嘲笑他人

但好像我错了，因为你试图告诉我，具备一定的“资格”的人是可以嘲笑你的

不过我保证，即使我具备了你所说的那个“资格”，我也不会嘲笑任何人的，包括你

谢谢你提醒我

yuba

讨论似乎转到“是否可以修改现有代码”的问题上了

看来认为“代码可以修改，味道不能忍受”的人比“代码不可修改，味道可以忍受”的人多

也许这正是软件发展缓慢的原因吧

想起了一个关于计算机和数学的关系的热帖

呵呵

hoopoos

抱歉，是我没看懂，因为我从你的回复里没看出你看懂我的解释，有点绕口。

可能我的表达能力有问题，或者我太多假设了，向您道歉，多多包涵。

yuba

原帖由 hoopoos 于 30-4-2009 19:31 发表

                               
登录/注册后可看大图

我从你的回复里没看出你看懂我的解释

版主都说“很清晰易懂”了，你还是觉得我看不懂

这是谁嘲笑谁啊？！

hoopoos

原帖由 yuba 于 30-4-2009 19:42 发表

                               
登录/注册后可看大图

版主都说“很清晰易懂”了，你还是觉得我看不懂

这是谁嘲笑谁啊？！

呵呵，我说的是你没看懂我后面的解释，不是说你没看懂我的发贴，误会

总之，可能我的表达能力有限，或者理解能力也有限，交流有问题。

black_zerg

如果是谈“是否可以修改现有代码”，其实我是非常不赞成修改已有代码。理想的状态就是面向接口的模块化，如果一块有错，全部替换。另一个策略就是只增不减（增加新方法也算只增不减),  这其实是很实际的办法也是比较实用的做CR的原则。我以前做BOSS的时候记得团队就是遵守这个原则，结果就是一大堆垃圾方法哈哈，不过谁也不敢修改现有的方法，因为做CR的只有时间关注这一次的需求，谁也不高兴担那个风险。只增不减还是很简单实用的原则，虽然最终可能会导致代码腐败。在现实社会里这个就是我多年CR的基本原则哈，要么就重写，要么就只增不减，这样恢复都容易些。
补充一下，在需求变化的这个情况下，之所以不支持用visitor实现这个只增不减的原则，是因为这个原则只是个适用于快速开发的原则，本身就会降低代码质量，用了visitor后，首先并不一定适用所有的CR,又增加了一定的复杂度，分散了逻辑，却并没有带来明显的好处。说简单点，加个新方法起码还看得见找的到，你加几个新类再配置几下，以后的人就不知道到哪里去找了。几十次cr也是很常见的，你增加了几十次*n的新类后，到时候后来的人看着代码就可能要哭了。xml配置这些并不是一个CR所需要的东西

可能楼主的这个“需求变化”并不是我所理解的changeRequest, 而是指的是 这个系统需要设计为需要不断扩展功能， 那就是一个插件扩展机制，那就是一个很好的应用场景。或者你想表达的是保持接口，替换实现这个策略，如果是那样的话，直接写个新实现类用spring注入一下。只修改实现，保持接口稳定还是很重要的。

[ 本帖最后由 black_zerg 于 30-4-2009 21:39 编辑 ]

key

hoo的一楼写得很好。我在实际项目中遇过类似的问题，很感谢你给我指点。

key

原帖由 yuba 于 30-4-2009 19:24 发表

                               
登录/注册后可看大图

讨论似乎转到“是否可以修改现有代码”的问题上了

看来认为“代码可以修改，味道不能忍受”的人比“代码不可修改，味道可以忍受”的人多

也许这正是软件发展缓慢的原因吧

想起了一个关于计算机和数学的关系 ...

这是两个角度的问题，不能说绝对的错或对吧。
Refactor这本书一开始就教人要把代码改来改去，但事实上，写Refactor的那个人是做软件咨询的，
别人不改代码，他就没饭吃了……

而在工作环境里，如果有一个相对稳定的版本，然后把所有的.class打包，封起来，
然后重用，扩展，这是很有意义的事。

从长远来看，代码最好能做一些必要的refactor……这个观点不能说错，但要多长远呢？
楼主一开始就说了是在“扩展”。我觉得如果这个扩展特别的有意义，而又没有绝对的必要
加到原来的类里面，为什么一定要Refactor原来的类呢？如果一定要说这样就是做plug-in，
那就只好plugin了……因为的确这就是在扩展嘛。

我之所以支持楼主，更重要原因是，我明白到打开一个原始类，加一行代码的代价的确很大。
可能其他人所在的公司很好，没有遇到我这样的问题也不奇怪。我并没有贬低其他人的意思。

yuba

严重同意，深有同感

打工的都该这么想，有时真把自己当葱了，代码又不是我的

只有代码不断腐烂，我们才会一直有饭碗

而代码的腐烂有两种情况，一种是质量下降了，充满味道，另一种是找不到owner了，没人敢动

有些更甚，我见过连log4j的新版本都不敢用。固件还升级呢，这简直是在做硬件

yuba

原帖由 key 于 30-4-2009 21:25 发表

                               
登录/注册后可看大图

Refactor这本书一开始就教人要把代码改来改去，但事实上，写Refactor的那个人是做软件咨询的，
别人不改代码，他就没饭吃了……

没有他估计大家还动不了肝火

key

原帖由 yuba 于 30-4-2009 21:38 发表

                               
登录/注册后可看大图

严重同意，深有同感

打工的都该这么想，有时真把自己当葱了，代码又不是我的

只有代码不断腐烂，我们才会一直有饭碗

而代码的腐烂有两种情况，一种是质量下降了，充满味道，另一种是找不到owner了，没人敢动 ...

我觉得更多时间我们有点过份学究，“完美主义”。事实上，如果一定要从完美的角度看问题，怎样都会看出毛病的。
你看design pattern出来后就马上有over design，而再细看一下，会发现design pattern很多地方都很不oo，
然后又怀疑起来。再看RoR之流，还AOP之流，有哪个OO了？

说得太远了。但总而言之，我觉得楼主对于visitor以及例解都说得很好，我愿意给9.5分（10分满分）。

yuba

作为成熟的软件从业人员，大家都有自己的侧重和坚持而已

你不认为楼主的“极致化”也是一种“过分学究”和“完美主义”，我也没有办法

AOP是AO，本来就不OO

Ruby连字面常量都有方法，还不够OO吗

不想抬杠

作为成熟的软件从业人员，大家都有自己的侧重和坚持而已

hoopoos

“作为成熟的软件从业人员，大家都有自己的侧重和坚持而已”

非常赞同！

ingeer

Design Pattern 這東西讓沒經驗的新手看，看上一百年也不會懂的，這東西是要靠多做自己摸出來後，到這本書裏去較對一下，不過說實在太教條了  每個人都有自己的習慣愛好，CODING 還是要有點FLEXIBILITY的。
抓到老鼠的就是好貓，不過別忘了老鼠抓光了，貓也會被掃地出門，所以嘛。。 CODING還是不要做得太好。。哈哈

key

原帖由 ingeer 于 1-5-2009 09:48 发表

                               
登录/注册后可看大图

Design Pattern 這東西讓沒經驗的新手看，看上一百年也不會懂的

不同的阶段看有不同的得益。新手学习，难免有点穿凿附会，但即使这样，得益还是很大的。

這東西是要靠多做自己摸出來後，到這本書裏去較對一下

有些部分能摸出来，有的就摸不了。

不過說實在太教條了  每個人都有自己的習慣愛好，CODING 還是要有點FLEXIBILITY的

想省时省力，还是少点flexibility好一点。coding不是一个创意工业。
如果想发挥创造力，最好还是在architecture上下功夫。coding上做文章……
不是不行，而是一般人没有这个精力，达不到这个高度，最后就只是在浪费时间。

不過別忘了老鼠抓光了，貓也會被掃地出門，所以嘛。。 CODING還是不要做得太好

这个很认同。我自己程序最大的缺点就是没有什么bug，后期维护接近0。。。。

yuba

原帖由 key 于 1-5-2009 16:43 发表

                               
登录/注册后可看大图

我自己程序最大的缺点就是没有什么bug，后期维护接近0

接近0不算啥

按照楼主的想法做，你的程序的后期维护等于0

ingeer

原帖由 key 于 1-5-2009 16:43 发表

                               
登录/注册后可看大图

不同的阶段看有不同的得益。新手学习，难免有点穿凿附会，但即使这样，得益还是很大的。


有些部分能摸出来，有的就摸不了。


想省时省力，还是少点flexibility好一点。coding不是一个创意工业。
如果想发 ...

牛，您真牛，請繼續牛，咱是代碼民工，看個熱鬧

hoopoos

谢谢大家热烈的参与讨论，再友情提示一下，模式要活学活用，注意场合。我这里提Visitor模式不是说一有需求变化就用Visitor，是在特定的场合，已经完成了一个稳定的模块，冻结，打包，发布，这样的前提下，为了降低改动带来的风险，保持代码的integrity，采用的一种灵活策略。如果处在开发生命周期的当中，代码不稳定，频繁的需要修改，肯定是不能用Visitor的。

key

原帖由 ingeer 于 7-5-2009 08:41 发表

                               
登录/注册后可看大图

牛，您真牛，請繼續牛，咱是代碼民工，看個熱鬧

您老牛一点，俺才是代码民工。你提倡flexible，俺提倡跟着别人屁股跑，高下之分，一目了然嘛

caoglish

1. 
   
2. var visitable = function () {
   
3.     this.accept = function (visitor) {
   
4.         visitor.visit(this);
   
5.     };
   
6. };
   
7. element = new visitable();
   
8. element.name = "John";
   
9. 
   
10. 
    
11. visitor = {
    
12.     visit: function (visitable) {
    
13.         console.log(visitable.name);
    
14.     }
    
15. };
    
16. 
    
17. element.accept(visitor);
    
18. 
    
19. 
    
20. visitor = {
    
21.     visit: function (visitable) {
    
22.         console.log("name:" + visitable.name);
    
23.     }
    
24. };
    
25. 
    
26. element.accept(visitor);
    
27. 
    
28. visitor = {
    
29.     visit: function (visitable) {
    
30.         console.log("First Name:" + visitable.name);
    
31.     }
    
32. };
    
33. 
    
34. element.accept(visitor);
    
35. 
    
36. 
    

复制代码

jsbin

Javascript 实现的例子

caoglish

1. var Client = function () {
   
2.   this.setStrategy=function(strategy){
   
3.     this.strategy=strategy;
   
4.   };
   
5.   this.run=function(){
   
6.     strategy.run(this);
   
7.   };
   
8.    
   
9. };
   
10. client = new Client();
    
11. client.name = "John";
    
12. 
    
13. 
    
14. strategy = {
    
15.    run: function (client) {
    
16.         console.log(client.name);
    
17.     }
    
18. };
    
19. 
    
20. client.setStrategy(strategy);
    
21. client.run();
    
22. 
    
23. 
    
24. strategy = {
    
25.    run: function (client) {
    
26.         console.log("name"+client.name);
    
27.     }
    
28. };
    
29. 
    
30. client.setStrategy(strategy);
    
31. client.run();
    
32. 
    
33. strategy = {
    
34.    run: function (client) {
    
35.         console.log("first name"+client.name);
    
36.     }
    
37. };
    
38. client.setStrategy(strategy);
    
39. client.run();

复制代码

jsbin

在做一个strategy的demo， 这两个模式感觉很像。


感觉visitor，只是重点修改内部，希望过程不要一样。
而strategy，修改内部，过感觉上strategy更多是用于结果相同，过程不同