野人獻曝一下
可能是我習慣swing的設計方式吧
http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/
uiswing/components/border.html
縮：http://0rz.tw/QwN3l
Border機制的設計就是您說的這樣
以C 實作畫圈圈 D 實作畫框框的例子來說
我覺得a.setB(new C("要顯示的名字"));
或 a.setB(new D(new Date()));並無奇怪之處
所以XYZ應該也能以此類推
對我來說這種設計在現在或預想中都沒有壞處
所以我覺得他是好設計：）
離題一下....
像上面這種寫法
繪圖物件中會包含一個負責繪出邊框的物件
所以我們在component.paint時不用傳入所需資訊
（例如邊框資訊）
這可以避免出現像是以下
paint(Object arg);
paint(Object ... args);
不定參數、陣列參數、Object（最上層物件）出現的機會
我總覺得這種寫法會不清楚arg這個參數的用途
（負責定義此method的人那時候也根本不知道後來的人會丟啥吧= ="）
而arg本身的用途也只有實作的人知道
且這種寫法可能會導致大量的轉型及if敘述
另一個原因是我討厭看到參數很~長的method（光看就覺得很累）
所以個人是不太喜歡@@
另外我很佩服他的是在於抽象化的部份
Border這個interface別人只需實作3個method就能應付大部分
想像到的border樣式（雖然說paintBorder有點近乎作弊啦...）
如果抽象化做的不好的話
以後就可能遇到此介面無法處理的情況
那只好修改介面或增加其他介面
至於沒有參數會不會很奇怪
我覺得不會，畢竟沒有理由要使他一定要有參數
雖然說我總覺得不可能會沒有參數
（例如：要畫的內容、要記錄的內容、要傳遞的目的地...等等）
不過這應該要看您的實作...大家說不準的
嗯...另外
若A提供了（使用BXYZ）處理事情的骨架
如您說的
a.function(){
b.畫畫() ;
x.紀錄() ;
y.傳送圖片() ;
}
BXYZ就應該要是可以代換的
例如Y的後代實作了多種傳送的方式
Socket、FTP、EMAIL甚至是傳真（咦
且必須的資訊都已經在new的時候給足了
那A就無需計較現在的"y"到底會怎麼傳送
（當然使用A的人有可能還是要留意傳送方式）
如：
Y sender = SenderFactory.createMailSender("name","passwd",otherInfo);
a.setY(sender);
...
//a畫圖並記錄後，以email的方式送出
a.doFunction();
最後，如果上述的b、x、y很多而且常常是一套的一起換
那應該可以用AbstractFactory組織起來
例如您的情況是"產生一張gif（畫畫）、
把檔名寫在mail內容中（記錄）並寄到某個信箱（傳送圖片）"
以及"畫出一幅ASCII ART後把'luoqr'附在下面，並以純文字存在電腦的某個資料夾中"
只有這幾種情況的話
應該能寫成
void doFunction(ProcessorFactory p){
p.createPainter().畫畫();
p.createLogger().記錄();
p.createSender().傳送圖片();
}
然後實作幾種ProcessorFactory分別對應幾種情況
這樣就不用每次要換都要set set set
（可以只要setProcessorFactory就好）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.124.147.238
※ 編輯: kanandg1 來自: 140.124.181.25 (07/18 18:15)
推
07/21 08:50, , 1F
07/21 08:50, 1F
討論串 (同標題文章)