※ 引述《H45 (!H45)》之銘言： : 使用裝飾者的角度來看更顯得怪異 : 因為Decorator Pattern是動態地將責任加諸於物件上 : 但是Square似乎沒什麼更多的責任可以加諸在Rectangle上 : Square只是一種長和寬相等的Rectangle罷了 : 提不上是Rectangle的什麼裝飾者 : 所以我認為用裝飾者的角度來看，只是讓事情更複雜化而已 其實我也覺得用 decorator 會讓問題變得更加模糊難懂 回頭來看 Square 和 Rectangle, 這兩個東東會想怎麼操作他們？ 令 Rectangle 有 setWidth 和 setHeight, 那 Square 呢？同樣都有這兩個操作嗎？ 那麼為了防止失去 Square 的特性，是否要這樣實作 setWidth? public void setWidth(int num){ this.do_set_width_height(num); } public void setHeight(int num){ this.do_set_width_height(num); } private void do_set_width_height(int num){ this.width_ = this.height_ = num; } 不知道這樣做有沒有意義？如果 setWidth 和 setHeight 實際上做的事 根本就完全一樣。假使增加這兩個 method 純粹只是為了和 Rectangle 有相似的介面，那試問，當你呼叫 setWidth 時，你會想得到 height 其實也變了？ 假若讓 setWidth 就單純只是 setWidth, 那是否又違反了 Square 的前提？ 丟 exception 不成？其實這同樣違反了 LSP, 因為原本並不會有 exception. 個人認為，Square 和 Rectangle 之間不應存在太多關係 令 abstract class Shape{...} 則 class Rectangle extends Shape{...} 與 class Square extends Shape{...} 覺得這樣比較合理一些 Rectangle 提供 setWidth 與 setHeight, 甚至 setWidthHeight(int, int); Square 僅提供 setWidthHegiht(int) 或 setSize or whatever you like 總之他們的操作介面是不一樣的，因為他們的特徵會影響到其操作介面 硬要讓他們有共通介面的話，就很容易出現預期外的行為 那如果 Rectangle 和 Square 之間其實有共用的程式碼怎麼辦？ 提供一個類似 pimpl 的東西給他們共同使用即可 http://en.wikipedia.org/wiki/Opaque_pointer 這邊就不針對名詞做解釋了，我不知道 Java 怎麼形容這種做法 寫成程式碼大概是這樣： class Rectangle_Stuff_Implement{ // 加底線看起來比較清楚，字型關係 protected Rectangle_Stuff_Implement(){...} // 只給 Rect 和 Square 用 protected void draw(int width, int height){...} ... } class Rectangle extends Shape{ private Rectangle_Stuff_Implement imp_ = new Rectangle_Stuff_Implement(); public void draw(){ imp_.draw(this.width_, this.height_); } ... } class Square extends Shape{ private Rectangle_Stuff_Implement imp_ = new Rectangle_Stuff_Implement(); public void draw(){ imp_.draw(this.length_, this.length_); } ... } 諸如此類 不過理所當然，考慮實作前，先要想的是問題到底是什麼（problem domain） 在這個 thread 中，有人提到不是所有的車都有雨刷， 雨刷怎麼可以當汽車與機車的共同屬性？ 呃，我想說除非我們是在做模擬現實世界的程式， 不然，說不定他想解決的問題裡，所有的汽車機車都有雨刷呢？ 在遊戲程式中，確實很可能會有這種事情發生，畢竟本來就不是在模擬現實 這也是為什麼我說為什麼物件導向可以被違反，更別提現實世界了 重點是問題是什麼，是不是會有這個狀況出現 一股腦把現實世界放進來考慮，常常只會造成不必要的複雜性 就好像上面的例子裡，也許我們根本就不在乎 Rectangle 的長寬到底是什麼 反正他就只是一種形狀嘛，說不定根本沒有外界可以操作的 setWidth 與 setHeight 那麼讓這兩者之間有著繼承關係，也不見得是那麼壞的事 或是直到我們有一天發現，確實是需要 setWidth 與 setHeight 的介面 那麼這時候，就很有可能得改變設計，把 Square 與 Rectangle 的繼承關係解除 我覺得有些話說得很好，需求會慢慢壓迫你尋求好的設計，此時好的設計就會慢慢浮現。 design pattern 也不是忽然出現的，他們是長時間在程式設計領域慢慢累積下來的， 不是誰忽然發明這麼偉大的設計，而是自然而然，我們就會想到這些解決辦法可以解決 某個很複雜的問題。但是當問題本身並沒有那麼複雜時，過度的設計也只是找自己麻煩 而已。 可以參考一下 Martin Fowler 的文章，Is Design Dead? http://www.martinfowler.com/articles/designDead.html Martin Fowler 是不少知名書籍的作者， 如 Refactoring, UML Distilled, Analysis Patterns 等 -- 　　『風車』が廻り続ける度に 『美しき』幻想が静かに紡がれ 　　　『焔』の揺らめきの外に 『腕』を伸ばす愚かな者達 －《Roman》5th Story 　『宝石』をより多く掴もうと 『朝と夜』の狭間を彷徨い続ける Track 10 　　『星屑』の砂の煌めきにも 『葡萄酒』の仄甘い陶酔を魅せ 黄昏の賢者 『賢者』が忌避する檻の中から 『伝言』の真意を彼等に問うだろう 　　『天使』が别れを告げし時 『地平線』は第五の物語を識る --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.135.28.18