奇葩 基於 設計 就會 函數 面向 自動 成員 好的

轉自知乎

我個人覺得很有用 我就將其轉載過來，大家有興趣可以看下。

沒有人還記得面向對象原本要解決的問題是什麽，這就是我們現在所面臨的困境。

面向對象原本要解決什麽（或者說有什麽優良特性）
似乎很簡單，但實際又很不簡單：面向對象三要素封裝、繼承、多態

封裝：封裝的意義，在於明確標識出允許外部使用的所有成員函數和數據項，或者叫接口。

繼承+多態：繼承和多態必須一起說。一旦割裂，就說明理解上已經誤入歧途了。

先說繼承：繼承同時具有兩種含義：其一是繼承基類的方法，並做出自己的改變和/或擴展——號稱解決了代碼重用問題；其二是聲明某個子類兼容於某基類（或者說，接口上完全兼容於基類），外部調用者可無需關註其差別（內部機制會自動把請求派發[dispatch]到合適的邏輯）。

再說多態：基於對象所屬類的不同，外部對同一個方法的調用，實際執行的邏輯不同。

很顯然，多態實際上是依附於繼承的兩種含義的：“改變”和“擴展”本身就意味著必須有機制去自動選用你改變/擴展過的版本，故無多態，則兩種含義就不可能實現。 繼承的第二種含義非常重要。它又叫“接口繼承”。
接口繼承實質上是要求“做出一個良好的抽象，這個抽象規定了一個兼容接口，使得外部調用者無需關心具體細節，可一視同仁的處理實現了特定接口的所有對象”——這在程序設計上，叫做歸一化。 真正的封裝是，經過深入的思考，做出良好的抽象，給出“完整且最小”的接口，並使得內部細節可以對外透明（註意：對外透明的意思是，外部調用者可以順利的得到自己想要的任何功能，完全意識不到內部細節的存在；而不是外部調用者為了完成某個功能、卻被礙手礙腳的private聲明弄得火冒三丈；最終只能通過怪異、復雜甚至奇葩的機制，才能更改他必須關註的細節——而且這種訪問往往被實現的如此復雜，以至於稍不註意就會釀成大禍）。

面向對象——淺談弊端