物件導向其實不需要封裝

Note: 這裡的‘封裝(Encapsulation)’指的是限制對象訪問的語言特性，也被稱為資訊隱藏(information hiding)。翻譯的初衷在於看看一些不同的想法，作者的思考在某個層次上是有道理的，但並是完全正確。總之這裡有一個決策和角度的問題。

沒有封裝的OOP?

Python支援Object Oriented Programming, 卻沒有封裝(encapsulation). 許多都對此不解，但討論來討論去，最終的結論是OO壓根不需要封裝。 Python裡什麼公有的，如果在成員名字前加兩個底線則表示不能由外部使用，也即非介面類的成員。但也有辦法使用，當然風險自理。Python開發人員稱之為命名規範式的封裝，而非強制封裝。本質上，這並不是封裝，也沒有隱藏什麼。原因何在？

用電腦做個比喻 

我可以隨時開啟我的電腦，升級一下，或者換個組件，這很容易做到。如果硬體廠商也開始使用封裝，我們可能很難再開啟機箱，如果要加個記憶體或換個什麼，就只能送回廠家了。

如上封裝限制了對實現細節的使用。但確實需要時，就只能自己動手了。硬體上並沒有限制我把它開啟，軟體為什麼要這樣做？

使用抽象代替封裝 

一個關於抽象(abstraction)的定義說到: ‘the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.’.
從編程上看，意思就是在實現之上提供一個介面，使用者只需要知道介面層(即抽象層)，而不用關心實現的細節。與封裝的差異在於，如果使用者想要去瞭解那些潛在的細節，仍然可以做得到。絕大多數硬體都是使用抽象代替封裝，使用一個很少變化的介面，同時允許進階使用者窺看細節。

當使用抽象代替封裝時，使用者可以清楚地看到介面，和使用封裝的方式也沒什麼差別。我們鼓勵使用者使用開放的介面，但並不僅限於此。對於使用介面而言，抽象與封裝的效果是一樣的，只是前者允許訪問背後的內容。這樣使用者完全可以瞭解到他的行為可能帶來的風險。

一個執行個體 

假設我用一個跨平台的GUI庫來開發應用程式。跨平台的GUI庫好用，在不同平台上也保持相同的介面，會省去不少麻煩。

假設Windows使用者希望添加一個特別的功能。這個時候，你如果堅持封裝，你會面臨如下的問題::

• 在原來的GUI庫上實現一個新的庫，這樣就要包括其它的介面。
• 聯絡廠商做特殊修改，這個可能性不大，即使可行，也未必來得及！
• 放棄原先的庫，在Windows上使用新的庫。這個風險很高，成本也很高！

如果你轉而使用抽象呢? 除了上面的選項外，你可以動到庫裡的細節實現，不過要考慮一下幾個風險:

• 有沒有可以破壞其它行為。
• 庫的升級可能導致你的修改失敗，所以每次升級時都要檢查一下它的行為是否仍然正常。
• 當然庫的廠商可不一定願意為你提供支援人員了。

就是說，使用抽象代替封裝時，你一定要自行權衡利弊。我可不是鼓勵大家使用那些細節的內容，只是在一些情況下，這可能是一個最佳方案。

How I do it 

在傳統的OO語言，我將介面定義為public, 其它實現的細節內容我定義在protected中。四人幫曾經說: “因為繼承會將父類的實現細節暴露給子類，所以通常稱為‘繼承破壞了封裝’’”. 事實上，這正是我想要的效果。我的使用者可以使用public介面，如果需要，他們可以子類化自己的類。

這招讓我省了不少的事，我不用再糾結於private, protected或者public。我的座佑銘正是:Keep It Stupid Simple.

封裝不是安全 

把資料隱藏或者保護起來不讓使用者接觸到，通常講是很有必要的。但如果是要討論安全性，我認為通過封裝來實現安全性是極為糟糕的。

結論 

依賴於細節實現絕不是什麼好主意，所以只能使用類的公用介面。不過總有些意思不到情況讓你需要使用一些內部細節，這個時候最好把類設計更加有用一些，讓用記可以通過一些專業的方式來使用它。使用者不是白癡，要假定他們都是專家，可以很合理的使用你的類來解決一些問題。如果他們要訪問一些細節內容，自然有他們的理由，或許就是別無它法。所以，不要拿封裝來對付他們。

原文地址.

轉載請註明出處:http://blog.csdn.net/horkychen