今天犯了個錯：
“接口變動，傷筋動骨，除非你确定隻有你一個人在用”。哪怕隻是throw了一個新的exception。哈哈，這是我犯的錯誤。
類，即一個對象。
先抽象類，就是抽象出類的基礎部分，即抽象基類（抽象類）。官方定義讓人費解，但是記憶方法是也不錯的 — 包含抽象方法的類叫做抽象類。
接口就是把抽象的深度更深，它就像用簡短的非邏輯的一些規則表示類之間的關系。可以比作協定，比如通信使用的udp/tcp協定等。
小結：類與接口是java語言的基本抽象單元。
a. 向上轉型為多個基類型
如此，會給開發帶來相當大的靈活性。比如女神劉亦菲（class），實作了
明星 和 女人 的接口。這樣在複雜的繼承結構的某類中使用它，以後在調用seestar(star star)或者seewomen(women
women)方法時，隻要傳入其實作類（劉亦菲）即可。這也就是常說的接口可以多實作，達到了完全解耦。
b. 可複用性
即根據接口定義，讓建立類有了遵循的”協定“（規則）。whatever~ 要做的僅僅建立一個接口，為了保證生成對象的非耦合。如此而來，接口的使用讓代碼更具可複用性，通用性和靈活性。但并不是那麼萬能。後面使用守則會講到。
前人大牛總結了一些設計模式，也就是接口衍生出的一些設計模式。設計模式就是文法糖的甜蜜吧。接口讓我們嘗到了甜蜜。和我身邊的一杯starbucks的熱巧克力一樣。有點太甜。比如：
a.政策模式 — 方法中參數使用接口，傳入的參數對象（實作類）即包含了執行的代碼。如圖：
調用過程如下，在方法中出入實作而已：
b. 擴充卡模式 — 接口擴充卡（interface adapter）類，可以将不同源配到同一個目标。即暴露目标接口和實作源有共同的方法，擴充卡類怎麼适配呢？實作目标接口，并關聯了實作源對象，在實作方法中調用關聯實作源真正對象，然後在裡面進行各種适配操作。比如再關聯一個源什麼的。如圖：
這其實有點aop的味道。比如spring aop架構對beforeadvice、afteradvice、throwsadvice三種通知類型的支援實際上是借助擴充卡模式來實作的。
c. 工廠模式 — 工廠對象将生成接口某個實作的對象。進而代碼将實作和接口的實作分離，比較透明地将某個實作透明地替換成另一個實作。但是這裡工廠調用方法是靜态的，也就是簡單工廠模式（靜态工廠模式）。動态工廠模式無非是使用了反射達到了動态調用。
第一、盡可能使每一個類或成員不被外界通路
這裡的外界有個度，比如包級或者公有的。這樣子可以更好地子產品化，子產品與子產品之間通過暴露的api調動。這樣如果有個子產品改動接口或者類。隻要擔心該子產品，而不會涉及其他子產品。
第二、适當的使用類（抽象類）繼承，更多的使用複合
繼承，實作了代碼重用。内部中使用繼承非常安全，但是要記住什麼時候使用繼承。即當子類真正是超類的子類型時，才适用繼承。否則盡可能使用複合，即在一個類中引用另一個類的執行個體。也就是說将另一個類包裝了一下，這也就是裝飾模式所展現的。
第三、優先考慮使用接口，相比抽象類
首先java隻許單繼承，這導緻抽象類定義收到極大的限制。二者，接口無法實作方法。但是java 8提供了函數式接口。
但是接口在設計的時候注意，設計公有接口必須謹慎。接口如果被公開發行，則肯定會被廣泛實作，那樣改接口幾乎不可能，會是巨大的工程。（這和我犯的錯誤一樣。）
第四、占時沒有第四了…
明白了 java接口和抽象類何時用？怎麼用？待續，有新的點補充吧