抽象類和接口 應用場景

原創 小奕是个胖子 2018-09-01 22:19

很多童鞋經常背誦抽象類和接口的區別，使用場景，但並沒有深入瞭解什麼時候使用他們，或者使用哪個更好，本文舉一小例，並不一定完全正確，歡迎讀者吐槽；


我們看一個銀行借款的領子，中國人民銀行管理並監督所有的銀行，它制定了一個規範，所有的銀行在進行借款時都必須遵守這個規範（基本接口）；

Version~0.1.0:

中國人民銀行定義了一個操作接口：

package GoodDesignPattern;

import java.util.Map;

public interface BankLoan {
	
	/**
	 * 銀行借款操作
	 * 每個公司都需要實現該方法，並針對自己公司員工的情況進行特殊操作，
	 * 比如判斷該員工是否有資格，能借款多少等等
	 * @return
	 */
	public Map<String, String>  loanOperation(String userId);

}

所有的銀行都必須遵守這個接口，進行具體的實現： 

package GoodDesignPattern;

import java.util.HashMap;
import java.util.Map;

public class ABC implements BankLoan {

	@Override
	public Map<String, String> loanOperation(String userId) {
		
		//所有銀行借款必須的校驗
		if(userId==null || userId.isEmpty()){
			System.out.println("userId爲空！");
			return null;
		}
		//所有銀行借款必須的校驗
		if(userId.length()!=32){
			System.out.println("userId格式錯誤，應該爲32位！"+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserExist(userId)){
			System.out.println("用戶不存在："+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserIllegal(userId)){
			System.out.println("用戶沒有資格進行借款："+userId);
			return null;
		}
		
		//業務邏輯
		Map<String, String> map = getResultMap(userId);
		return map;

	}
	
	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	public boolean queryUserExist(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢數據查詢判斷
	public boolean queryUserIllegal(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢相關信息
	public Map<String, String> getResultMap(String userId){
		Map<String, String> map = new HashMap<String, String>();
		
		map.put("name", "詹姆斯"); //此處爲了方便直接寫死
		map.put("amount", "100000"); //應根據userId，在系統進行一系列判斷計算，得出能借款金額，此處爲了方便直接寫死
		map.put("rankLevel", "A"); //應根據userId，在系統進行一系列判斷計算，得出用戶等級，此處爲了方便直接寫死
		//.....其它一些列操作
		
		return map;

	}
	

}


package GoodDesignPattern;

import java.util.HashMap;
import java.util.Map;

public class ICBC implements BankLoan {

	@Override
	public Map<String, String> loanOperation(String userId) {
		
		//所有銀行借款必須的校驗
		if(userId==null || userId.isEmpty()){
			System.out.println("userId爲空！");
			return null;
		}
		//所有銀行借款必須的校驗
		if(userId.length()!=32){
			System.out.println("userId格式錯誤，應該爲32位！"+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserExist(userId)){
			System.out.println("用戶不存在："+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserIllegal(userId)){
			System.out.println("用戶沒有資格進行借款："+userId);
			return null;
		}
		
		//業務邏輯
		Map<String, String> map = getResultMap(userId);
		return map;

	}
	
	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	public boolean queryUserExist(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢數據查詢判斷
	public boolean queryUserIllegal(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢相關信息
	public Map<String, String> getResultMap(String userId){
		Map<String, String> map = new HashMap<String, String>();
		
		map.put("amount", "100000"); //應根據userId，在系統進行一系列判斷計算，得出能借款金額，此處爲了方便直接寫死
		map.put("rankLevel", "A"); //應根據userId，在系統進行一系列判斷計算，得出用戶等級，此處爲了方便直接寫死
		//.....其它一些列操作
		
		return map;

	}
	

}
我們發現，每當一家銀行做此操作時，都會做一些校驗，並且他們都是類似的，這不僅繁瑣，而且有些銀行容易遺漏一些校驗操作；雖然校驗的邏輯大同小異，但是每個銀行都可能自己定義自己的方法名、判斷自己的業務邏輯，這樣的開發低效且中國人民銀行不方便管理，爲此，人行需要調整自己的規範，統一各個銀行的行爲；

Version~0.2.0:

中國人民銀行修改自己的規範：

之前的接口不變，新增一個抽象類：

package GoodDesignPattern;

import java.util.Map;

public abstract class CommonOpretion {
	
	public Map<String, String> loanOperation(String userId) {
		
		//所有銀行借款必須的校驗
		if(userId==null || userId.isEmpty()){
			System.out.println("userId爲空！");
			return null;
		}
		//所有銀行借款必須的校驗
		if(userId.length()!=32){
			System.out.println("userId格式錯誤，應該爲32位！"+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserExist(userId)){
			System.out.println("用戶不存在："+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserIllegal(userId)){
			System.out.println("用戶沒有資格進行借款："+userId);
			return null;
		}
		
		//業務邏輯
		Map<String, String> map = getResultMap(userId);
		return map;

	}
	
	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	protected abstract boolean queryUserExist(String userId);
	
	//根據數據庫查詢數據查詢判斷
	protected abstract boolean queryUserIllegal(String userId);
	
	//根據數據庫查詢相關信息
	protected abstract Map<String, String> getResultMap(String userId);
	
	
	

}
看看這個抽象類的邏輯，你可以看出來，把所有的公共邏輯都寫在裏面，具體的業務操作方法是抽象的，由具體的銀行去實現即可，看下銀行的實現： 

package GoodDesignPattern;

import java.util.HashMap;
import java.util.Map;

public class ABC extends CommonOpretion implements BankLoan {

	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	@Override
	public boolean queryUserExist(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢數據查詢判斷
	@Override
	public boolean queryUserIllegal(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢相關信息
	@Override
	public Map<String, String> getResultMap(String userId){
		Map<String, String> map = new HashMap<String, String>();
		
		map.put("name", "詹姆斯"); //此處爲了方便直接寫死
		map.put("amount", "100000"); //應根據userId，在系統進行一系列判斷計算，得出能借款金額，此處爲了方便直接寫死
		map.put("rankLevel", "A"); //應根據userId，在系統進行一系列判斷計算，得出用戶等級，此處爲了方便直接寫死
		//.....其它一些列操作
		
		return map;

	}
	

}


package GoodDesignPattern;

import java.util.HashMap;
import java.util.Map;

public class ICBC extends CommonOpretion implements BankLoan {

	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	@Override
	public boolean queryUserExist(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢數據查詢判斷
	@Override
	public boolean queryUserIllegal(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢相關信息
	@Override
	public Map<String, String> getResultMap(String userId){
		Map<String, String> map = new HashMap<String, String>();
		
		map.put("amount", "100000"); //應根據userId，在系統進行一系列判斷計算，得出能借款金額，此處爲了方便直接寫死
		map.put("rankLevel", "A"); //應根據userId，在系統進行一系列判斷計算，得出用戶等級，此處爲了方便直接寫死
		//.....其它一些列操作
		
		return map;

	}
	

}
每個銀行只要繼承這個抽象類，並實現對應的業務邏輯方法即可，一些校驗都統一放入抽象類中判斷，這樣，每個銀行的實現邏輯清晰、規範、不會遺漏校驗，當然如果抽象類中的某些抽象方法，有些銀行不想做具體實現，可以默認返回，當然這是一個缺陷，歡迎讀者提出更好的解決方案。

這個時候每個銀行又要實現抽象類，又要實現接口，他們感覺很麻煩且沒有必要，這個時候中國銀行又進行調整：

Version~0.3.0:
頂層接口還是不變，抽象類修改：由抽象類實現接口

package GoodDesignPattern;

import java.util.Map;

public abstract class CommonOpretion  implements BankLoan{
	
	@Override
	public Map<String, String> loanOperation(String userId) {
		
		//所有銀行借款必須的校驗
		if(userId==null || userId.isEmpty()){
			System.out.println("userId爲空！");
			return null;
		}
		//所有銀行借款必須的校驗
		if(userId.length()!=32){
			System.out.println("userId格式錯誤，應該爲32位！"+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserExist(userId)){
			System.out.println("用戶不存在："+userId);
			return null;
		}
		//所有銀行借款必須的校驗
		if(!queryUserIllegal(userId)){
			System.out.println("用戶沒有資格進行借款："+userId);
			return null;
		}
		
		//業務邏輯
		Map<String, String> map = getResultMap(userId);
		return map;

	}
	
	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	protected abstract boolean queryUserExist(String userId);
	
	//根據數據庫查詢數據查詢判斷
	protected abstract boolean queryUserIllegal(String userId);
	
	//根據數據庫查詢相關信息
	protected abstract Map<String, String> getResultMap(String userId);
	
	
	

}
具體銀行不再需要實現接口： 

package GoodDesignPattern;

import java.util.HashMap;
import java.util.Map;

public class ABC extends CommonOpretion {

	//根據數據庫查詢是否存在，根據自己公司的用戶表查詢
	@Override
	public boolean queryUserExist(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢數據查詢判斷
	@Override
	public boolean queryUserIllegal(String userId){
		return true; //return false;
	}
	
	//根據數據庫查詢相關信息
	@Override
	public Map<String, String> getResultMap(String userId){
		Map<String, String> map = new HashMap<String, String>();
		
		map.put("name", "詹姆斯"); //此處爲了方便直接寫死
		map.put("amount", "100000"); //應根據userId，在系統進行一系列判斷計算，得出能借款金額，此處爲了方便直接寫死
		map.put("rankLevel", "A"); //應根據userId，在系統進行一系列判斷計算，得出用戶等級，此處爲了方便直接寫死
		//.....其它一些列操作
		
		return map;

	}
	

}
到此一個體現接口和抽象類結合使用的簡單例子就說完了，謝謝～



發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Java設計模式和設計思想學習筆記

設計模式學習筆記 面向對象設計原則 單一職責 單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義爲：就一個類而言，應該只有一個引起它變化

HeapStone 2020-07-08 11:55:44

探究動態代理的祕密

1 代理模式 動態代理屬於代理模式，那究竟什麼是代理模式呢？ 說白了，代理模式就是爲對象提供一個代理以控制對某個對象的訪問，原對象被稱爲委託類，這個代理的實現被稱爲代理類。代理類在爲委託類預處理消息之後會將消息轉發給委託類，之後還

Geffin 2020-07-08 10:04:53

面向接口編程----思維

相信看到這篇文字的人已經不需要了解什麼是接口了，我就不再過多的做介紹了，直接步入正題，接口測試如何編寫。那麼在這一篇裏，我們用一個例子，讓各位對這個重要的編程思想有個直觀的印象。爲充分考慮到初學者，所以這個例子非常簡單，望各位高手見諒。

dwj_daiwenjie 2020-07-08 10:29:15

大話設計模式C++版本-04-代理模式

概念 代理模式：爲其他對象提供一種代理以控制對這個對象的訪問 使用場景 想在訪問一個類時做一些控制； 直接訪問對象時會帶來的問題，比如說：要訪問的對象在遠程的機器上。 一般步驟 將被代理者和代理者的共同行爲抽象出來作爲一個類

wkd_007 2020-07-08 10:27:39

大話設計模式C++版本-07-模板方法模式

概述 模板方法模式：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。 優點： 封裝不變部分，擴展可變部分 提取公共代碼，便於維護 行爲由父類控制，子類

wkd_007 2020-07-08 10:27:28

大話設計模式C++版本-05-工廠方法模式

概念 工廠方法模式：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。 與簡單工廠模式對比 簡單工廠模式最大優點就是工廠類中包含了必要的邏輯判斷，可以根據不同條件動態實例化相關的類，

wkd_007 2020-07-08 10:27:26

大話設計模式C++版本-06-原型模式

概念 原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。 原理：利用一個Clone函數來封裝了自身的拷貝構造函數，調用Clone函數時就會觸發拷貝構造。 使用場景 利用已有的一個原型對象，快速地生成和原型對

wkd_007 2020-07-08 10:27:25

大話設計模式C++版本-03-裝飾模式

概念 裝飾模式：動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾器模式相比生成子類更爲靈活。 允許向一個現有的對象添加新的功能，同時又不改變其結構 優點：裝飾類和被裝飾類可以獨立發展，不會相互耦合，裝飾模式是繼承的一個替代

wkd_007 2020-07-08 10:27:25

三、單例模式（Singleton Pattern）

1. 什麼是單例模式 單例模式屬於創建者模式，一個類只有一個全局實例 2. 單例模式的角色組成 只有一個角色，就是單例角色本身 3. 代碼示例 單例模式有兩種加載模式：懶漢式創建實例，餓漢式創建實例 懶漢式創建實例 pack

Lizza~ 2020-07-08 09:38:07

工廠方法模式違背了面向接口編程

http://www.w2bc.com/article/43755

BaldWinf 2020-07-08 09:36:34

設計模式之委派模式delegate

文章目錄概念樣例演示定義接口：IEmployee定義接口實現A:EmployeeA定義接口實現B:EmployeeB定義中介委派實現:TeamLeader------>本質上具體的委派delegate是這個TeamLeader定義

东山富哥 2020-07-08 09:07:36

使用設計模式出任CEO迎娶白富美(1)--畢業即失業

畢業 時間從不停留，也不是回憶令人消瘦。 真的看淡了風景，也不會再有任何請求。 2020年盛夏，陳二毛畢業了。 沒有找到工作，蝸居在城市，每天爲了房租發愁。 每逢傍晚，溜達到一個湖邊，買一注彩票，然後攥得緊緊的，彷彿那是二毛的未來

熊猫大哥大 2020-07-08 08:42:58

mybatis-cache緩存包解析

概述 緩存包是mybatis對緩存的抽象和實現，可爲其他模塊提供緩存的支持。其設計也很值得借鑑。 大概分爲 緩存定義（抽象、異常、緩存鍵） 緩存實現 緩存裝飾者 可以重點在於緩存策略裝飾模式實現，可以複習複習裝飾模式啦。 C

请叫我程序猿大人 2020-07-08 07:54:47

數據連接池的基本實現

1、 實現途徑： 編寫JdbcPool implements java.sql.DataSource類 l 靜態初始化塊 l getConnection() l release() 總結： 可以解決連接池的實現問題，但是必須要求編程人員熟

祁琼冉 2020-07-08 07:54:27

《C#設計模式》【裝飾者模式】

一：案例場景 在軟件開發中，我們經常想要對一類對象添加不同的功能，例如要給房子添加安防，房子暖氣，房子防水等，如果此時利用繼承來實現的話，就需要定義無數的類，如HouseSecuity（安防類）、HouseWarm（暖氣類）等，這樣就會

半杯新酒 2020-07-08 07:51:19