hoopoos 发表于 30-4-2009 17:30:11

原帖由 coredump 于 30-4-2009 16:14 发表 http://www.freeoz.org/forum/images/common/back.gif
你这样的观点完全的是钻牛角尖了,别忘了还有重构这一说:L

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

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

yuba 发表于 30-4-2009 17:30:44

原帖由 coredump 于 30-4-2009 16:14 发表 http://www.freeoz.org/forum/images/common/back.gif
别忘了还有重构这一说

亡我之心不死啊

再加上一条:

销毁源代码

coredump 发表于 30-4-2009 17:33:17

回复 #31 hoopoos 的帖子

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

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

hoopoos 发表于 30-4-2009 17:33:40

原帖由 yuba 于 30-4-2009 15:58 发表 http://www.freeoz.org/forum/images/common/back.gif
一直以为主人只是不在家

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

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

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

coredump 发表于 30-4-2009 17:41:05

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

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

hoopoos 发表于 30-4-2009 17:42:45

原帖由 coredump 于 30-4-2009 16:33 发表 http://www.freeoz.org/forum/images/common/back.gif
按照你这个说法,我啥OO也不要,就要个VCS就行了,某个BUG肯定是某个changeset导致的,代码随便写;P

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

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

coredump 发表于 30-4-2009 17:45:57

回复 #36 hoopoos 的帖子

参见#24和#35 :P

hoopoos 发表于 30-4-2009 17:51:53

回复 #37 coredump 的帖子

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

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

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

yuba 发表于 30-4-2009 19:33:15

回复 #34 hoopoos 的帖子

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

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

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

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

yuba 发表于 30-4-2009 19:45:43

原帖由 hoopoos 于 30-4-2009 16:33 发表 http://www.freeoz.org/forum/images/common/back.gif
如果你是想嘲笑我,那我告诉你,你没资格。

刚看到这句

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

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

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

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

谢谢你提醒我

yuba 发表于 30-4-2009 20:24:58

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

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

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

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

呵呵

hoopoos 发表于 30-4-2009 20:31:43

回复 #40 yuba 的帖子

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

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

yuba 发表于 30-4-2009 20:42:04

原帖由 hoopoos 于 30-4-2009 19:31 发表 http://www.freeoz.org/forum/images/common/back.gif
我从你的回复里没看出你看懂我的解释

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

这是谁嘲笑谁啊?!

hoopoos 发表于 30-4-2009 21:40:54

原帖由 yuba 于 30-4-2009 19:42 发表 http://www.freeoz.org/forum/images/common/back.gif


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

这是谁嘲笑谁啊?!

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

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

black_zerg 发表于 30-4-2009 22:08:25

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

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

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

key 发表于 30-4-2009 22:09:10

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

key 发表于 30-4-2009 22:25:48

原帖由 yuba 于 30-4-2009 19:24 发表 http://www.freeoz.org/forum/images/common/back.gif
讨论似乎转到“是否可以修改现有代码”的问题上了

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

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

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

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

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

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

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

yuba 发表于 30-4-2009 22:38:35

回复 #45 black_zerg 的帖子

严重同意,深有同感

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

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

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

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

yuba 发表于 30-4-2009 22:43:55

原帖由 key 于 30-4-2009 21:25 发表 http://www.freeoz.org/forum/images/common/back.gif
Refactor这本书一开始就教人要把代码改来改去,但事实上,写Refactor的那个人是做软件咨询的,
别人不改代码,他就没饭吃了……

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

key 发表于 30-4-2009 23:16:35

原帖由 yuba 于 30-4-2009 21:38 发表 http://www.freeoz.org/forum/images/common/back.gif
严重同意,深有同感

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

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

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

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

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

yuba 发表于 30-4-2009 23:45:06

回复 #50 key 的帖子

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

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

AOP是AO,本来就不OO

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

不想抬杠

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

hoopoos 发表于 1-5-2009 10:24:44

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

非常赞同!

ingeer 发表于 1-5-2009 10:48:03

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

key 发表于 1-5-2009 17:43:20

原帖由 ingeer 于 1-5-2009 09:48 发表 http://www.freeoz.org/forum/images/common/back.gif
Design Pattern 這東西讓沒經驗的新手看,看上一百年也不會懂的
不同的阶段看有不同的得益。新手学习,难免有点穿凿附会,但即使这样,得益还是很大的。

這東西是要靠多做自己摸出來後,到這本書裏去較對一下
有些部分能摸出来,有的就摸不了。

不過說實在太教條了每個人都有自己的習慣愛好,CODING 還是要有點FLEXIBILITY的
想省时省力,还是少点flexibility好一点。coding不是一个创意工业。
如果想发挥创造力,最好还是在architecture上下功夫。coding上做文章……
不是不行,而是一般人没有这个精力,达不到这个高度,最后就只是在浪费时间。

不過別忘了老鼠抓光了,貓也會被掃地出門,所以嘛。。 CODING還是不要做得太好
这个很认同。我自己程序最大的缺点就是没有什么bug,后期维护接近0。。。。;P :(

yuba 发表于 1-5-2009 18:14:04

原帖由 key 于 1-5-2009 16:43 发表 http://www.freeoz.org/forum/images/common/back.gif
我自己程序最大的缺点就是没有什么bug,后期维护接近0

接近0不算啥

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

ingeer 发表于 7-5-2009 09:41:09

原帖由 key 于 1-5-2009 16:43 发表 http://www.freeoz.org/forum/images/common/back.gif

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


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


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


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

hoopoos 发表于 7-5-2009 10:21:01

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

key 发表于 7-5-2009 23:49:23

:loveliness:
原帖由 ingeer 于 7-5-2009 08:41 发表 http://www.freeoz.org/forum/images/common/back.gif



牛,您真牛,請繼續牛,咱是代碼民工,看個熱鬧
:loveliness:
您老牛一点,俺才是代码民工。你提倡flexible,俺提倡跟着别人屁股跑,高下之分,一目了然嘛
:handshake

caoglish 发表于 22-12-2013 01:15:02

本帖最后由 caoglish 于 22-12-2013 01:17 编辑


var visitable = function () {
    this.accept = function (visitor) {
      visitor.visit(this);
    };
};
element = new visitable();
element.name = "John";


visitor = {
    visit: function (visitable) {
      console.log(visitable.name);
    }
};

element.accept(visitor);


visitor = {
    visit: function (visitable) {
      console.log("name:" + visitable.name);
    }
};

element.accept(visitor);

visitor = {
    visit: function (visitable) {
      console.log("First Name:" + visitable.name);
    }
};

element.accept(visitor);


jsbin

Javascript 实现的例子

caoglish 发表于 22-12-2013 01:40:28

本帖最后由 caoglish 于 22-12-2013 01:43 编辑

var Client = function () {
this.setStrategy=function(strategy){
    this.strategy=strategy;
};
this.run=function(){
    strategy.run(this);
};
   
};
client = new Client();
client.name = "John";


strategy = {
   run: function (client) {
      console.log(client.name);
    }
};

client.setStrategy(strategy);
client.run();


strategy = {
   run: function (client) {
      console.log("name"+client.name);
    }
};

client.setStrategy(strategy);
client.run();

strategy = {
   run: function (client) {
      console.log("first name"+client.name);
    }
};
client.setStrategy(strategy);
client.run();jsbin

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


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

页: 1 [2] 3
查看完整版本: 以Visitor设计模式应对需求变化