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

[adrianshum (Alien)]

: → 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)
推 wctang:只要把 lock 視為 resource，很自然的就可以視為 RAII
推 H45:寫得好，研究中....
推 godfat:那是 RAII 沒錯
→ godfat:所以我會說有些行為是可以視為資源的
→ cplusplus:所以說，這種LOCAGUARD，動作都在CTOR裡了~ 不是嗎 :)
→ cplusplus:有些設計可以大大幫助整個程式的架構和安全，WHY NOT?
→ cplusplus:當然，是特例，如果一開始所說，只有某些地方適用
→ cplusplus:基本上設計CLASS還是很少在CTOR裡面做事情