夢想飛翔

    首先,如果沒有接口會怎么樣呢？一個類總歸可以從另一類繼承，難道還不夠么？

沒接口會怎么樣
    一個對象需要知道其他的一些對象，并且與其他的對象發生相互作用，這是因為這些對象需要借助于其他對象的行為以便完成一項工作。這些關于其他對象的知識，以及對其他對象行為的調用，都是使用硬代碼（Hardcode）寫在類里面的，可插入性幾乎為零。

    如果要加入一個新的類，僅僅意味著加入新的硬代碼，而不能給出動態的可插入行。
    那么基于類的繼承是否可以提供一點幫助呢？比如現在有一個具體類，提供某種使用硬代碼寫在類的行為。現在，要提供一些類似的行為，并且實現動態的可插入，也就是說，要能夠動態地決定使用那種實現。一個可能的做法就是為這個類提供一個抽象超類，生命出子類要提供的行為，然后讓這個具體類繼承自這個抽象超類。同時，為這個抽象超類提供另一個具體子類，這個子類以不同的方法實現了超類所生命的行為。客戶端可以動態決定那個具體子類。這是否可以提供可插入性呢？
    答案是，這卻是可以在簡單的情況下提供可插入性。但是由于java語言是一個單繼承的語言，換言之，一個類只能有一個超類，因此，在很多情況下，這個具體類可能已經有了以超類，這時候，要給它加上一個新的超類是不可能的，如果硬要加的話，就只好把這個新的超類加到已有的超類上面，形成超超類的情況；如果這個超超類的位置已經被占用了，就只好繼續向上移動，直到移動到類等級結構的最頂端。這樣一來，對一個具體類的可插入性設計，就變成了對整個等級結構中所有的類的修改。
    這還是假設這些超類都是在設計師控制之下的。如果這些超類是一些軟件商提供的，設計師無法修改，怎么辦呢？如果有一個具體類，它有一個超類是Frame，那么新加入的超類就只好一直向上移動到java.lang.Object類上面，這怎么可能呢？
    因此，沒有接口可插入性就沒有保證。

接口是對可插入性的保證
    接口使可插入性變得可能。
    在一個類等級結構中的任何一類可以實現一個接口，這個接口會影響到此類的所有子類，但是不會影響到此類的任何超類。此類將不得不實現這個接口所規定的方法，而其子類則可以從此類自動繼承到這些方法，當然也可以選擇置換掉所有的這些方法，或者其中的某一些方法。
    這時候，這些子類就具有了可插入性。

    關聯的可插入性

    正如前面所說的，一個對象需要完成一項任務，所以需要知道其他的對象，并且調用其他對象的方法。這個對象對其他對象的知識叫做關聯（Association）。
    如果一個關聯不是針對一個具體類的，而是針對一個接口的，那么任何實現這個接口的類就都可以滿足要求。換言之，當前對象并不在意所關聯的是哪一個具體類。而僅僅關心這個類是否實現了某一個借口。

    這樣一來，就可以動態地將這個關聯從一個具體類轉換到另一個具體類，而這樣做的唯一條件是它們都實現某個接口。

    調用的可插入性
    同樣，一個對象不可避免地需要調用其他對象的方法。這種調用不一定飛的是某一個具體類，而可以是一個接口。這樣一來，任何實現了這個接口的具體類都可以被當前對象調用；而當前對象到底調用的是哪一個具體的實例則完全可以動態地決定。
    因此，接口提供了關聯以及方法調用上的可插入性，軟件系統的規模越大，生命周期越長，接口的重要性就越大。接口使得軟件系統在靈活性和可擴展性、可插入性方面得到保證。