论坛首页 Java企业应用论坛

论面向组合子程序设计方法 之 微步毂纹生

浏览 87528 次
该帖已经被评为精华帖
作者 正文
   发表时间:2005-08-08  
ajoo 写道

一个人说明白,比如你或者T1,倒还好说,毕竟你们本身对这个概念就有一定了解。

但是这么多人说理解,赞同,我就有点怀疑了。不大可能是我的表达能力超强(其实,对这个,我有自知之明的,以前多少次悲惨遭遇都是和我表达不清有关系),也许更可能的是,我的地瓜被当作土豆卖了。

说这话其实有点不知好歹,伤人一大片之嫌,先道个歉先。我是希望,说理解的同学们,好意我表示感谢,但是请还是仔细看看,别闹出我当年“歌德巴赫猜想?简单,就是一个加一个等于一对嘛”的错误来。


这人还是挺有意思啊~,可能是不同意的人多了才有战斗的欲望吧:),对于一种分析方法,可能在大的方向是有相同或者相似的地方,可能思考的方式或者细节上会有些不同,所以就投了赞成票。具体的还没有看到,希望能够快点出来,好拿过来比较比较~
0 请登录后投票
   发表时间:2005-08-08  
to:ajoo

如果我说我理解你的意思,你应该不会反对吧。:)

今天早上我跟徐昊聊了一下,修正了一下我对于“正交性”的观点,修正后的表述如下:

正交性不是坏事,能够正交的系统,看起来总是赏心悦目的。但是要达到正交性的设计,相当困难。当我们面对一个不熟悉的系统时,追求正交性,往往会追求得焦头烂额。

而借助DJ这样一种语言,我们可以发现系统内部各个组成部分相交的事实,以改进系统的设计。而不是假设“正交性”可以自然的、从一开始就设计出来。

你的BLOG里也写了:
类似于xp + refactoring,我们的组合子的建造也一样可以摸着石头过河,走一步看一步的。

那么我的问题就是:你要过河我是看出来了,你打算摸到的石头在哪里呢?
0 请登录后投票
   发表时间:2005-08-08  
看到最后面的那篇,开发的过程(或者称之为CO组合子推导过程)怎么跟XP 很相像呢? 心里有点异样的感觉,仔仔细细从头看到尾 可还是没发现有什么吸引人的地方啊? 莫非ajoo还在卖关子,要是这样的话,这个连载也可以放到CSDN上赚钱了。

不过不管怎样,至少道出一个软件开发的原则:先从简单的开始, 尽快让你的代码跑起来。
0 请登录后投票
   发表时间:2005-08-08  
老实说我不太清楚采用CO或FO在实际的项目中有什么重要位置,或者能够带来如何重要的进步。
如果我看不到它们的重要性,那么对它们大谈特谈我只会认为是毫无意义的噱头。
给我一个提得起兴趣的理由?
0 请登录后投票
   发表时间:2005-08-08  
partech 写道
老实说我不太清楚采用CO或FO在实际的项目中有什么重要位置,或者能够带来如何重要的进步。
如果我看不到它们的重要性,那么对它们大谈特谈我只会认为是毫无意义的噱头。
给我一个提得起兴趣的理由?

对单一项目而言,他的价值并不比OO来得更大。但是他会使你从单一项目中积累可复用元素的机会变大。这是我的体验。
0 请登录后投票
   发表时间:2005-08-08  
gigix 写道
对单一项目而言,他的价值并不比OO来得更大。但是他会使你从单一项目中积累可复用元素的机会变大。这是我的体验。

嗯,抽象了点,方便的话,能不能举个例子?
看来俺是落后了 ,俺用起来游刃有余的东西,被别人狠批,别人倡导的新玩意,俺提不起兴趣,老了,老了。
0 请登录后投票
   发表时间:2005-08-08  
partech 写道
gigix 写道
对单一项目而言,他的价值并不比OO来得更大。但是他会使你从单一项目中积累可复用元素的机会变大。这是我的体验。

嗯,抽象了点,方便的话,能不能举个例子?
看来俺是落后了 ,俺用起来游刃有余的东西,被别人狠批,别人倡导的新玩意,俺提不起兴趣,老了,老了。

这个,我就不举例子,因为没细想过,举出来须不好看。还是看ajoo举的例子罢。
其实也不能说是多么新的东西,因为用Java做产品的时候,需要更多的复用和灵活度,做着做着就会不知不觉的朝着这个方向走一走,想来这也应该是一个普遍现象,只不过没人把他提出来说说罢了。
0 请登录后投票
   发表时间:2005-08-08  
//================
对了。我说“CO不看需求”了么?如果说了,对不起,我撒谎了。
CO确实不是一个以需求为中心的方法论。它有自己的组合系统要关心。
但是需求也仍然在CO中有反映。我们前面提出的那些需求比如打印系统时间什么的不会被无中生有地实现。
只不过,在CO里面,这些需求不再影响系统架构,而是被实现为一个一个独立的组合子。同时,我们抛开需求之间复杂的逻辑关系,上来直奔主题而去就好了。
//================================


只要有一定的现实需求牵引, 那么你的组合子就不会有那么搞,从Logger 到SequenceLogger  再到 ErrorMessageLogger  等等有这么搞的吗 ? 被你搞的晕死 , 我从你的文章中看, 现在的CO 这是一个自己从最先unit 下开始往上上的过程, 所谓的这些都是你在没有任何的需求牵引下, 所写的组合子, 说实话我看不出一点你说的新鲜的东西, 唯一说明的就是这是从下往上, 有些好处, 但我们会不会因此而失去更多啊!
0 请登录后投票
   发表时间:2005-08-08  
gigix 写道
partech 写道
老实说我不太清楚采用CO或FO在实际的项目中有什么重要位置,或者能够带来如何重要的进步。
如果我看不到它们的重要性,那么对它们大谈特谈我只会认为是毫无意义的噱头。
给我一个提得起兴趣的理由?

对单一项目而言,他的价值并不比OO来得更大。但是他会使你从单一项目中积累可复用元素的机会变大。这是我的体验。

要是追求可复用的话,”单一职责“原则也是够用的。而且感觉ajoo在那里长篇大论的推导组合子的过程,有种潜在的脱离实际需求的危险,到最后,真正要将ajoo兄辛辛苦苦推导的一大堆CO结合到实际项目的时候,发现仅有一两个被实际采用,其他的那些都不知道猴年马月再被重用阿。
另外,组合子的推导通过重构推出似乎更加合理一些,这样的说法不知道会不会被ajoo一同狂骂说我看了半天没看懂。 
0 请登录后投票
   发表时间:2005-08-08  
引用

对了。我说“CO不看需求”了么?如果说了,对不起,我撒谎了。
CO确实不是一个以需求为中心的方法论。它有自己的组合系统要关心。
但是需求也仍然在CO中有反映。我们前面提出的那些需求比如打印系统时间什么的不会被无中生有地实现。
只不过,在CO里面,这些需求不再影响系统架构,而是被实现为一个一个独立的组合子。同时,我们抛开需求之间复杂的逻辑关系,上来直奔主题而去就好了。


这样看起来,就是存在那种在某个领域内搞定一切的系统架构?
这样的话,可以分为两种情况,一种是这里除了自定义组合规则以外就没有所谓的架构,因为规则总是可以自定义,所以有几乎无限的"不影响架构"的可扩展性。只有无才是无所不包,正因为没有架构,所以也不存在"影响需求架构"的需求。
另一点么,就是大家梦寐以求的永动机模型了。有了这个,不要说某个领域,简直可以包打天下。
或者,作者可能在这里还有另外一层意思
引用

...在CO里面,这些需求不再影响系统架构...

言下之意是除了"这些"之外,还有另外一些需求是要影响架构的。但是,如果有的话,怎么在架构设计的早期阶段把这些需求识别出来以免以后坏菜就变成一个非常重要的方面了,但这个,又会走上了老路。所以,我的猜想,在作者的蓝图中,应该是不存在这类东西的。
至于正交性,我的猜想,在某个领域中的主干部分,如果有深厚的领域经验,设计成正交性是有可能的。但是,对于主干之外的部分,从工程的角度来说,并没必要为了细枝末节而设计一个理论上看起来很爽的无所不包的模型。只不过,这里关于主干和细枝末节的识别也并不是一件简单的事情,所以才要有深厚的领域经验才行。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics