: tinlans 說的沒有錯，物件導向並不是要我們做無意義的繼承，但是物件導向也沒有 : 說一定要套封裝、繼承、多型。 : 光就「物件導向」這四個字的意義只是以「物件」為基礎來模擬 (Model) 真實世界的 : 東西，所以物件導向的分析第一步就是找出有哪些「物件」要被建立，儘管這個例子 : 簡單到物件少到只有兩三種：河內塔、盤子、或者柱子，但是這個問題是做練習還是 : 無意義什麼的我不管，在這邊就是討論如何以「物件」的角度來設計這樣的一個軟體。 基本上最古典的 OOP 定義就是指封裝、繼承、多型， 而僅有封裝這類， 一般被稱為 Object-based Programming 或 ADT programming， 它的設計精神與 OOP 差別就在於繼承和多型， 實際上它們的目的也有所不同； 以這個題目為例子， OOP 可以說是幾乎派不上用場， 事實上它也沒有必要派上用場， 套 ADT 就可以搞定， 甚至傳統的 procedural 就很足夠了； 這些狀況也是為什麼某語言很堅持支援 multi-paradigm， 而不要變成一個純 OOPL 的原因之一。 以最後寫出的程式來看， 如果不含繼承與多型， 我們只能說它是「以物件為基礎」設計而成的， 也就是 object-based 或 ADT。 : 在找出所有要被建立的「物件」之後，下一步就是找出每個物件之間的關係。當您了解 : 每個物件之間如何交流互動之後，才有辦法決定「物件」擁有哪些「成員」，而這些「 : 成員」也就是所謂的「屬性」和「方法」，儘管這個例子簡單到有些物件可能連一個「 : 方法」都沒有，但是河內塔擺明了就是在做練習而已，我儘可能地描述「物件導向」的 : 精神在哪邊，它是以何種思維來開發軟體的，如此而已。 這段做法事實上在 ADT 的年代就存在了， 只是大部分的教科書故意舉了 well-known 的東西， 譬如 stack 和 queue 之類的， 它們的定義已眾所皆知， 所以教科書直接將它們的定義當作 spec， 然後說明怎樣怎樣弄就會符合 ADT 的要求； 如果一個人的 knowledge 裡面並沒有 stack、queue、list 這些東西， 那麼他們找尋一個功能與之相同的物件所擁有的屬性和操作， 過程其實就是這樣子的， 而為它們設置一個名詞以及詳列規格 (也就是定義) 則是後來的事。 : 話說回來，河內塔問題用一個函式 (function) 就可以解決，它的複雜度低到不適合用 : 物件導向來模擬 (Model) 每個物件，它的所有變化也只有柱子的數目和盤子的數目，這 : 兩個變數的改變並不會使河內塔的問題用物件導向就比較好解決，所以真正要解決河內 : 塔問題的話，還是建議寫成一個函式就足夠了！ 所以我覺得， 如果出這題目的是老師， 這位老師可能並不是一位很理想的教師， 如果是自己給自己練習的， 那麼建議是換個題目比較好； 物件導向的用意是程式碼再利用、應付多變的需求等等， 並不適合用在這種 case。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.230.221.133 ※ 編輯: tinlans 來自: 61.230.221.133 (04/08 02:12)