設計模式之---橋接模式

還是舉例說明吧！現在有一個問題，那就是手機和手機應用。手機有很多牌子，應用也有很多，那某個手機上的應用，該怎麼實現呢。

第一種架構：

這種架構非常簡單，但有個明顯的問題，那就是可擴展性差。比如再來一種手機或者應用，那類又得增加好幾個。他雖然符合開放封閉原則，但卻違背了職責單一性原則，即一個類應該只有一個引起它變化的原因。這個時候，橋接模式就派上用場了。

從UML類圖裏我們就能看出來，它使用了類的聚合而不是繼承，設計模式裏有一個原則，那就是合成/聚合複用原則。即儘量使用合成/聚合而不是繼承。這是爲了提高類的可複用性。

上代碼：

package bridge;

public abstract class Phone {
	protected App app;
	public abstract void phone();
	public App getApp() {
		return app;
	}
	public void setApp(App app) {
		this.app = app;
	}
	public void useApp() {
		phone();app.app();
	}
}

package bridge;

public class IPhone extends Phone {

	@Override
	public void phone() {
		// TODO Auto-generated method stub
		System.out.print("--IPhone--");
	}

}

package bridge;

public class Android extends Phone {

	@Override
	public void phone() {
		// TODO Auto-generated method stub
		System.out.print("--Android--");
	}

}

package bridge;

public interface App {
	void app();
}

package bridge;

public class Game implements App {

	@Override
	public void app() {
		// TODO Auto-generated method stub
		System.out.println("play game");
	}

}

package bridge;

public class MailList implements App {

	@Override
	public void app() {
		// TODO Auto-generated method stub
		System.out.println("open maillist");
	}

}

package bridge;

public class Client {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Phone iPhone=new IPhone();
		iPhone.setApp(new Game());
		iPhone.useApp();
		
		Phone android=new Android();
		android.setApp(new MailList());
		android.useApp();
	}

}

橋接模式就是解決了這種多維度變化的類的組合問題。

jdbc就應用了橋接模式

不同的數據庫管理系統可以任意切換，但對應用程序的實現影響不大。