設計模式

第一章、 簡單工廠模式

  1. 簡單工廠模式就是新建一個工廠類,用來創建需要的實體對象,所有被該工廠產生的實體對象都必須繼承於同一個接口,這樣做的好處是當新增一個類似功能時不需要對以前已經存在的穩定功能類做修改。如圖1.1,計算器UML類圖
    在這裏插入圖片描述
  2. 類圖常見示例如圖1.2,類圖示例
    在這裏插入圖片描述

第二章、 策略模式

  1. 策略模式,是使用一個策略處理類來處理所有繼承了策略抽象類的策略算法,策略處理類可以直接調用一系列策略中的方法,對外界而言,你只要給策略處理類策略算法的類別,和相關的參數,你就能得到結果,這樣做的好處就是對外隱藏更多策略算法相關的東西,只暴露策略處理類,同時使用繼承抽象類可以將一些算法通用的東西複用,另外這樣單個算法可以更加方便的測試,同時不同算法間沒有直接關係。如圖2.1,策略UML類圖。
    在這裏插入圖片描述
    第三章、 裝飾模式
  2. 裝飾模式和責任鏈模式有些相似,具體比較等學習了責任鏈再詳細處理,裝飾模式需要一個抽象的裝飾類,一個具體的實現類,還有一個可以設置裝飾類實體的實現類,其他具體的裝飾類都是繼承自改具有set的裝飾類。如圖3.1,裝飾UML類圖。
    在這裏插入圖片描述
    2.在寫一個項目時候要考慮依賴倒轉原則(使用抽象類,子類可以替換父類)、開放封閉原則(將變化開放)、單一原則(就一個類而言就一個引起變化的原因)。

    第四章、 代理模式
  3. 代理模式是A類和B類同時繼承於同一個抽象類,B類中保存一個引用,使得可以往B類中放A的實體,且B中通常有A的所有方法,當需要使用A時,可以直接使用B來代替,且我們可以在B中添加前後處理代碼,比如常用的執行時間代碼。如圖4.1,代理UML類圖。
    在這裏插入圖片描述

    第五章、 工廠方法模式
  4. 工廠方法模式相對簡單工廠模式,同樣是繼承一個抽象類,但是每一個需要創建的類都有自己單獨的工廠類,我們同樣還有工廠方法類,只是這裏不在具體的去創建實體了,改由工廠生成,我們在工廠方法類中只需要調用就行,這個相對簡單工廠模式,對開放閉合做了更生的實現。如圖5.1,工廠方法UML類圖。
    在這裏插入圖片描述
    第六章、 模板方法模式
  5. 我們經常使用數據庫操作方式,大多使用了模板方法模式,這樣的好處是避免了重複的勞動,模板方法模式通常是把重複的動作搬到父類中去,子類只重寫變化的部分。如圖6.1,模板方法UML類圖。
    在這裏插入圖片描述
    第七章、 外觀模式
  6. 外觀模式是爲了封裝一系列複雜操作,提供一個簡單的對外接口,我們只需要關心對外接口的調用,其內部複雜的操作我們並不關心,都在外觀接口中進行操作。如圖7.1 外觀模式UML類圖。
    在這裏插入圖片描述

第八章、 建造者模式

  1. 當我們進行某一個流程比較複雜的程序時,經常害怕自己會忘記其中某些步驟,這個時候我們可以使用建造者模式,通過定義一個建築抽象類來規定整個流程,其他流程都繼承該抽象類,這樣就再也不會存在流程過程缺失了。如圖8.1,建造者模式UML類圖。
    在這裏插入圖片描述

第九章、 觀察者模式

  1. 觀察者模式是一種聯動效果,當一個事情發生時,觀察者捕捉到,然後會通知其下注冊的所有被觀察對象,執行相應操作,好一點的觀察者模式可以將觀察者做出抽象類,具體的觀察者可以實現抽象類,不至於所有雞蛋放到一個籃子裏。如圖9.1,觀察者UML類圖。
    在這裏插入圖片描述

第十章、 抽象工廠模式

  1. 抽象工廠的出現是爲了方便管理同一品牌有不同產品,我們爲每個平臺創建一個抽象工廠,這樣一個工廠就可以管理一批產品。如圖10.1,抽象工廠UML類圖。
    在這裏插入圖片描述
    第十一章、 狀態模式
  2. 狀態模式有點類似責任鏈模式,只不過每種狀態只會有一個正確的類做出響應,這麼做的好處就是當狀態特別多時,且每個狀態的處理都比較複雜,且狀態可能發生變化,這個時候狀態模式就是比較合適的。如圖11.1,狀態模式UML類圖。
    在這裏插入圖片描述

    第十二章、 適配器模式
  3. 適配器模式就像手機充電適配器一樣,一般情況下是不可以使用該模式的,只有當新舊接口存在一定的不適應情況下才會使用,該模式就是使用代碼進行硬解碼,將原本不一樣的字段通過做對應關係變成可以適配的代碼。如圖12.1,適配器模式UML類圖。
    在這裏插入圖片描述

    第十三章、 備忘錄模式
  4. 當一局遊戲打到關鍵關卡時我們一般會選擇保存一個備份,備忘錄模式類似,我們希望能夠只有當前對象能管理備忘錄,且很少受別人影響,將備忘錄封裝起來。如圖13.1,備忘錄模式。
    在這裏插入圖片描述

    第十四章、 組合模式
  5. 組合模式,像樹形結構的數據最合適使用組合模式。如圖14.1,組合模式。
    在這裏插入圖片描述
    第十五章、 迭代器模式
  6. 迭代器可能是我們使用比較多的一種模式,像foreach,java直接作爲一種語法了。如圖15.1,迭代器模式。
    在這裏插入圖片描述第十六章、 橋接模式
    1.橋接模式主要是針對多個可變操作對主體流程產生影響,例如計薪系統中,會有加班和正常工作產生薪水,但是加班可能會公司政策有所調整,薪水也是隨着公司政策有所調整,我們不想計薪系統隨着節氣改變就把主程序改動。橋接模式就可以應對這種情況
    ActionAbstract 文件
abstract class ActionAbstract {
    abstract void operate();
}

NormalPayroll文件

class NormalPayroll extends ActionAbstract{
    void operate() {
        System.out.println("正常計薪");
    }
}

OvertimeContinues文件

class OvertimeContinues extends ActionAbstract{
    void operate() {
        System.out.println("加班得薪");
    }
}

PayrollSystem文件

class PayrollSystem {
    private ActionAbstract actionAbstract;

    void setActionAbstract(ActionAbstract actionAbstract) {
        this.actionAbstract = actionAbstract;
    }
    void operate() {
        actionAbstract.operate();
    }
}

PayrollMain文件

public class PayrollMain {

    public static void main(String[] args) {
        PayrollSystem payrollSystem = new PayrollSystem();
        payrollSystem.setActionAbstract(new NormalPayroll());
        payrollSystem.operate();
        payrollSystem.setActionAbstract(new OvertimeContinues());
        payrollSystem.operate();
    }
}

第十七章、 命令模式
1.命令模式由命令、執行者、司令組成,什麼時候使用命令模式呢??當一個功能需要結果,不關心下面怎麼操作,而且還要有超時之類的情況下可以撤回部分命令的功能時,可以使用命令模式。開發中可能我們不知不覺中就使用了命令模式,比如一個功能比較複雜時,我們分好幾個類,每個類各幹各的事,然後再把這幾個類合併起來完成特定功能,這個就可以算是命令模式。
AbstractCommand文件

public abstract class AbstractCommand {
    abstract void operate();
}

AbstractReceiver文件

public abstract class AbstractReceiver {
    abstract void action();
}

MyCommand文件

public class MyCommand extends AbstractCommand{
    private AbstractReceiver receiver;

    public MyCommand(AbstractReceiver receiver) {
        this.receiver = receiver;
    }

    void operate() {
        receiver.action();
    }
}

Receiver文件

public class Receiver extends AbstractReceiver {
    void action(){
        System.out.println("處理命令");
    }
}

Invoker文件

public class Invoker {
    private AbstractCommand command;

    public Invoker(AbstractCommand command) {
        this.command = command;
    }

    public void action(){
        command.operate();
    }
}

CommandMain文件

public class CommandMain {
    public static void main(String[] args) {
        AbstractReceiver receiver = new Receiver();
        AbstractCommand command = new MyCommand(receiver);
        Invoker invoker = new Invoker(command);
        invoker.action();
    }
}

第十八章、 責任鏈模式
1.責任鏈的最直接例子就是攔截器,當我們有一系列條件需要判斷時,責任鏈就是最好的模式
AbstractChainOfResponsibility文件

public abstract class AbstractChainOfResponsibility {
    abstract void doPost();
}

ParameterInterception文件

public class ParameterInterception extends AbstractChainOfResponsibility{
    private PermissionInterception permissionInterception = new PermissionInterception();
    void doPost() {
        System.out.println("參數攔截");
        permissionInterception.doPost();
    }
}

PermissionInterception文件

public class PermissionInterception extends AbstractChainOfResponsibility{
    void doPost() {
        System.out.println("權限攔截");
    }
}

ChainOfResponsibilityMain文件

public class ChainOfResponsibilityMain {

    public static void main(String[] args) {
        AbstractChainOfResponsibility abstractChainOfResponsibility = new ParameterInterception();
        abstractChainOfResponsibility.doPost();
    }
}

第十九章、 中介模式
1.中介模式是最好理解的一種模式,生活中找房子,我們首先會想到中介,這個模式和這個類似,買賣雙方不需要自己見面,使用中介進行中間調和,這樣就降低了買賣雙方的耦合度,所以的變化到中介這就結束了。這個模式理解下就好。
第二十章、 享元模式
1.享元模式和單例模式有點相似,作用都是減少類的創建,享元模式將大類分成小類,將具有共有特徵的給抽象出來,只創建一次對象放到一個map中,下次使用直接獲取,太簡單,不再介紹。
第二十一章、 解釋模式
1.解釋模式和適配器模式有點相似,解釋模式更像是翻譯,我們告訴機器給我們做什麼,機器聽不懂,需要使用用解釋模式將文本翻譯成機器可以聽懂的二進制,缺點是每新增一種語義都得新增翻譯解釋,推薦使用語法樹分析。
第二十二章、 訪問者模式
1.這個是所以模式中最讓人搞不懂的模式,但是可以用在ui、過濾器等場所。首先是元素接口,需要定義accept方法,所有需要被外訪問的對象需要實現這個接口,其次需要有觀察者接口,這個接口主要定義可以操作被訪問對象的方法,所有操作被訪問對象的類都需要實現該接口,另外還有一個真正的操作對象,使用觀察者操作元素。

abstract class Element
{
    public abstract void accept(IVisitor visitor);
    public abstract void doSomething();
}
class ConcreteElement1 extends Element{
    public void doSomething(){
        System.out.println("這是元素1");
    }
    public void accept(IVisitor visitor){
        visitor.visit(this);
    }
}
class ConcreteElement2 extends Element{
    public void doSomething(){
        System.out.println("這是元素2");
    }
    public void accept(IVisitor visitor){
        visitor.visit(this);
    }
}
class ConcreteElement3 extends Element{
    public void doSomething(){
        System.out.println("這是元素3");
    }
    public void accept(IVisitor visitor){
        visitor.visit(this);
    }
}
interface IVisitor{
    public void visit(ConcreteElement1 el1);
    public void visit(ConcreteElement2 el2);
    public void visit(ConcreteElement3 el3);
}
class Visitor implements IVisitor{
    public void visit(ConcreteElement1 el1){
        el1.doSomething();
    }
    public void visit(ConcreteElement2 el2){
        el2.doSomething();
    }
    public void visit(ConcreteElement3 el3){
        el3.doSomething();
    }
}
class ObjectStructure{
    private static List<Element> elements = new ArrayList<>();
    static List<Element> getElements(){
        elements.add(new ConcreteElement1());
        elements.add(new ConcreteElement2());
        elements.add(new ConcreteElement3());
        return elements;
    }
}
public class Client{
    public static void main (String[]args){
        Element e = new ConcreteElement3();
        e.accept(new Visitor());
        ObjectStructure.getElements().forEach(a->a.accept(new Visitor()));
    }
}
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章