[讨论]再论点圆球的设计问题------面向对象设计的实际运用

[zosatapo]

我近来看到一段文字，讲的是面向对象设计中的一些问题，我觉得跟前面大家提到的那个什么点，圆，球设计的问题比较相关的，不知道大家看到这段文字是什么感想。我觉得理论就是理论，我们不能灵活运用的话，已经使得理论打了一些折扣。
//-----------------------------------------------------
文章如下：
//-----------------------
繼承（Inheritance ）

絕對不要以 public inheritance 來實作 "IS-ALMOST-A" 的關係。我曾經看過某
些程式員，甚至是經驗豐富的程式員，以 public 方式繼承一個 base ，並以
「保存 base class 的語意」的方式改寫大部份虛擬函式。然而在此情況下，
某些時候以 Derived object 做為一個 Base object ，其行為並不完全是 Base
的client所期望。Robert Martin 常引用一個例子，從 Rectangle class 身上
衍生下來Square class 。正方形是矩形，這在數學上或許為真，但在 classes
的世界中不一定為真。例如，假設 Rectangle class 有一個虛擬函式 SetWidth(int)。
Square 設定寬度時應該很自然地也設定高度，使形狀永遠保持正方。但是程
式某處有一些碼，它們以多型方式（polymorphically ）運用Rectangle objects ，
它們並不預期寬度的改變也會影響高度，畢竟那對矩形而言不是真的。這是
「public inheritance 違反 LSP 」的一個好例子，因為 derived class
並未陳述與base class 相同的語意。它違反了 public inheritance 的關鍵誡律：
「不要求更多，也不承諾更少」。一點點不相容罷了，沒有人會以危險的方式這
麼使用 差勁的設計，然後再花更多天的時間去修正它。不要被誘惑，只要說 no
就是了。如果其行為不像 Base ，那就不要以「使它看起來像個 Base 」的方式
來衍生它。設計準則：總是確定 public inheritance 用以模塑 IS-A 和
並符合 求

[zosatapo]

Class 的設計與繼承
public inheritance 。publicinheritance 的目的是為了被既有的碼以多型方式(polymorphically)重複運用base結論明智地運用 inheritance 。如果你能夠單獨以 containment/delegation 表現出某個class相互關係，你應該那麼做。如果你需要 inheritance 但不想模塑出 IS-A 的關係，請使用 nonpublic inheritance 。如果你不需要多重繼承（multiple inheritance ）的威力，請使用單一繼承（single inheritance ）。一般而言，大而深的繼承體系特別難以理解，因此也就難以維護。Inheritance 是一個設計期的決定，必須捨去許多執行期的彈性。某些人以為，除非使用繼承機制，否則不算物件導向。那不是真的。儘量使用可
有效運作的解答中最簡單的一個，那麼你或許還有可能多享受幾年穩定而容易維護的碼。

[ajoo]

zosatapo(隆杰@宗山太保):
假設 Rectangle class 有一個虛擬函式 SetWidth(int)。
Square 設定寬度時應該很自然地也設定高度，使形狀永遠保持正方。但是程
式某處有一些碼，它們以多型方式（polymorphically ）運用Rectangle objects ，
它們並不預期寬度的改變也會影響高度，畢竟那對矩形而言不是真的

it depends how you define your interface.
If Rectangle is immutable, then it does not matter.
i.e.
Rect* setWidth(int i);//this will return a new instance of Rect.

I'm not saying that Square should be a subtype of Rect though.

Again, how do you design ClosedShape, Circle, Ellipse, Rect, Square and "Zheng n Bian Xing"?

[mylove0618]

关于圆不是椭圆的问题，我琢磨了很久。也许就是因为我解决实际问题的机会太少了。唉，这个概念要弄清楚估计得花些时间了。

[ajoo]

zosatapo(隆杰@宗山太保) :
about whether mutable/immutable rect can be subtype of square, this is quite theoretic. You can see in-depth study in some OO type theory book.
so that's not theory's fault.

[zosatapo]

当然了，你的方法也是解决方案之一的。我贴这些文字的目的就是为了说明，我们在应用面向对象理论的时候，不仅仅要考虑到理论同时也要考虑到实际应用的。因为我的理论是用来解决实际问题的。

学习理论是为了更好的为现实服务，不是为了理论而理论的。
因为如果是那样的，理论的道理也不会走多远的。

[richard_hu]

有道是“能抓老鼠的猫就是好猫”！

[lkcowboy]

gz

[shornmao]

任何事情都是有两面性的。
关于圆和椭圆的问题，在学术界也存在两种观点：

一种认为圆是椭圆的退化，持这种观点的人更多地从解析几何的角度来看，圆的曲线方程是椭圆的曲线方程的特殊形式，即半长轴和半短轴长度相等。这样就可以从抽象的角度统一圆和椭圆。
另一种则认为圆和椭圆是两种不同的形状，因为他们的性质不相同，这更多的是从传统的几何学的观点来看的。

从哲学的角度来看，就是用外延的方法还是内涵的方法来定义事物的区别。
二者没有绝对的错与对，不过从编程的角度来看，编程大多数是一个抽象过程，所以推荐使用前者的方法来建模。
至于使用继承还是组合，这和具体应用的要求有着密切的联系，实际上如果作为CAD的应用，不管是继承还是组合，可能都是不合时宜的。还记得在C++先驱的著作中频频提到的一个说明性的例子，point/point2d/point3d，作者自己也提到，实际上在任何一个实际的系统中都不会这样做，大多数情况下他们只使用point3d作为point的抽象，处理point的方法和point3d没有大的差别。
至于CSDN的文档中心中给出的解决方案，从学术角度上说是一个比较完美的例子，从圆和椭圆的集合观点来看，曲线就是有无数的满足一个曲线方程的点组成的点集，如果二进制机器可以处理无限这种情况的话，那真的就有完美的解决了。
所以脱离了需求，没有什么可谈的。《面向对象分析和设计》一书中说道，只有满足需求的设计，而没有完美的设计，即使是满足需求的设计，也总是存在不同的方案。

[magicblue]

这儿又开帖了，呵呵

所谓最佳设计取决于这个系统希望做什么事，包括现在与未来。对所谓的完美追求没有意义，也没有益处。正如C++不是完美的，如果有完美的语言，那么它仅仅是个玩具而已。

各位是数学家还是程序员？这种问题想的翻来覆去的好象没有必要吧，如果用它来教学还不错，用来讨论就……

[ajoo]

actually it is so easy!
just define interfaces for circle, ellipse. don't prebuild any subtype relation.
in your app, if you think circle should be treated as ellipse, write adapter.

ALL DONE.