08 | 理論五：介面vs抽象類的區別？如何用普通的類模擬抽象類和介面？
抽象類和介面能解決什麼程式設計問題？
抽象類不允許被例項化，只能被繼承，
抽象類： **復用，多型性的優雅實現；
為什麼需要介面？它能夠解決什麼程式設計問題？
介面：不允許例項化，只能被實現；不包含屬性和普通方法，包含抽象方法、靜態方法、default 方法；類實現介面時，必須實現抽象方法。
抽象類更多的是為了**復用，而介面就更側重於解耦，
如果要表示一種 is-a 的關係，並且是為了解決**復用問題，我們就用抽象類；如果要表示一種 has-a 關係，並且是為了解決抽象而非**復用問題，那我們就用介面。
09 | 理論六：為什麼基於介面而非實現程式設計？有必要為每個類都定義介面嗎？
「介面」就是一組「協議」或者「約定」，
「基於介面而非實現程式設計」這條原則的另乙個表述方式，是「基於抽象而非實現程式設計」。後者的表述方式其實更能體現這條原則的設計初衷。在軟體開發中，最大的挑戰之一就是需求的不斷變化，這也是考驗**設計好壞的乙個標準。越抽象、越頂層、越脫離具體某一實現的設計，越能提高**的靈活性，越能應對未來的需求變化。好的**設計，不僅能應對當下的需求，而且在將來需求發生變化的時候，仍然能夠在不破壞原有**設計的情況下靈活應對。而抽象就是提高**擴充套件性、靈活性、可維護性最有效的手段之一。
1.「基於介面而非實現程式設計」，這條原則的另乙個表述方式，是「基於抽象而非實現程式設計」。後者的表述方式其實更能體現這條原則的設計初衷。我們在做軟體開發的時候，一定要有抽象意識、封裝意識、介面意識。越抽象、越頂層、越脫離具體某一實現的設計，越能提高**的靈活性、擴充套件性、可維護性。
2. 我們在定義介面的時候，一方面，命名要足夠通用，不能包含跟具體實現相關的字眼；另一方面，與特定實現有關的方法不要定義在介面中。
3.「基於介面而非實現程式設計」這條原則，不僅僅可以指導非常細節的程式設計開發，還能指導更加上層的架構設計、系統設計等。比如，服務端與客戶端之間的「介面」設計、類庫的「介面」設計。
10 | 理論七：為何說要多用組合少用繼承？如何決定該用組合還是繼承？
為什麼不推薦使用繼承？
一方面，徒增了編碼的工作量；另一方面，也違背了我們之後要講的最小知識原則（least knowledge principle，也叫最少知識原則或者迪公尺特法則），暴露不該暴露的介面給外部，增加了類使用過程中被誤用的概率。
繼承最大的問題就在於：繼承層次過深、繼承關係過於複雜會影響到**的可讀性和可維護性。
組合相比繼承有哪些優勢？
我們可以利用組合（composition）、介面、委託（delegation）三個技術手段，一塊兒來解決剛剛繼承存在的問題。
表示 is-a 關係，支援多型特性，**復用。而這三個作用都可以通過其他技術手段來達成。比如 is-a 關係，我們可以通過組合和介面的 has-a 關係來替代；多型特性我們可以利用介面來實現；**復用我們可以通過組合和委託來實現。所以，從理論上講，通過組合、介面、委託三個技術手段，我們完全可以替換掉繼承，在專案中不用或者少用繼承關係，特別是一些複雜的繼承關係。
裝飾者模式（decorator pattern）、策略模式（strategy pattern）、組合模式（composite pattern）等都使用了組合關係，而模板模式（template pattern）使用了繼承關係。
物件導向程式設計思想 介面和抽象類
介面抽象類 是否可以被例項化否 否是否可以寫抽象方法是 是是否可以寫普通方法否 是是否可以寫 static 方法是 是是否可以寫 default 方法是 否是否可以寫屬性是 是訪問修飾符都為 public 可以自定義 抽象類描述了 is a 的關係，表示乙個類是什麼，可以解決 復用的問題。典型的場景...
介面與抽象類
介面與抽象類區別 個人總結 語法結構 1 型別可以繼承多個介面，但是只能繼承乙個抽象類，即不支援多重繼承。2 介面可以用於值型別和引用型別，例如struct和class，而抽象類不能用於值型別，只能用於引用型別。3 抽象類定義可以包括建構函式，字段資料，非抽象成員 具體實現 等，而介面只能包括抽象成...
介面與抽象類
抽象類 當抽象類作為父類時，他的子類對其中的抽象類方法有不同的方法體 簡單舉例為 classhorse mammal,ilangbound public int numeroflegs return 4 inte ce ilandbound int numberoflegs 介面例子 main函式 ...