原帖由 yuba 于 30-4-2009 13:06 发表
MethodBVisitor中methodB的逻辑如果不能完全由ConcreteClass已有的public的method组合而来,则必然有部分应该属于ConcreteClass的逻辑写到了methodB中。
理想的情况是
private void methodB(ConcreteClass c)
{ ...
原帖由 yuba 于 30-4-2009 13:14 发表
原则上说,3楼说的非常正确
但是不适合评价本例
从这部分代码可以看出
ConcreteClass c=new ConcreteClass ();
c.methodA();
List vList=XMLConfigFactory.load(VISITOR_CLASS_LIST);
for(Visitor v:vList ...
原帖由 black_zerg 于 30-4-2009 13:56 发表
逻辑分散。vistor 权力过大,不过怎么说呢,管用就行。现在还有什么面向方向编程,动态语言也有点流行,在变动的世界中,管用的就是好办法。
原帖由 hoopoos 于 30-4-2009 14:09 发表
"如果要让Visitor能充分的实现新的功能,需要ConcreteClass把所有Visitor可能需要用到的method和property(gettter, setter)都设成public或者friendly的"
这句话已经表明,新的Visitor能够在完全利用ConcreteClas ...
原帖由 black_zerg 于 30-4-2009 13:56 发表
逻辑分散。vistor 权力过大,不过怎么说呢,管用就行。现在还有什么面向方向编程,动态语言也有点流行,在变动的世界中,管用的就是好办法。
补充一点,个人以为除非应用是那种plugin的架构, 如果只是CR,直接改代 ...
原帖由 black_zerg 于 30-4-2009 14:48 发表
不明白为什么要重编译5000个类。你的新逻辑全放一个class里也没问题,只不过在切入的时候,直接修改原先的代码,切入这个新类。这就是基于一个change request.需要做的事情.
如果用这个vistor的模式来做需求变化, ...
只是新的这个visitor呢?因为无论这个visitor做了什么,它都不会影响现有的类,它就算全是bug,甚至编译都通不过,也只是它一个类的问题。
这个原则极致化的结果就是,不论是需求增加还是需求修改,永远只增加类,不会修改类
原帖由 coredump 于 30-4-2009 16:33 发表
按照你这个说法,我啥OO也不要,就要个VCS就行了,某个BUG肯定是某个changeset导致的,代码随便写![]()
ok,不是你钻牛角尖,是我钻牛角尖了,以至于我以为你和我一起钻了![]()
原帖由 yuba 于 30-4-2009 19:24 发表
讨论似乎转到“是否可以修改现有代码”的问题上了
看来认为“代码可以修改,味道不能忍受”的人比“代码不可修改,味道可以忍受”的人多
也许这正是软件发展缓慢的原因吧
想起了一个关于计算机和数学的关系 ...
原帖由 yuba 于 30-4-2009 21:38 发表
严重同意,深有同感
打工的都该这么想,有时真把自己当葱了,代码又不是我的
只有代码不断腐烂,我们才会一直有饭碗
而代码的腐烂有两种情况,一种是质量下降了,充满味道,另一种是找不到owner了,没人敢动 ...
這東西是要靠多做自己摸出來後,到這本書裏去較對一下
不過說實在太教條了 每個人都有自己的習慣愛好,CODING 還是要有點FLEXIBILITY的
不過別忘了老鼠抓光了,貓也會被掃地出門,所以嘛。。 CODING還是不要做得太好
原帖由 key 于 1-5-2009 16:43 发表
不同的阶段看有不同的得益。新手学习,难免有点穿凿附会,但即使这样,得益还是很大的。
有些部分能摸出来,有的就摸不了。
想省时省力,还是少点flexibility好一点。coding不是一个创意工业。
如果想发 ...
欢迎光临 FreeOZ论坛 (https://hioz.im/ibbs/) | Powered by Discuz! X3.2 |