Re: [問題] 想請問interface的具體意義
※ 引述《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
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 27 之 29 篇)：