一、什么是設計模式
設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。簡單說：
模式：在某些場景下，針對某類問題的某種通用的解決方案。
場景：項目所在的環境
問題：約束條件，項目目標等
解決方案：通用、可復用的設計，解決約束達到目標。
二、設計模式的六大原則
因為設計模式就是基於這些原則的實現，所以很有必要了解這些原則，下面主要對面向對象編程的幾個原則進行簡單介紹。
1、開閉原則（Open Close Principle）
開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。
2、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。
3、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對接口編程，依賴於抽象而不依賴於具體。
4、接口隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什么叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。
6、合成復用原則（Composite Reuse Principle）
原則是盡量使用合成/聚合的方式，而不是使用繼承。
三、設計模式的三個分類
創建型模式：對象實例化的模式，創建型模式用於解耦對象的實例化過程。
結構型模式：把類或對象結合在一起形成一個更大的結構。
行為型模式：類和對象如何交互，及划分責任和算法。
如下圖所示：
四、各分類中模式的關鍵點
創建型模式
單例模式：某個類只能有一個實例，提供一個全局的訪問點。
簡單工廠：一個工廠類根據傳入的參量決定創建出那一種產品類的實例。
工廠方法：定義一個創建對象的接口，讓子類決定實例化那個類。
抽象工廠：創建相關或依賴對象的家族，而無需明確指定具體類。
建造者模式：封裝一個復雜對象的構建過程，並可以按步驟構造。
原型模式：通過復制現有的實例來創建新的實例。
結構性模式
適配器模式：將一個類的方法接口轉換成客戶希望的另外一個接口。
組合模式：將對象組合成樹形結構以表示“”部分-整體“”的層次結構。
裝飾模式：動態的給對象添加新的功能。
代理模式：為其他對象提供一個代理以便控制這個對象的訪問。
亨元（蠅量）模式：通過共享技術來有效的支持大量細粒度的對象。
外觀模式：對外提供一個統一的方法，來訪問子系統中的一群接口。
橋接模式：將抽象部分和它的實現部分分離，使它們都可以獨立的變化。
行為型模式
模板模式：定義一個算法結構，而將一些步驟延遲到子類實現。
解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器。
策略模式：定義一系列算法，把他們封裝起來，並且使它們可以相互替換。
狀態模式：允許一個對象在其對象內部狀態改變時改變它的行為。
觀察者模式：對象間的一對多的依賴關系。
備忘錄模式：在不破壞封裝的前提下，保持對象的內部狀態。
中介者模式：用一個中介對象來封裝一系列的對象交互。
命令模式：將命令請求封裝為一個對象，使得可以用不同的請求來進行參數化。
訪問者模式：在不改變數據結構的前提下，增加作用於一組對象元素的新功能。
責任鏈模式：將請求的發送者和接收者解耦，使的多個對象都有處理這個請求的機會。
迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，不暴露該對象的內部結構。
五、八種常見設計模式詳解
1、單例模式
所謂的單例設計指的是一個類只允許產生一個實例化對象。
最好理解的一種設計模式，分為懶漢式和餓漢式。
1.1、餓漢式
——構造方法私有化，外部無法產生新的實例化對象，只能通過static方法取得實例化對象
class Singleton {
/**
* 在類的內部可以訪問私有結構，所以可以在類的內部產生實例化對象
*/
private static Singleton instance = new Singleton();
/**
* private 聲明構造
*/
private Singleton() {
}
/**
* 返回對象實例
*/
public static Singleton getInstance() {
return instance;
}
public void print() {
System.out.println("Hello Singleton...");
}
}
1.2、懶漢式
——當第一次去使用Singleton對象的時候才會為其產生實例化對象的操作
class Singleton {
/**
* 聲明變量
*/
private static volatile Singleton singleton = null;
/**
* 私有構造方法
*/
private Singleton() {
}
/**
* 提供對外方法
* @return
*/
public static Singleton getInstance() {
// 還未實例化
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
public void print() {
System.out.println("Hello World");
}
}
當多個線程並發執行 getInstance 方法時，懶漢式會存在線程安全問題，所以用到了 synchronized 來實現線程的同步，當一個線程獲得鎖的時候其他線程就只能在外等待其執行完畢。而餓漢式則不存在線程安全的問題。
2、工廠設計模式
工廠模式分為工廠方法模式和抽象工廠模式。
工廠方法模式
工廠方法模式：
1. 工廠方法模式分為三種：普通工廠模式，就是建立一個工廠類，對實現了同一接口的一些類進行實例的創建。
2. 多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字符串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。
3. 靜態工廠方法模式，將上面的多個工廠方法模式里的方法置為靜態的，不需要創建實例，直接調用即可。
2.1、普通工廠模式
建立一個工廠類，對實現了同一接口的一些類進行實例的創建。
interface Sender {
void Send();
}
class MailSender implements Sender {
@Override
public void Send() {
System.out.println("This is mail sender...");
}
}
class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("This is sms sender...");
}
}
public class FactoryPattern {
public static void main(String[] args) {
Sender sender = produce("mail");
sender.Send();
}
public static Sender produce(String str) {
if ("mail".equals(str)) {
return new MailSender();
} else if ("sms".equals(str)) {
return new SmsSender();
} else {
System.out.println("輸入錯誤...");
return null;
}
}
}
2.2、 多個工廠方法模式
該模式是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字符串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。
interface Sender {
void Send();
}
class MailSender implements Sender {
@Override
public void Send() {
System.out.println("This is mail sender...");
}
}
class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("This is sms sender...");
}
}
class SendFactory {
public Sender produceMail() {
return new MailSender();
}
public Sender produceSms() {
return new SmsSender();
}
}
public class FactoryPattern {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produceMail();
sender.Send();
}
}
2.3、 靜態工廠方法模式
將上面的多個工廠方法模式里的方法置為靜態的，不需要創建實例，直接調用即可。
interface Sender {
void Send();
}
class MailSender implements Sender {
@Override
public void Send() {
System.out.println("This is mail sender...");
}
}
class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("This is sms sender...");
}
}
class SendFactory {
public static Sender produceMail() {
return new MailSender();
}
public static Sender produceSms() {
return new SmsSender();
}
}
public class FactoryPattern {
public static void main(String[] args) {
Sender sender = SendFactory.produceMail();
sender.Send();
}
}
2.4、抽象工廠模式
工廠方法模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要擴展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？
那么這就用到了抽象工廠模式，創建多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。
interface Provider {
Sender produce();
}
interface Sender {
void Send();
}
class MailSender implements Sender {
public void Send() {
System.out.println("This is mail sender...");
}
}
class SmsSender implements Sender {
public void Send() {
System.out.println("This is sms sender...");
}
}
class SendMailFactory implements Provider {
public Sender produce() {
return new MailSender();
}
}
class SendSmsFactory implements Provider {
public Sender produce() {
return new SmsSender();
}
}
public class FactoryPattern {
public static void main(String[] args) {
Provider provider = new SendMailFactory();
Sender sender = provider.produce();
sender.Send();
}
}
3、 建造者模式
工廠類模式提供的是創建單個類的模式，而建造者模式則是將各種產品集中起來管理，用來創建復合對象，所謂復合對象就是指某個類具有不同的屬性。
import java.util.ArrayList;
import java.util.List;
/**
* @Author: LiuWang
* @Created: 2018/8/6 17:47
*/
abstract class Builder {
/**
* 第一步：裝CPU
*/
public abstract void buildCPU();
/**
* 第二步：裝主板
*/
public abstract void buildMainBoard();
/**
* 第三步：裝硬盤
*/
public abstract void buildHD();
/**
* 獲得組裝好的電腦
* @return
*/
public abstract Computer getComputer();
}
/**
* 裝機人員裝機
*/
class Director {
public void Construct(Builder builder) {
builder.buildCPU();
builder.buildMainBoard();
builder.buildHD();
}
}
/**
* 具體的裝機人員
*/
class ConcreteBuilder extends Builder {
Computer computer = new Computer();
@Override
public void buildCPU() {
computer.Add("裝CPU");
}
@Override
public void buildMainBoard() {
computer.Add("裝主板");
}
@Override
public void buildHD() {
computer.Add("裝硬盤");
}
@Override
public Computer getComputer() {
return computer;
}
}
class Computer {
/**
* 電腦組件集合
*/
private List<String> parts = new ArrayList<String>();
public void Add(String part) {
parts.add(part);
}
public void print() {
for (int i = 0; i < parts.size(); i++) {
System.out.println("組件:" + parts.get(i) + "裝好了...");
}
System.out.println("電腦組裝完畢...");
}
}
public class BuilderPattern {
public static void main(String[] args) {
Director director = new Director();
Builder builder = new ConcreteBuilder();
director.Construct(builder);
Computer computer = builder.getComputer();
computer.print();
}
}
4、 適配器設計模式
適配器模式是將某個類的接口轉換成客戶端期望的另一個接口表示，目的是消除由於接口不匹配所造成的的類的兼容性問題。
主要分三類：類的適配器模式、對象的適配器模式、接口的適配器模式。
4.1、 類的適配器模式：
class Source {
public void method1() {
System.out.println("This is original method...");
}
}
interface Targetable {
/**
* 與原類中的方法相同
*/
public void method1();
/**
* 新類的方法
*/
public void method2();
}
class Adapter extends Source implements Targetable {
@Override
public void method2() {
System.out.println("This is the targetable method...");
}
}
public class AdapterPattern {
public static void main(String[] args) {
Targetable targetable = new Adapter();
targetable.method1();
targetable.method2();
}
}
4.2、 對象的適配器模式
基本思路和類的適配器模式相同，只是將Adapter 類作修改，這次不繼承Source 類，而是持有Source 類的實例，以達到解決兼容性的問題。
class Source {
public void method1() {
System.out.println("This is original method...");
}
}
interface Targetable {
/**
* 與原類中的方法相同
*/
public void method1();
/**
* 新類的方法
*/
public void method2();
}
class Wrapper implements Targetable {
private Source source;
public Wrapper(Source source) {
super();
this.source = source;
}
@Override
public void method1() {
source.method1();
}
@Override
public void method2() {
System.out.println("This is the targetable method...");
}
}
public class AdapterPattern {
public static void main(String[] args) {
Source source = new Source();
Targetable targetable = new Wrapper(source);
targetable.method1();
targetable.method2();
}
}
4.3、 接口的適配器模式
接口的適配器是這樣的：有時我們寫的一個接口中有多個抽象方法，當我們寫該接口的實現類時，必須實現該接口的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了接口的適配器模式，借助於一個抽象類，該抽象類實現了該接口，實現了所有的方法，而我們不和原始的接口打交道，只和該抽象類取得聯系，所以我們寫一個類，繼承該抽象類，重寫我們需要的方法就行。
/**
* 定義端口接口，提供通信服務
*/
interface Port {
/**
* 遠程SSH端口為22
*/
void SSH();
/**
* 網絡端口為80
*/
void NET();
/**
* Tomcat容器端口為8080
*/
void Tomcat();
/**
* MySQL數據庫端口為3306
*/
void MySQL();
}
/**
* 定義抽象類實現端口接口，但是什么事情都不做
*/
abstract class Wrapper implements Port {
@Override
public void SSH() {
}
@Override
public void NET() {
}
@Override
public void Tomcat() {
}
@Override
public void MySQL() {
}
}
/**
* 提供聊天服務
* 需要網絡功能
*/
class Chat extends Wrapper {
@Override
public void NET() {
System.out.println("Hello World...");
}
}
/**
* 網站服務器
* 需要Tomcat容器，Mysql數據庫，網絡服務，遠程服務
*/
class Server extends Wrapper {
@Override
public void SSH() {
System.out.println("Connect success...");
}
@Override
public void NET() {
System.out.println("WWW...");
}
@Override
public void Tomcat() {
System.out.println("Tomcat is running...");
}
@Override
public void MySQL() {
System.out.println("MySQL is running...");
}
}
public class AdapterPattern {
private static Port chatPort = new Chat();
private static Port serverPort = new Server();
public static void main(String[] args) {
// 聊天服務
chatPort.NET();
// 服務器
serverPort.SSH();
serverPort.NET();
serverPort.Tomcat();
serverPort.MySQL();
}
}
顧名思義，裝飾模式就是給一個對象增加一些新的功能，而且是動態的，要求裝飾對象和被裝飾對象實現同一個接口，裝飾對象持有被裝飾對象的實例。
interface Shape {
void draw();
}
/**
* 實現接口的實體類
*/
class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Shape: Rectangle...");
}
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Shape: Circle...");
}
}
/**
* 創建實現了 Shape 接口的抽象裝飾類。
*/
abstract class ShapeDecorator implements Shape {
protected Shape decoratedShape;
public ShapeDecorator(Shape decoratedShape) {
this.decoratedShape = decoratedShape;
}
@Override
public void draw() {
decoratedShape.draw();
}
}
/**
* 創建擴展自 ShapeDecorator 類的實體裝飾類。
*/
class RedShapeDecorator extends ShapeDecorator {
public RedShapeDecorator(Shape decoratedShape) {
super(decoratedShape);
}
@Override
public void draw() {
decoratedShape.draw();
setRedBorder(decoratedShape);
}
private void setRedBorder(Shape decoratedShape) {
System.out.println("Border Color: Red");
}
}
/**
* 使用 RedShapeDecorator 來裝飾 Shape 對象。
*/
public class DecoratorPattern {
public static void main(String[] args) {
Shape circle = new Circle();
Shape redCircle = new RedShapeDecorator(new Circle());
Shape redRectangle = new RedShapeDecorator(new Rectangle());
System.out.println("Circle with normal border");
circle.draw();
System.out.println("\nCircle of red border");
redCircle.draw();
System.out.println("\nRectangle of red border");
redRectangle.draw();
}
}
6、 策略模式
策略模式定義了一系列算法，並將每個算法封裝起來，使他們可以相互替換，且算法的變化不會影響到使用算法的客戶。需要設計一個接口，為一系列實現類提供統一的方法，多個實現類實現該接口，設計一個抽象類（可有可無，屬於輔助類），提供輔助函數。策略模式的決定權在用戶，系統本身提供不同算法的實現，新增或者刪除算法，對各種算法做封裝。因此，策略模式多用在算法決策系統中，外部用戶只需要決定用哪個算法即可。
/**
* 抽象算法的策略類，定義所有支持的算法的公共接口
*/
abstract class Strategy {
/**
* 算法方法
*/
public abstract void AlgorithmInterface();
}
/**
* 具體算法A
*/
class ConcreteStrategyA extends Strategy {
//算法A實現方法
@Override
public void AlgorithmInterface() {
System.out.println("算法A的實現");
}
}
/**
* 具體算法B
*/
class ConcreteStrategyB extends Strategy {
/**
* 算法B實現方法
*/
@Override
public void AlgorithmInterface() {
System.out.println("算法B的實現");
}
}
/**
* 具體算法C
*/
class ConcreteStrategyC extends Strategy {
@Override
public void AlgorithmInterface() {
System.out.println("算法C的實現");
}
}
/**
* 上下文，維護一個對策略類對象的引用
*/
class Context {
Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
public void contextInterface(){
strategy.AlgorithmInterface();
}
}
/**
* 客戶端代碼：實現不同的策略
*/
public class StrategyPattern {
public static void main(String[] args) {
Context context;
context = new Context(new ConcreteStrategyA());
context.contextInterface();
context = new Context(new ConcreteStrategyB());
context.contextInterface();
context = new Context(new ConcreteStrategyC());
context.contextInterface();
}
}
7、 代理模式
代理模式指給一個對象提供一個代理對象，並由代理對象控制對原對象的引用。代理可以分為靜態代理和動態代理。通過代理模式，可以利用代理對象為被代理對象添加額外的功能，以此來拓展被代理對象的功能。可以用於計算某個方法執行時間，在某個方法執行前后記錄日志等操作。
7.1、 靜態代理
靜態代理需要我們寫出代理類和被代理類，而且一個代理類和一個被代理類一一對應。代理類和被代理類需要實現同一個接口，通過聚合使得代理對象中有被代理對象的引用，以此實現代理對象控制被代理對象的目的。
/**
* 代理類和被代理類共同實現的接口
*/
interface IService {
void service();
}
/**
* 被代理類
*/
class Service implements IService{
@Override
public void service() {
System.out.println("被代理對象執行相關操作");
}
}
/**
* 代理類
*/
class ProxyService implements IService{
/**
* 持有被代理對象的引用
*/
private IService service;
/**
* 默認代理Service類
*/
public ProxyService() {
this.service = new Service();
}
/**
* 也可以代理實現相同接口的其他類
* @param service
*/
public ProxyService(IService service) {
this.service = service;
}
@Override
public void service() {
System.out.println("開始執行service()方法");
service.service();
System.out.println("service()方法執行完畢");
}
}
//測試類
public class ProxyPattern {
public static void main(String[] args) {
IService service = new Service();
//傳入被代理類的對象
ProxyService proxyService = new ProxyService(service);
proxyService.service();
}
}
7.2、 動態代理
JDK 1.3 之后，Java通過java.lang.reflect包中的三個類Proxy、InvocationHandler、Method來支持動態代理。動態代理常用於有若干個被代理的對象，且為每個被代理對象添加的功能是相同的（例如在每個方法運行前后記錄日志）。動態代理的代理類不需要我們編寫，由Java自動產生代理類源代碼並進行編譯最后生成代理對象。
創建動態代理對象的步驟：
1）指明一系列的接口來創建一個代理對象
2）創建一個調用處理器（InvocationHandler）對象
3）將這個代理指定為某個其他對象的代理對象
4） 在調用處理器的invoke（）方法中采取代理，一方面將調用傳遞給真實對象，另一方面執行各種需要的操作
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
/**
* 代理類和被代理類共同實現的接口
*/
interface IService {
void service();
}
class Service implements IService{
@Override
public void service() {
System.out.println("被代理對象執行相關操作");
}
}
class ServiceInvocationHandler implements InvocationHandler {
/**
* 被代理的對象
*/
private Object srcObject;
public ServiceInvocationHandler(Object srcObject) {
this.srcObject = srcObject;
}
@Override
public Object invoke(Object proxyObj, Method method, Object[] args) throws Throwable {
System.out.println("開始執行"+method.getName()+"方法");
//執行原對象的相關操作，容易忘記
Object returnObj = method.invoke(srcObject,args);
System.out.println(method.getName()+"方法執行完畢");
return returnObj;
}
}
public class ProxyPattern {
public static void main(String[] args) {
IService service = new Service();
Class<? extends IService> clazz = service.getClass();
IService proxyService = (IService) Proxy.newProxyInstance(clazz.getClassLoader(),
clazz.getInterfaces(), new ServiceInvocationHandler(service));
proxyService.service();
}
}
8、模板方法模式
定義：定義了一個算法的骨架，而將一些步驟延遲到子類中，模版方法使得子類可以在不改變算法結構的情況下，重新定義算法的步驟。
需求：簡單描述一下：本公司有程序猿、測試、HR、項目經理等人，下面使用模版方法模式，記錄下所有人員的上班情況
模板方法模式中的三類角色：
1、具體方法(Concrete Method)
2、抽象方法(Abstract Method)
3、鈎子方法(Hook Method)
// 具體方法 public final void workOneDay() { Log.e("workOneDay", "-----------------work start----------------"); enterCompany(); work(); exitCompany(); Log.e("workOneDay", "-----------------work end----------------"); } // 工作 抽象方法 public abstract void work(); // 鈎子方法 public boolean isNeedPrintDate() { return false; } private void exitCompany() { if (isNeedPrintDate()) { Log.e("exitCompany", "---" + new Date().toLocaleString() + "--->"); } Log.e("exitCompany", name + "---離開公司"); }
/** * 重寫父類的此方法,使可以查看離開公司時間 */ @Override public boolean isNeedPrintDate() { return true; }
最后測試：
查看所有人員的工作情況：
QAWorker qaWorker = new QAWorker("測試人員"); qaWorker(); HRWorker hrWorker = new HRWorker("莉莉姐"); hrWorker.workOneDay();
...
查看程序猿離開公司的時間:
ITWorker itWorker = new ITWorker("jingbin"); itWorker.workOneDay();
參考：
https://www.cnblogs.com/pony1223/p/7608955.html