==> 在 tinlans.bbs@whshs.cs.nccu.edu.tw (汀) 的文章中提到:
> > 於是這個機制就成了，在修改一個我不完全了解的程式(或者是黑箱)
> > 就像是在拆一個自己不是很了解的炸彈一樣
> > 你說這樣安不安全
> 也沒有你想的糟糕...
> 首先還是要強調一點，繼承不是要你拆，是要你拿來用，
> 所以小箱子標示為 private 的部分你不必動也不能動。
> public 通常是小箱子想放給外界使用的介面，
> 大多數的情形下你也會想提供相同形式的介面出去，
> 通常標為 public 的東西就是給外面亂戳亂玩也不會爆炸的，
> 如果你覺得小箱子有某些 public 的東西危險，
> 你還是可以把它 private 化，
> 或是標成 protected，
> 只給將來設計更大箱子的人使用。
補充一點。理想情況下, 任何 method, 尤其是 public method,
都會有 pre-condition 及 post-condition,
在執行前與執行後, 也都有 well-defined 的 invariant state。
好的 class 設計說明文件, 都應該明確道出這些事項。
有了這些 interface 的 contract,
仍可維持黑箱的實作隱密, 又不損白箱的透明度,
可降低許多「拆一個自己不是很了解的炸彈」的風險。
這也正是 Eiffel 爸爸 Bertrand Meyer 所提倡的
"design by contract" 的用意之一。
> 對於設計小箱子方面經驗很老到的人來說，
> 用他們設計出來的小箱子是非常安全的，
> 除非你用的是經驗很淺的人寫的小箱子，
> 不然就是故意要放炸彈炸死你的仇家寫的。
>
> 而經驗老不老到跟語言機制本身安全性的影響性，
> 在每個語言都一樣，
> 在 C 的時代人家嫌 pointer 不安全，
> 但是給經驗老到的人來寫照樣又快又安全，
> 程式彈性又大；
> C 不會檢查 array index out of bound 的問題，
> 經驗老到的 C programmer 反而將它視為優勢加以發揮和應用，
> 但是在寫 Java 的 programmer 就不這麼想。
說得好。
除了程式語言、方法論之外,
配套的流程、制度、discipline 往往更能決定安全性。
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 在這個世界上，你就愛一種東西，你就在你愛的這個東西裡
把自己練到完美，練到無懈可擊… 就這樣，你學會簡單而嚴肅…
你形成一種風格，唯你獨有。 劉大任
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>