功能向上聚合
Abstract作為抽象類和抽象方法，第一種情況是在聚合子類的通用性上起到作用，往往出現在重構過程中自然而然形成的一種層次結構～希望將多個子類的通用方法和邏輯提取到父層的抽象類。
這種重構情況的最極致表現就是：若再加入新的子類，子類只需要實現抽象類的abstract方法，而且可能就只用幾句話的簡單宣告，或者做一些屬性設定就可以了，往往只是用於區分子類的特徵，真正的邏輯處理實際上是在抽象類的方法內實現。這樣就極大地簡化了子類的程式碼邏輯量，實現子類層去耦合，抽象層高內聚的極佳效果
如下圖所示：可以看到流水線作為一個統一的物件抽象概念，下轄了分揀、抽檢、加工等子工序...，但是流水線是一個密集的工序，肯定具有大量上下文處理邏輯在裡面，那麼就加上一個抽象的類，交給抽象類來做，各個子工序只需要將自己份內的工序實現好就可以了。由抽象類來實現工序連線，上下文管理等，統一成為介面方法具體實現的邏輯代表。
設計模式中使用
我們們再舉個例子，Java MVC框架的鼻祖Struts Framework，是由Craig R. McClanahan設計創造。我相信很多人都聽說過Struts框架，其設計的Action物件都已經成為Web開發中控制的代名詞。這也是最早基於JavaEE的servlet規範的WEB層框架，讓老早的程式設計師見識到了MVC是什麼樣子（當然1.0並不是徹底的MVC），
好，我們看看他的一個非常簡化的架構圖，我們重點是說明它對Abstract的使用：
Struts1.x版本的內部使用了過濾鏈模式和命令模式的組合，當客戶端向Servlet發起請求，那麼作為Servlet的Struts實現ActionServlet就將請求排程進了Struts框架來處理。
我們可以看到圖中ActionCommand作為介面抽象，ActionCommandBase作為命令鏈的統一入口層抽象，AbstractCreateActoin、AbstractAuthorizeAction、AbstractExectionAction作為對業務Action的建立、授權和執行（Execture）的命令抽象層，最後一層CreateAction、AuthorizeAction、ExectionAction為父類提供具體Action的實現類。另外還有選擇、跳轉、異常等命令，
就是以命令鏈條串起來的形式，從Action被建立或選擇，到Action執行以及跳轉的Action全生命週期管理。
那麼我們從這個示例中看到了抽象（abstract）被大量的使用，主要就是通過設計模式的引入，將“業務執行（Action）”這個抽象的概念，在流程中用命令的方式進行了全生命週期的管理。那麼程式設計師寫的Action就徹底與Servlet解耦了，中間是通過Struts框架的過濾鏈和命令兩種設計模式的操作，使得控制層徹底獨立出來。備註：MVC的模型和檢視不在這個架構描述當中。
因此無論是以後的Struts2.0也好，Spring MVC也好，基本上都是沿著Struts1.0的設計思想進行不斷的優化。但是大體的方向在那個時候都已經成型了。唯獨是面向元件的JSF標準是另一種思路了，順便提一下，JSF的最初的規範設計還是Craig R. McClanahan操刀的。
