作者adrianshum (Alien)
看板OOAD
标题Re: [资料] 神之物件 (God object, Blob AntiPattern)
时间Fri Sep 14 20:32:17 2007
※ 引述《H45 (!H45)》之铭言：
: 个人的看法是「一致就是简单，视情况而定就是复杂。」
: constructor/destructor 要做什麽事情是非常直观的
: 而且永远都一样的：
: 「建构子永远只建立本物件初始的属性。」
: 除了初始化属性之外，其他的事情都不要做。
大致上认同. (握手)
: 让 constructor/destructor 来做 Lock/unlock 反而限制了功能
: 事实上在许多例子中并不需要把整个函式都锁起来
: 着名的 Writer/Reader 问题就是一例。
其实我之前回的时候, LockGuard 这特例我就有想起来.
所以我才特意写了 "没有很强的原因而妄顾本身设计的目的"
的一句.
LockGuard 算是一个很特别的应用.
会用到 LockGuard 最主要的原因是能够大大减少出问题
的机会. 如果是自己作 explicit lock/unlock 的话, 中途
有一个uncaught exception , 那个 mutex 就没人会去
unlock 它了.
这个 trick 是我觉得能接受的额外应用, 也没有其他选择
可以做到一样的效果
说到 Readers Writer Lock, 一样可以写对应的 LockGuard .
这个反而不是很大的问题.
[43]
Alien
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 202.22.246.26
1F：→ H45:既然是 uncaught exception, 那麽....仍然需要 unlock 它吗..? 09/14 20:41
2F：→ H45:这个特例我不太熟，请指教 m(_ _)m 09/14 20:42
3F：推 wctang:这是很典型的RAII，是C++处理资源的标准做法 09/15 00:29