很多人都認為抽象類和介面都「差不多」，於是就隨便選一種來開發專案。其實這是一種非常不明智的做法，若選擇上稍微有些錯誤，到了專案開發後期，這些錯誤將會越來越明顯，越來越大，最後直接導致專案的失敗。
在介面和抽象類的選擇上，必須遵守這樣乙個原則：行為模型應該總是通過介面而不是抽象類定義。為了說明其原因，下面試著通過抽象類建立行為模型，看看會出現什麼問題
某發電廠需要開發一套發電機，用來給城市居民供電。發電機的功率是發電廠最為關心的資料，所以當查詢發電機的功率時，發電機需要返回乙個表示功率的整數。
為了說明用抽象類定義可能出現的問題，下面用抽象類建立發動機的行為模型
public abstract class alternator又過了一段時間後，客戶發現當地經常刮大風，而且風力不小，於是客戶想開發一套風力發電機，風速便成了客戶關心的資料。於是，發電機必須返回乙個表示風速的整數
public abstract class windalternator extends alternator
這時，對於這些發電機，發電廠偶爾需要檢查一下是太陽能發電還是風力發電，**如下：
if (instanceof sunalternator)
if (instanceof windalternator)
無論什麼發電機，功率這個引數很重要。所以在所有具體類中，getpower()方法都有效。
隨著業務的發展，客戶想把太陽能和風力結合起來。太陽能發電和風力發電本身行為沒有任何變化，但新型的發電機同時支援兩種行為。在考慮如何定義新型的發電機時，抽象類和介面的差別開始顯示出來了。軟體設計原則之一是：以修改最少的**來應對需求。太陽能發電和風力發電已經過嚴格的測試，不存在已知的bug。為了開發新型發電機，就需要定義乙個sunwindalternator，如果讓sunwindalternator從抽象類alternator派生，那麼sunwindalternator將不支援針對太陽能發電和風力發電的instanceof操作，也就是說，當需要檢查發電機目前正在以太陽能形式發電還是以風力形式發電，那麼得到的答案永遠是：都不是。如果讓sunwindalternator從sunalternator派生，那麼得到的答案永遠都是：太陽能發電機；從windalternator派生也會遇到類似的問題。
什麼時候用抽象類什麼時候用介面
如果預計要建立元件的多個版本，則建立抽象類。抽象類提供簡單易行的方法來控制項版本。通過更新基類，所有繼承類都隨更改自動更新。另一方面，介面一旦建立就不能更改。如果需要介面的新版本，必須建立乙個全新的介面。如果建立的功能將在大範圍的全異物件間使用，則使用介面。抽象類應主要用於關係密切的物件，而介面最適...
java什麼時候用抽象類，什麼時候用介面
關於什麼時候用抽象類，什麼時候用介面，我在這裡做一下總結。首先看下面的例子 abstract class abstractstudent void smoke 所有的student被建立都會抽菸，是不是很搞笑？class student extends abstractstudent 上面這個學生抽...
什麼時候使用抽象類, 什麼時候使用介面
介面是一種協定，抽象類則相當於類模板。使用抽象類，而不要使用介面來分離協定與實現。如果需要提供多型層次結構的值型別，使用介面。如果乙個型別必須實現多個協定，或者協定適用於多種型別，使用介面。雖然抽象類和介面都支援將協定與實現分離開來，但介面不能指定以後版本中的新成員，而抽象類可以根據需要新增成員以支...