與封裝相關

Question

我知道封裝意味着什麼。 但是這個問題在採訪中被問到了我。

我有一個要求，在我必須創建一個新的類。 如果在團隊中有人弄亂了班級的封裝部分，但整體上 所需的功能正常工作，並且讓我們假設其已交付給客戶端。

客戶因此可能面臨什麼樣的問題？

我試圖說安全規範會被違反，我們可以利用這個漏洞來增加一些東西並搞亂產品。但是他說客戶端並不知道任何有關增強代碼的知識。 我終於放棄了。

有沒有人可以幫我一些例子？

Answer 1

錯誤的封裝（不管它的意思）使得正確使用類更難。例如，如果你有兩個公共方法，它們應該只按正確的順序被調用，否則對象狀態就會變壞，這是一個封裝不好的例子 - 用戶不能從類定義中知道這些方法應該只能按此順序調用，並且班級沒有做任何事情來防止以錯誤的順序撥打電話，並且一旦用戶沒有猜到他被糾正的正確順序。

Answer 2

封裝不是程序的屬性。它是如何編寫程序的源代碼的屬性。因此，無法訪問源代碼的用戶（例如最終用戶）不會受到正確或不正確封裝的影響。你可以寫一個沒有任何封裝的程序，如果功能正常，最終用戶永遠不會注意到。

當然，那些能夠訪問代碼的人會受到封裝存在的影響，因爲它通常會調試舊代碼並更容易編寫新的正交代碼。因此，從某種意義上說，這確實會影響按時交付工作功能的能力，但在採訪中假定這是事實。

Answer 3

鑑於「客戶端不知道任何有關增強代碼的知識」，我假定他們自己並沒有使用API​​編寫任何代碼。對他們的後果只能通過分佈式代碼直接修改應該是對象私有部分的分佈式代碼......這意味着更多的庫和應用程序可能包含代碼，如果該類的工作方式發生更改，還需要修改代碼。所以，對軟件的更新可能會更大並且可能更難以部署。 （如果正確封裝成員函數無論如何都是內聯的，它仍然可以工作，因爲調用代碼仍然需要重新編譯）。

順便說一句，通過私有和受保護的封裝不是一個運行時安全功能......即使在編譯時，它的目的是作爲一個堅定的提醒客戶端代碼，某些東西不是直接訪問/修改，但即使使用重新演繹演員，模板專業化和其他hackery，也可以輕鬆繞過。

Answer 4

IMO可能面臨的最大問題是您會低估重構或實現新功能的成本。例如，用一個新的代理替代這個類作爲遠程代理的代理可能看起來很簡單，但是可能會遇到問題，因爲應用程序最終使用的內部代碼難以改變以供遠程使用。

可能會讓快捷方式節省一點時間，但由於這種低估，您最終會免費向憤怒的客戶回饋此次（以及更多）。

另一個嚴重的問題是，一個具有清晰接口的程序，然而通過用內部的東西來做討厭的東西，這個程序只是發臭。這是一個問題，但也是一個問題，因爲無論誰看到該代碼都會覺得可以爲未來的變化做類似的事情，特別是在時間壓力下。

從長遠來看，這將改變一碗爛腐爛的意大利細麪條的程序，任何人都會因爲無法解釋的波紋副作用而感到恐懼。這個「broken window」效果的描述在好書「實用程序員」中。