Re: [資料] 神之物件 (God object, Blob AntiPattern)

看板OOAD作者 (Alien)時間17年前 (2007/09/15 01:23), 編輯推噓3(305)
留言8則, 4人參與, 最新討論串12/19 (看更多)
: → H45:既然是 uncaught exception, 那麼....仍然需要 unlock 它嗎..? 09/14 20:41 : → H45:這個特例我不太熟,請指教 m(_ _)m 09/14 20:42 當然要呀 你自己的 function uncaught 而已,可能上層有作處理. 其實不止uncaught exception. LockGuard 這玩意也能 令 programmer 的錯失減少,要是要 explicit unlock 的話,萬一某些程況下漏寫了 Unlock 的話也是 很棘手 寫一個簡單的 LockGuard 例子吧 (以前參考某商業 C++ library 寫的自用 library 大概就是這樣做) : class MutexLock { public: void Lock(); void Unlock(); }; class LockGuard<class T> { public: LockGuard<T>::LockGuard<T>(T& lock) : m_lock(lock) { m_lock.Lock(); } LockGuard<T>::~LockGuard<T>() { m_lock.Unlock(); } private: T& m_lock; }; 用的情況: Foo::bar() { LockGuard<MutexLock> guard(m_myMutex); // do whatever u want // m_myMutex will be unlocked automatically } 假設 "do whatever u want" 有 exception 發生,或者 裡面 return 了,m_myMutex 也能正確被 unlock. LockGuard 還有很多變型 比如 UnlockGuard (在特定範圍暫時放開 lock, 範圍完結重新取得) TryLockGuard (嘗試取得 Lock,失敗的情況當然不會自動做 Unlock 嘍) 還有 ReadLockGuard/WriteLockGuard 這些比較特例的東西. : 推 wctang:這是很典型的RAII,是C++處理資源的標準做法 09/15 00:29 LockGuard 說是 RAII 好像也不全是,算是有點變奏? 因為一般來說 RAII 通常是在 constructor 取得並 initialize 好 resources. LockGuard 則單純對一個外部的 Mutex (or other kind of lock) 進行 lock/unlock 而已 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.77.26.195 ※ 編輯: adrianshum 來自: 219.77.26.195 (09/15 01:37)

09/15 10:59, , 1F
只要把 lock 視為 resource,很自然的就可以視為 RAII
09/15 10:59, 1F

09/15 13:38, , 2F
寫得好,研究中....
09/15 13:38, 2F

09/15 14:49, , 3F
那是 RAII 沒錯
09/15 14:49, 3F

09/15 14:51, , 4F
所以我會說有些行為是可以視為資源的
09/15 14:51, 4F

09/16 00:36, , 5F
所以說,這種LOCAGUARD,動作都在CTOR裡了~ 不是嗎 :)
09/16 00:36, 5F

09/16 00:37, , 6F
有些設計可以大大幫助整個程式的架構和安全,WHY NOT?
09/16 00:37, 6F

09/16 00:38, , 7F
當然,是特例,如果一開始所說,只有某些地方適用
09/16 00:38, 7F

09/16 00:39, , 8F
基本上設計CLASS還是很少在CTOR裡面做事情
09/16 00:39, 8F
文章代碼(AID): #16wiElrL (OOAD)
討論串 (同標題文章)
文章代碼(AID): #16wiElrL (OOAD)