我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式：介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖：

 

6、介面卡模式（Adapter）：

介面卡模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類相容性問題。主要分成三類：類的介面卡模式、物件的介面卡模式、介面的介面卡模式。

6.1 類的介面卡模式：

核心思想就是：有一個Source類，擁有一個方法，待適配，目標介面是Targetable，通過Adapter類，將Source的功能擴充套件到Targetable裡，看程式碼：

public class Source {
 
	public void method1() {
		System.out.println("this is original method!");
	}
}

public interface Targetable {
 
	/* 與原類中的方法相同 */
	public void method1();
 
	/* 新類的方法 */
	public void method2();
}

public class Adapter extends Source implements Targetable {
 
	@Override
	public void method2() {
		System.out.println("this is the targetable method!");
	}
}
 

Adapter類繼承Source類，實現Targetable介面，下面是測試類：

public class AdapterTest {
 
	public static void main(String[] args) {
		Targetable target = new Adapter();
		target.method1();
		target.method2();
	}
}

執行結果：

this is original method!
this is the targetable method!

6.2 物件的介面卡模式：

基本思路和類的介面卡模式相同，只是將Adapter類作修改，這次不繼承Source類，而是持有Source類的例項，以達到解決相容性的問題。看圖：

只需要修改Adapter類的原始碼即可

public class Wrapper implements Targetable {
 
	private Source source;
	
	public Wrapper(Source source){
		super();
		this.source = source;
	}
	@Override
	public void method2() {
		System.out.println("this is the targetable method!");
	}
 
	@Override
	public void method1() {
		source.method1();
	}
}

測試類：

public class AdapterTest {
 
	public static void main(String[] args) {
		Source source = new Source();
		Targetable target = new Wrapper(source);
		target.method1();
		target.method2();
	}
}

輸出與第一種一樣，只是適配的方法不同而已。

6.3 介面的介面卡模式：

有時我們寫的一個介面中有多個抽象方法，當我們寫該介面的實現類時，必須實現該介面的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了介面的介面卡模式，藉助於一個抽象類，該抽象類實現了該介面，實現了所有的方法，而我們不和原始的介面打交道，只和該抽象類取得聯絡，所以我們寫一個類，繼承該抽象類，重寫我們需要的方法就行。看一下類圖：

這個很好理解，在實際開發中，我們也常會遇到這種介面中定義了太多的方法，以致於有時我們在一些實現類中並不是都需要。看程式碼：

public interface Sourceable {
	
	public void method1();
	public void method2();
}

抽象類Wrapper2：

public abstract class Wrapper2 implements Sourceable{
	
	public void method1(){}
	public void method2(){}
}

public class SourceSub1 extends Wrapper2 {
	public void method1(){
		System.out.println("the sourceable interface's first Sub1!");
	}
}

public class SourceSub2 extends Wrapper2 {
	public void method1(){
		System.out.println("the sourceable interface's second Sub2!");
	}
}

public class WrapperTest {
 
	public static void main(String[] args) {
		Sourceable source1 = new SourceSub1();
		Sourceable source2 = new SourceSub2();
		
		source1.method1();
		source1.method2();
		source2.method1();
		source2.method2();
	}
}

執行結果：

the sourceable interface's first Sub1!
the sourceable interface's second Sub2!

講了這麼多，總結一下三種介面卡模式的應用場景：

類的介面卡模式：當希望將一個類轉換成滿足另一個新介面的類時，可以使用類的介面卡模式，建立一個新類，繼承原有的類，實現新的介面即可。

物件的介面卡模式：當希望將一個物件轉換成滿足另一個新介面的物件時，可以建立一個Wrapper類，持有原類的一個例項，在Wrapper類的方法中，呼叫例項的方法就行。

介面的介面卡模式：當不希望實現一個介面中所有的方法時，可以建立一個抽象類Wrapper，實現所有方法，我們寫別的類的時候，繼承抽象類即可。

 

7、裝飾模式（Decorator）：

 顧名思義，裝飾模式就是給一個物件增加一些新的功能，而且是動態的，要求裝飾物件和被裝飾物件實現同一個介面，裝飾物件持有被裝飾物件的例項，關係圖如下：

Source類是被裝飾類，Decorator類是一個裝飾類，可以為Source類動態的新增一些功能，程式碼如下：

public interface Sourceable {
	public void method();
}

public class Source implements Sourceable {
 
	@Override
	public void method() {
		System.out.println("the original method!");
	}
}

public class Decorator implements Sourceable {
 
	private Sourceable source;
	
	public Decorator(Sourceable source){
		super();
		this.source = source;
	}
	@Override
	public void method() {
		System.out.println("before decorator!");
		source.method();
		System.out.println("after decorator!");
	}
}

測試類：

public class DecoratorTest {
 
	public static void main(String[] args) {
		Sourceable source = new Source();
		Sourceable obj = new Decorator(source);
		obj.method();
	}
}

執行結果：

before decorator!
the original method!
after decorator!

裝飾器模式的應用場景：

（1）需要擴充套件一個類的功能。

（2）動態的為一個物件增加功能，而且還能動態撤銷。（繼承不能做到這一點，繼承的功能是靜態的，不能動態增刪。）

缺點：產生過多相似的物件，不易排錯！

 

8、代理模式（Proxy）：

其實每個模式名稱就表明了該模式的作用，代理模式就是多一個代理類出來，替原物件進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的資訊掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。再如我們有的時候打官司，我們需要請律師，因為律師在法律方面有專長，可以替我們進行操作，表達我們的想法。先來看看關係圖：

根據上文的闡述，代理模式就比較容易的理解了，我們看下程式碼：

public interface Sourceable {
	public void method();
}

public class Source implements Sourceable {
 
	@Override
	public void method() {
		System.out.println("the original method!");
	}
}

public class Proxy implements Sourceable {
 
	private Source source;
	public Proxy(){
		super();
		this.source = new Source();
	}
	@Override
	public void method() {
		before();
		source.method();
		atfer();
	}
	private void atfer() {
		System.out.println("after proxy!");
	}
	private void before() {
		System.out.println("before proxy!");
	}
}

測試類：

public class ProxyTest {
 
	public static void main(String[] args) {
		Sourceable source = new Proxy();
		source.method();
	}
 
}

執行結果：

before proxy!
the original method!
after proxy!

代理模式的應用場景：

如果已有的方法在使用的時候需要對原有的方法進行改進，此時有兩種辦法：

（1）修改原有的方法來適應。這樣違反了“對擴充套件開放，對修改關閉”的原則。

（2）就是採用一個代理類呼叫原有的方法，且對產生的結果進行控制。這種方法就是代理模式。

使用代理模式，可以將功能劃分的更加清晰，有助於後期維護！

看到這裡：你可能會將代理模式和上面的裝飾模式混淆了，但是，仔細看，兩者是有區別的：

（1）裝飾模式，是為了動態增加新的行為，執行主體是原類；
代理模式，是替原類操作，增加新的行為，執行主體是代理類。

（2）裝飾器模式關注於在一個物件上動態的新增方法，而代理模式關注於控制物件的訪問。
（3）代理模式，代理類可以對他的客戶隱藏一個物件的具體資訊，因此，當使用代理模式的時候，我們常常在一個代理類中建立一個物件的例項。裝飾器模式，我們通常的做法是將原始物件作為一個引數傳給裝飾著的構造器。
即：代理模式的代理和真實物件之間的物件通常在編譯時就已經確定了，而裝飾者能夠在執行時遞迴地被構造。

 

9、外觀模式（Facade）：

外觀模式是為了解決類與類之家的依賴關係的，像spring一樣，可以將類和類之間的關係配置到配置檔案中，而外觀模式就是將他們的關係放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面，看下類圖：（我們以一個計算機的啟動過程為例）

我們先看下實現類：

public class CPU {
	
	public void startup(){
		System.out.println("cpu startup!");
	}
	
	public void shutdown(){
		System.out.println("cpu shutdown!");
	}
}

public class Memory {
	
	public void startup(){
		System.out.println("memory startup!");
	}
	
	public void shutdown(){
		System.out.println("memory shutdown!");
	}
}

public class Disk {
	
	public void startup(){
		System.out.println("disk startup!");
	}
	
	public void shutdown(){
		System.out.println("disk shutdown!");
	}
}

public class Computer {
	private CPU cpu;
	private Memory memory;
	private Disk disk;
	
	public Computer(){
		cpu = new CPU();
		memory = new Memory();
		disk = new Disk();
	}
	
	public void startup(){
		System.out.println("start the computer!");
		cpu.startup();
		memory.startup();
		disk.startup();
		System.out.println("start computer finished!");
	}
	
	public void shutdown(){
		System.out.println("begin to close the computer!");
		cpu.shutdown();
		memory.shutdown();
		disk.shutdown();
		System.out.println("computer closed!");
	}
}

User類如下：

public class User {
 
	public static void main(String[] args) {
		Computer computer = new Computer();
		computer.startup();
		computer.shutdown();
	}
}

執行結果：

start the computer!
cpu startup!
memory startup!
disk startup!
start computer finished!
begin to close the computer!
cpu shutdown!
memory shutdown!
disk shutdown!
computer closed!

如果我們沒有Computer類，那麼，CPU、Memory、Disk他們之間將會相互持有例項，產生關係，這樣會造成嚴重的依賴，修改一個類，可能會帶來其他類的修改，這不是我們想要看到的，有了Computer類，他們之間的關係被放在了Computer類裡，這樣就起到了解耦的作用，這，就是外觀模式！
 

10、橋接模式（Bridge）：

橋接模式就是把事物和其具體實現分開，使他們各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣，JDBC進行連線資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的程式碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖：

實現程式碼：

先定義介面：

public interface Sourceable {
	public void method();
}

分別定義兩個實現類：

public class SourceSub1 implements Sourceable {
 
	@Override
	public void method() {
		System.out.println("this is the first sub!");
	}
}

public class SourceSub2 implements Sourceable {
 
	@Override
	public void method() {
		System.out.println("this is the second sub!");
	}
}

定義一個橋，持有Sourceable的一個例項：

public abstract class Bridge {
	private Sourceable source;
 
	public void method(){
		source.method();
	}
	
	public Sourceable getSource() {
		return source;
	}
 
	public void setSource(Sourceable source) {
		this.source = source;
	}
}

public class MyBridge extends Bridge {
	public void method(){
		getSource().method();
	}
}

測試類：

public class BridgeTest {
	
	public static void main(String[] args) {
		
		Bridge bridge = new MyBridge();
		
		/*呼叫第一個物件*/
		Sourceable source1 = new SourceSub1();
		bridge.setSource(source1);
		bridge.method();
		
		/*呼叫第二個物件*/
		Sourceable source2 = new SourceSub2();
		bridge.setSource(source2);
		bridge.method();
	}
}

執行結果：

this is the first sub!
this is the second sub!

這樣，就通過對Bridge類的呼叫，實現了對介面Sourceable的實現類SourceSub1和SourceSub2的呼叫。接下來我再畫個圖，大家就應該明白了，因為這個圖是我們JDBC連線的原理，有資料庫學習基礎的，一結合就都懂了。

 

11、組合模式（Composite）：

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便，看看關係圖：

直接來看程式碼：

public class TreeNode {
	
	private String name;
	private TreeNode parent;
	private Vector<TreeNode> children = new Vector<TreeNode>();
	
	public TreeNode(String name){
		this.name = name;
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		this.name = name;
	}
 
	public TreeNode getParent() {
		return parent;
	}
 
	public void setParent(TreeNode parent) {
		this.parent = parent;
	}
	
	//新增孩子節點
	public void add(TreeNode node){
		children.add(node);
	}
	
	//刪除孩子節點
	public void remove(TreeNode node){
		children.remove(node);
	}
	
	//取得孩子節點
	public Enumeration<TreeNode> getChildren(){
		return children.elements();
	}
}

public class Tree {
 
	TreeNode root = null;
 
	public Tree(String name) {
		root = new TreeNode(name);
	}
 
	public static void main(String[] args) {
		Tree tree = new Tree("A");
		TreeNode nodeB = new TreeNode("B");
		TreeNode nodeC = new TreeNode("C");
		
		nodeB.add(nodeC);
		tree.root.add(nodeB);
		System.out.println("build the tree finished!");
	}
}

使用場景：將多個物件組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

 

12、享元模式（Flyweight）：

享元模式的主要目的是實現物件的共享，即共享池，當系統中物件多的時候可以減少記憶體的開銷，通常與工廠模式一起使用。

FlyWeightFactory 負責建立和管理享元單位，當一個客戶端請求時，工廠需要檢查當前物件池中是否有符合條件的物件，如果有，就返回已經存在的物件，如果沒有，則建立一個新物件，FlyWeight 是超類。一提到共享池，我們很容易聯想到Java裡面的JDBC連線池，想想每個連線的特點，我們不難總結出：適用於作共享的一些物件，他們有一些共有的屬性，就拿資料庫連線池來說，url、driverClassName、username、password及dbname，這些屬性對於每個連線來說都是一樣的，所以就適合用享元模式來處理，建一個工廠類，將上述類似屬性作為內部資料，其他的作為外部資料，在方法呼叫時，當做引數傳進來，這樣就節省了很多空間，減少了例項的數量。

看個例子：

看下資料庫連線池的程式碼：

public class ConnectionPool {
	
	private Vector<Connection> pool;
	
	/*公有屬性*/
	private String url = "jdbc:mysql://localhost:3306/test";
	private String username = "root";
	private String password = "root";
	private String driverClassName = "com.mysql.jdbc.Driver";
 
	private int poolSize = 100;
	private static ConnectionPool instance = null;
	Connection conn = null;
 
	/*構造方法，做一些初始化工作*/
	private ConnectionPool() {
		pool = new Vector<Connection>(poolSize);
 
		for (int i = 0; i < poolSize; i++) {
			try {
				Class.forName(driverClassName);
				conn = DriverManager.getConnection(url, username, password);
				pool.add(conn);
			} catch (ClassNotFoundException e) {
				e.printStackTrace();
			} catch (SQLException e) {
				e.printStackTrace();
			}
		}
	}
 
	/* 返回連線到連線池 */
	public synchronized void release() {
		pool.add(conn);
	}
 
	/* 返回連線池中的一個數據庫連線 */
	public synchronized Connection getConnection() {
		if (pool.size() > 0) {
			Connection conn = pool.get(0);
			pool.remove(conn);
			return conn;
		} else {
			return null;
		}
	}
}

通過連線池的管理，實現了資料庫連線的共享，不需要每一次都重新建立連線，節省了資料庫重新建立的開銷，提升了系統的效能！

本章講解了7種結構型模式，因為篇幅的問題，剩下的11種行為型模式，我們將另起篇章！

 

原文轉自：https://blog.csdn.net/zhangerqing/article/details/8239539