Re: [資料] 神之物件 (God object, Blob AntiPattern)
※ 引述《cplusplus (大口小口吃炒飯)》之銘言：
: 個人看法是...視情況而定
: 在constructor/destructor裡面做些事情也是蠻常見的事情...
: 甚至主要功能在裡面完成也是蠻常見的事情..
個人的看法是「一致就是簡單，視情況而定就是複雜。」
constructor/destructor 要做什麼事情是非常直觀的
而且永遠都一樣的：
「建構子永遠只建立本物件初始的屬性。」
除了初始化屬性之外，其他的事情都不要做。
: 例如做同步化的時候...常用到簡易的lock之類的東西..
: class Lock;
: void Function() // syn safe
: {
: Lock safe("LockName"); //constructor裡面幫你做同步化，加上封鎖
: ...
: ...
: ...
: return; // 在任何一點用任何方式離開都會呼叫destructor，解除封鎖
: }
: 這樣不會卡死，也不容易讓使用者誤用
: 當然你要把程式寫成
: Lock safe("LockName"); safe.lock();
: ...
: safe.unlock();
: 也是可以，只是程式風格的問題...
: 提供lock, unlock等功能也挺不錯，但這樣也提高了誤用的可能性，
: 且在上面的例子，每個離開點地方你也得加上 unlock，你也可以說在constructor裡加上
: 檢查做unlock，但這樣就失去lock/unlock對秤性了，你在constructor裡面不自動lock
: 在destructor卻自動unlock，這種設計也有人詬病...
: 所以如果我只是要一個很簡單的自動lock功能，上面的做法我覺得挺好的，
: 也是在constructor/destructor裡完成所有動作。
讓 constructor/destructor 來做 Lock/unlock 反而限制了功能
事實上在許多例子中並不需要把整個函式都鎖起來
著名的 Writer/Reader 問題就是一例。
: 我看本來的討論是說把"整個程式"寫在constructor，
: 當然，把"整個程式"寫在constructor當然就是件很糟糕的事情...
: 但是如果只是一些小功能的話，視情況我覺得並不一定要這麼排斥
: 所以我覺得不一定說 constructor 只能做物件屬性的初始化
: OO 不是要讓程式變得麻煩，是要變得簡單好管理又好懂
: class Sound;
: void Welcome()
: {
: Sound s("welcome.mp3"); // play welcome background music repeatly
: .....
: // leave the function, autoamtically call constructor to stop play.
: }
: 這樣也不會難懂吧，應該也不至於破壞整個架構吧
如果程式完全不會再修改當然是沒有問題
但是軟體不變的本質就是：
「改變！」
如果把播放聲音的功能直接寫在 constructor 中
未來需要把此聲音進行編碼、加密、過濾都沒辦法使用既有的物件
因為每次建立此物件就是要播放音樂，而事實上新的需求根本不要播放音樂
這個時候原本的設計就出現了大問題
所以把「播放」的功能獨立於另一個函式是非常直觀，而且容易維護的。
: ---
: 以上只是個人的想法，可以討論，但不要戰我啊 XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.211.211.53
推
09/16 00:31, , 1F
09/16 00:31, 1F
→
09/16 00:33, , 2F
09/16 00:33, 2F
→
09/16 00:34, , 3F
09/16 00:34, 3F
→
09/16 00:35, , 4F
09/16 00:35, 4F
討論串 (同標題文章)