togoever
2007-10-01 13:33
谢谢BanQ大哥!请多指教啊!

刚来Jdon,看到了中国Java的希望!

http://www.jdon.com/jivejdon/thread/32771.html

rainerWJY
2007-10-01 22:33
我认为不要过于的执着于约束上面

你非要说oo思想就必须映射或者基本映射世间父子继承关系的所有映射,这本身就不合理不是么?

颗粒度不能过细,过细只会浪费资源啊。解决问题才是问题的关键。

manbaum
2007-10-21 00:04
正方形长方形的讨论是阎宏的书里的吧?我也记不清了。

他是说,大家都认为正方形是长方形的特例,那么就应该可以定义正方形继承长方形。作为长方形,有长和宽两个属性,而正方形有边长这一个属性。所以对于正方形来说,当边长、长、宽任何一个属性被修改时,都会把它们置成相同的值。

如果有个人写了段给长方形变形的代码,传入参数是一个长方形,先比较长和宽,如果长和宽相等或者长比宽小,就把长增一,然后循环再比较,直到长比宽大才停止。

这里出现一个问题,如果传进一个长方形,代码正常执行;如果传进一个正方形,则会是死循环,从而破坏了里氏替换原则。而里氏原则是不能被破坏的,由此只能得出结论,正方形不能继承长方形。

我觉得是阎宏瞎说八道,显然他没考虑清楚。只能说在他目前设计的长方形类下,正方形不能继承长方形。按他的这个设计,应该给长方形增加一个boolean属性, 指示当前类是否具有正方形的特征。从另一角度,也可以说,他的这个抽象并不代表长方形的本质,势必在应用中造成一定的问题。

damagegod
2007-11-18 02:17
用不到的东西就不用管?貌似记得某本书上说过这很危险。。。

accipiter
2007-11-19 15:55
阎宏的确是在瞎说八道,

死循环为什么就破坏了里氏替换原则???这个有定义吗?

死循环是它程序的bug,他举得例子是bug,他企图用bug来否认逻辑?

正方形能用他写的这个resize方法吗?不能,这是个bug,他显然没有考虑正方形这个特例。

再说清楚些,人能走路大家都承认吧,没腿的残疾人能走路吗?你能说残疾人不是人?只能说人这个类,走路这个方法写的有bug,没有考虑残疾人的情况。或者说走路这个方法/有没有腿 根本不是人的本质特征

[该贴被accipiter于2007-11-19 16:01修改过]

[该贴被accipiter于2008-04-24 10:20修改过]

javayuan
2007-12-02 19:01
在网上搜索关键字“长方形 正方形 子类”,就找到了这里。

我也感觉阎宏有点瞎扯,为啥偏给正方形加上一个side属性?

正方形是矩形的一个特例罢了,只不过width和length相等。

难道矩形的长和宽相等时,它就不是矩形了?这是什么?所谓的量变引起质变?

所以正方形根本是不存在的一个类别,只能说它是矩形的某种情况。

就像前面某朋友说的,60的妇女是女人的某种特殊情况,难道60的妇女就不是女人了?偏要分出年龄等于60这样的一个类出来?

还有那椭圆和圆也一样,圆是椭圆的一个特例而已。

yqj2065
2007-12-18 15:56
1、正方形和长方形的例子不是阎博士的,是bob大叔介绍LSP的例子。

2、Is a关系的本质问题的研究,导致了<design by contract>契约式设计的出现,在Eiffel中被支持。Meyer的咚咚。

3、模拟不可能绝对映射,

sleepinglord
2008-06-06 11:11
翻翻旧帖呵呵……随便说两句:

1.约束的问题:目前的OO语言和建模中确实没有很清楚明确地处理这个问题。面向契约的编程也并没有发展成什么样子。如果要我对约束是什么建模:我认为,约束是类的内部属性,同时它是特殊的aspect,它的所有结合点都在类内部(进行各种check)。每个类除了属性,功能,还要有一系列内部的aspects才算完整。继承的时候子类也应该继承这个aspect。当然它还要支持各种逻辑操作。……基于这个理念,或许我们能够更加OO地建模。或许能在java上整出一套框架?哈哈

2.那个给正方形resize的外部方法问题,应该是阎宏同学脑残了。

3.关于女人是不是一定能生育,我觉得如果你要抠非得20-50岁的女人才能生育,那最好再继承出“育龄女人”这样的东西。

[该贴被sleepinglord于2008-06-06 11:12修改过]

freebox
2008-06-06 17:33
分清这种继承是几何学上的概念还是在领域里的概念。如果不能符合领域意义,也就无所谓继承不继承了。

管理员是从民众继承来的,他不只负责管理,也要负责普通民众的社会交际,但是对于某一个企业的管理员账号,可能就是名副其实的“管理员”,他就负责管理,别的什么都不管。

同样是管理员,在不同的领域里就有不同的意义和从属。

其它的一些东西:UML有些表述在语言级别体现不良,比如关联、聚合、组合,体现在语言上就不是那么一回事了。

真能在语言层次上做到聚合必须通过聚合根访问,可能效果能好点。

nkhanxh
2008-09-16 22:07
没错,死循环就是他bug.谁规定长方形边长不能相等了。明明是自己考虑不周,还说不能继承啊。这么说就没有能继承的了。任何一个继承,我都能做出来反例,你只要找出子类特殊化父类地方,肯定能写出类似代码。

liuxingwei
2008-10-09 13:03
《敏捷软件开发-原则模式与实践》中不是在讨论开-闭原则的时候讨论了这个问题,而是在Liskov替换原则一章讨论了这个问题。

这一章对这一问题的讨论是很深刻的,抽丝剥茧,有理有据。由于这种继承违反了lSP,造成的运行时动态产生的错误,在测试和纠错方面都有严重的困难。

liuxingwei
2008-10-09 13:12
这个问题和《Header First 设计模式》的那个鸭子的例子是共通的,也许读了那个例子,会少些争论。

snowwolf
2009-07-03 11:49
正方形继承矩形类的做法无疑是错误的:

对于那个变形方法来说,他获得的对象是矩形,因为矩形的行为中定义了长宽可以分别做任意修改而不会互相影响。用一个类继承矩形没有错,错就错在这个类修改了父类的这种行为。

其实从开闭原则更容易看待这个问题。分别设置高和宽是矩形类的public方法,这两个方法是“开”的。在正方形类继承他的时候,他可以重写这两个方法,没有问题,但在方法的实现上实质是正方形类“闭”了一个方法,简单的来说就是正方形类想“private”setWidth()或setHeight()。子类绝对是不能“闭”父类“开”属性的。

由此引申继承的问题,extends关键字代表“扩展”,即子类应该是扩展了父类的行为和属性,而不应该是加入了更多的约束。即子类应该比父类更“开”,而不可能是更“闭”。

PS:“正方形是一个矩形”这句话其实没说完,完整的表达是这样的“正方形是矩形的一个特例”。从这里可以看出来,正方形只是矩形这个类的一个实例,创造这个实例的人应该自己管理他对这个实例的约束。而如果你要从这种带有约束性质的实例来抽象出一个类,那么这个类绝对不可以从这些实例的类中继承。

再说简单点:在一个矩形对象恰好在宽、高相等的时候,我们才从概念上认为它是“正方形”。

猜你喜欢
3Go 上一页 1 2 3