该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2005-02-02
看了半天,没有看出来楼主的意图。
是说:抽象的价值问题么?就是说,是是否值得去做抽象的问题么? |
|
返回顶楼 | |
发表时间:2005-02-23
其实楼主的逻辑很简单,他想反对“饿了就要吃饭”这句话的正确性,就举个例子说,我饿了,别人给我一碗狗饭,我吃了,就病了。什么?你说狗饭不是饭?凭什么只有人饭是饭,狗饭不是饭?从事务的普遍性上讲,结合三个##...(以下省略250字)所以“饿了就要吃饭”是错的,饿了不吃饭才是更普遍的真理.
|
|
返回顶楼 | |
发表时间:2005-02-23
jimmy_c 写道 其实楼主的逻辑很简单,他想反对“饿了就要吃饭”这句话的正确性,就举个例子说,我饿了,别人给我一碗狗饭,我吃了,就病了。什么?你说狗饭不是饭?凭什么只有人饭是饭,狗饭不是饭?从事务的普遍性上讲,结合三个##...(以下省略250字)所以“饿了就要吃饭”是错的,饿了不吃饭才是更普遍的真理.
肤浅,典型的见山是山,见水是水的理解。 你所看见的大部分都只是事物的表象,对这些表象进行抽象是徒劳无功及毫无意义的,驱动这种现象产生的内在本质规律才具有抽象的价值。 |
|
返回顶楼 | |
发表时间:2005-02-28
age0 写道 jimmy_c 写道 其实楼主的逻辑很简单,他想反对“饿了就要吃饭”这句话的正确性,就举个例子说,我饿了,别人给我一碗狗饭,我吃了,就病了。什么?你说狗饭不是饭?凭什么只有人饭是饭,狗饭不是饭?从事务的普遍性上讲,结合三个##...(以下省略250字)所以“饿了就要吃饭”是错的,饿了不吃饭才是更普遍的真理.
肤浅,典型的见山是山,见水是水的理解。 你所看见的大部分都只是事物的表象,对这些表象进行抽象是徒劳无功及毫无意义的,驱动这种现象产生的内在本质规律才具有抽象的价值。 没说错吧,说着说着就跑到三个代表上来了. |
|
返回顶楼 | |
发表时间:2005-03-28
搂住的意思比较杂
好像是说 不同抽象层次的东西 应该由同认识层次(或者不同职能层次)的人来完成。 而业务的抽象,不是设计的部分,因为抽象可以是无止境的,发散下去。dip虽然可以解决一定的问题,但其本身在代码实现过程中,会带来更多的需要抽象分析的东西。所以,dip不应该在特定的业务中去刻意追求,而应该由大量具体经验的人,在对抽象的业务(事物)进行归纳总结。 一般的人,只要注重使用抽象了的工具就可以了。 不知道是否是这个意思。。。。。 不过,感觉用哲学层次的表达没有必要。 |
|
返回顶楼 | |
发表时间:2005-03-28
wfeng007 写道 搂住的意思比较杂
好像是说 不同抽象层次的东西 应该由同认识层次(或者不同职能层次)的人来完成。 而业务的抽象,不是设计的部分,因为抽象可以是无止境的,发散下去。dip虽然可以解决一定的问题,但其本身在代码实现过程中,会带来更多的需要抽象分析的东西。所以,dip不应该在特定的业务中去刻意追求,而应该由大量具体经验的人,在对抽象的业务(事物)进行归纳总结。 一般的人,只要注重使用抽象了的工具就可以了。 不知道是否是这个意思。。。。。 不过,感觉用哲学层次的表达没有必要。 基本上就是这样,不过最近我也修正了自己的观点,DIP本身是一种方法工具,工具本身并没有任何错误,运用工具的人才可能会犯错。DIP在系统设计层面非常适用,因为系统层面的抽象适用范围广、持续时间长,一个好的系统抽象将会长久的运用下去,但是在短促多变的业务层面则不大适用,高层次的业务抽象没有实际意义,低层次的业务抽象又无法灵活应变。 |
|
返回顶楼 | |
发表时间:2005-04-04
age0 写道 基本上就是这样,不过最近我也修正了自己的观点,DIP本身是一种方法工具,工具本身并没有任何错误,运用工具的人才可能会犯错。DIP在系统设计层面非常适用,因为系统层面的抽象适用范围广、持续时间长,一个好的系统抽象将会长久的运用下去,但是在短促多变的业务层面则不大适用,高层次的业务抽象没有实际意义,低层次的业务抽象又无法灵活应变。 哈哈 随需应变 IBM哲学。。。 不过确实是这样 只有明确了主要目标(需求满足)后才能 更好的解决问题 其实软件工程中开头就讨论过了。。。 所以 应该认为在考虑 框架时 也应该 弄清在系统功能需求满足的情况后 最主要目标 是时间 是稳定性 是扩展性 还是安全性 我好像觉得 “时间“ 比较要紧吧。。。呵呵 |
|
返回顶楼 | |
发表时间:2005-07-12
DIP本身是一种方法工具,工具本身并没有任何错误,运用工具的人才可能会犯错。
------- 这句话才是正确的态度. 错误的不是吃饭本身, 而是吃的人有没有辨别出是人饭还是狗饭. 对于需求可能变化的情况, DIP是否应该被使用呢? 前面的讨论已经有人说的很清楚了, 只能用猜的. 一般来说, 经验丰富的人猜中的可能性大些. 不过既然都有可能错, DIP过的代码通常要简洁一些, 类之间的逻辑关系也清楚些, 更容易被人理解. 楼主以为如何呢? |
|
返回顶楼 | |
发表时间:2005-09-07
我的感觉是这样的,DIP这个原则是用在认识事物的某些阶段的,这个阶段可以叫做用理论指导实践的阶段。对于从实践中抽取理论这个阶段,DIP原则并不能用。
我就借着楼主的地盘,发表发表自己的看法吧,^-^。 很多人都说OO是符合人类认识世界的自然规律的。这是错误的。看起来好像我们可以渐进的(继承)不断的更深化我们的认识,但其实我们的认识有两个相反的方向,一个是不断泛化和抽象的方向,一个是不断特化和深入的方向。当然,另一个维度看过来就是归纳和演绎。OO提供的是一个不断特化的过程,要求我们一开始就给出最一般最抽象的概念,然后不断的特化以求描述客观。它没有提供泛化的能力。这不符合人的思维过程,不同人有不同的切入层次,但一般很少有直接到达最抽象或者最具体层次的能力。 Java是单根单继承的语言,所有的对象都是Object,可是Object是什么?是否相等,转换为字符串,得到Hashcode,获得类型信息,还有一堆用于同步的接口。我们想想,是不是我们所有的东西都是这样的?这些东西明显是计算机空间的东西,难道我们的领域空间的东西都这样?但是,我们也可以说Java的Object设计的其实挺好的,这也是没办法,在一个子类存在以前,父类必须存在!而要设计一个所有子类的父类,就只好给出一些领域空间的概念都不需要的属性了。 Java的Interface在很大程度上挽救了单根单继承,由于Interface强制不能有任何实现,也就保证了我们不会陷于计算机空间不能自拔。我们可以直接设计一些类型表达领域空间的概念。通过分析领域空间的概念及关系,最终我们能够设计出来一套类型体系,实现的时候在考虑怎么落实到解空间。 如果我们是用上面描述的思路解决问题的,那么DIP原则就自然被遵守了。但是前面那个分析阶段,显然DIP是不适用的。 |
|
返回顶楼 | |
发表时间:2005-09-07
DIP与其说是设计原则,倒不如说是设计目标来得更加贴切。
DIP所追求的高层次泛化抽象模型只能是在广泛性的探索和研究中归纳总结出来,在一般性的个别开发过程所得到的信息并不足以归纳出足够泛用的抽象模型。而OO也仅是一种方法工具,并没有强制约束应该以何种方式进行归纳或演绎,OO的功劳只是能够以自然幽雅的方式表达及展现DIP抽象模型而已。 所谓“OO提供的是一个不断特化的过程,要求我们一开始就给出最一般最抽象的概念,然后不断的特化以求描述客观”应该算是对OO的误解,OO建议好的系统应该建构在合理的抽象体系结构之上,但是并没有强制要求一开始就建立优秀的抽象设计,任何人都知道这是不可能的,任何好的抽象都必然是建立在归纳的基础之上。 |
|
返回顶楼 | |