常用的設計模式

設計模式：常用的設計模式

設計模式看似把代碼改造了很多，其實，只不過是把代碼挪動了一下位置，增加了一些小小的變量，刪減了一些小小的變量。

歷史

設計模式一開始是由一個搞建筑的人提出的。

GoF，Gang of Four，四人組。指的是一本書，四個人寫的，因為名字太長了，就叫做這個。原書名好像是叫做：《設計模式：面向對象軟件設計的基礎》

這本書中提出的設計模式一共有23種。

設計原則

設計原則按照字母手寫簡寫可以概括為`SOLID`原則。

單一職責原則（Single Responsibility Principle）

開放封閉原則（Open Close Principle）

里氏替換原則（Liskov Substitution Principle）

迪米特法則（Least Knowledge Principle）

接口分離原則（Interface Segregation Principle）

依賴倒置原則（Dependency Inversion Principle）

單一職責

一個模塊負責一個功能。

比如 controller 層有多個 controller，service 層有多個 service，每個模塊負責的功能都不一樣。

如果都混在一起，那么：

尋找代碼很困難
修改代碼很麻煩

開閉原則

對修改關閉，對擴展開放。

如果要擴展功能，盡量不要修改原有代碼，而是實現接口或者繼承父類。

里氏替換原則

S 是 F 的子類，如果 S 的編譯類型是 F，那么 S 的行為盡量和 F 保持一致。

意思就是子類盡量不要覆蓋父類的方法。

override：推翻、覆蓋。

之所以被翻譯成“重寫”，我認為是 override 看起來或者聽起來有點像 overwrite，而它確實有“覆蓋，重寫”的意思，但并不是關鍵字，而且“重寫”聽起來不如“覆蓋”那么那么容易理解。

迪米特法則

也叫最少知道原則。

一個類盡量與自已有直接依賴關系的類或接口產生聯系。

比如 controller 中只與 service 層產生直接聯系，沒有 dao 層的依賴；

明星與經紀人是直接聯系，經紀人和粉絲直接聯系。

接口隔離原則

不要試圖創建一個很龐大的接口，而應該針對特定的功能去設計接口。

比如 person 接口有 eat，study，work，sleep 四個方法，那么 Teacher 類和 Student 類實現這個接口的時候，都必須實現這四個方法，但是 Teacher 無需實現 study 方法，Student 類也無需實現 work 方法，這就造成代碼冗余了。

更好的方法應該是，創建三個接口：Person，Teacher，Student，Person 只有 eat，sleep 方法，Student 接口只有 study 方法，Teacher 類只有 work 方法。

那么，老師類實現 Person、Teacher 這兩個接口，學生類實現 Person、Student 這兩個接口。

依賴倒置原則

高層模塊盡量依賴抽象，而不是具體的實現類。

比如 controller 類應該依賴的是 Service 接口，而不是 Service 實現類。

有什么好處呢？

如果要替換 Service 實現類，那么就只需要替換實現類，而Service，controller 是不用變的。

創建型

單例模式

餓漢式

1. 構造器私有化 2. 創建靜態對象 3. 提供外部統一訪問方法

package singleton.case1;

/**
 * 單例模式：餓漢式
 */
public class Singleton1 {
    /**
     * 必須是靜態的，如果不是靜態的，那么 getInstance 方法就無法使用這個變量名
     * 靜態方法只能使用靜態成員。
     * 因為非靜態成員是屬于對象的，但是調用非靜態成員必須創建對象。
     */
    private static Singleton1 instance = new Singleton1();

    private Singleton1() {

    }

    public static Singleton1 getInstance() {
        return instance;
    }
}

為什么 getInstance 方法是靜態的？

因為如果是非靜態的，那么必須創建對象，來調用這個方法，但是構造器是不能被外部調用的。

為什么 instance 是靜態的？

如果不是靜態的，那么 getInstance 方法就無法使用這個變量名。

為什么靜態方法只能使用靜態成員？

靜態方法不屬于對象，屬于類，因此調用靜態方法的時候，是類在調用。方法體中，返回一個對象，返回的是方法調用者的對象，也就是類對象，所以 instance 是靜態的。

如果是非靜態方法，那么就是對象在調用，方法體中，返回的對象，是屬于對象的。對象的成員可以是靜態的，也可以是非靜態的。

非靜態方法返回的對象，默認是屬于 this 的，this 表示當前方法的調用者（實例對象）。這也就是為什么靜態方法不能出現 this 的原因。

總結：

方法體中出現 this，this 表示當前方法的調用者，調用者是實例對象；

靜態方法的調用者是類本身，因此靜態方法中不可能出現 this。也不可能出現非靜態成員，因為非靜態成員是和實例對象相關聯的。

工廠模式

一個方法，一個參數，就能創建指定的產品

看到XXXFactory形式的類，就要想到這是一個工廠類，它使用了工廠模式，例如 Spring 的BeanFactory、Mybatis 的 SqlSessionFactory。

簡單工廠模式

工廠直接創建產品

package com.cskaoyan.fatory.simple;


import com.cskaoyan.fatory.bean.Animal;
import com.cskaoyan.fatory.bean.Pig;
import com.cskaoyan.fatory.bean.Rabbit;

/**
 * 簡單工廠
 */
public class SimpleAnimalFactory {


    /**
     * 提供一個方法，根據不同的參數，獲取不同的對象實例
     * @param animalName
     * @return
     */
    public static Animal getAnimal(String animalName) {
        if (animalName.equals("pig")) {
            return new Pig();
        }

        if (animalName.equals("rabbit")) {
            return new Rabbit();
        }

        return null;
    }
}

package com.cskaoyan.fatory.simple;

import com.cskaoyan.fatory.bean.Animal;

public class Case1 {

    public static void main(String[] args) {

        Animal pig = SimpleAnimalFactory.getAnimal("pig");
        Animal rabbit = SimpleAnimalFactory.getAnimal("rabbit");

        int m = 0;
    }
}

工廠方法模式

由子工廠來創建產品

package com.cskaoyan.fatory.method;

import com.cskaoyan.fatory.bean.Animal;


/**
 *
 * 工廠方法設計模式:
 *
 * 通過不同的工廠實現類，就可以獲取不同的對象實例
 *
 * 工廠方法中，只有一個方法，只能生產單個產品
 * 而抽象工廠中，有多個方法，可以生產的是一個產品矩陣
 */
public interface AnimalFactory {

    Animal getAnimal();
}

package com.cskaoyan.fatory.method;

import com.cskaoyan.fatory.bean.Animal;
import com.cskaoyan.fatory.bean.Pig;

public class PigAnimalFactory implements AnimalFactory{
    @Override
    public Animal getAnimal() {
        return new Pig();
    }
}

package com.cskaoyan.fatory.method;

import com.cskaoyan.fatory.bean.Animal;
import com.cskaoyan.fatory.bean.Rabbit;

public class RabbitAnimalFactory implements AnimalFactory{
    @Override
    public Animal getAnimal() {
        return new Rabbit();
    }
}

抽象工廠模式

一個工廠有多個方法，可以生產一系列產品

public abstract class AbstractFurnitureFactory {

    public abstract TV createTV();
    public abstract Freezer createFreezer();
}

public class MiFurnitureFactory extends AbstractFurnitureFactory{
    @Override
    public TV createTV() {
        return new MiTV();
    }

    @Override
    public Freezer createFreezer() {
        return new MiFreezer();
    }
}

public class HaierFurnitureFactory extends AbstractFurnitureFactory{
    @Override
    public TV createTV() {
        return new HaierTV();
    }

    @Override
    public Freezer createFreezer() {
        return new HaierFreezer();
    }
}

public class OrderFurniture {
    public static void main(String[] args) {
        MiFurnitureFactory miFactory = new MiFurnitureFactory();
        TV tv = miFactory.createTV();
        Freezer freezer = miFactory.createFreezer();
        System.out.println("tv instanceof MiTV = " + (tv instanceof MiTV));
        System.out.println("freezer instanceof MiFreezer = " + (freezer instanceof MiFreezer));
    }
}

建造者模式

形式：`XXXBuilder`

使用場景：創建復雜對象。一步一步形成一個完整的對象，每一步又可能涉及到其他對象。

現有的例子：StringBuilder、Minio、ES、@Builder 注解……

StringBuilder

package com.cskaoyan.builder.case1;

public class Case1 {

    public static void main(String[] args) {

        /**
         * 建造者模式的代碼
         */  
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.append("hello")
        .append(" ")
        .append("cskaoyan")
        .append(" ")
        .append("2025")
        .append("!");

        String content = stringBuilder.toString();
        System.out.println(content);
    }
}

// 對比set：這種方式更加連續，更加緊湊，set 面對復雜對象容易出錯。

@Builder注解

// 這個注解，其實就是在編譯階段，幫助我們生成這個對象的builder類
// 但是，需要注意的是，一旦某個類被添加了@Builder注解，那么就意味著這個類沒有無參構造方法了
// 沒有無參構造方法，
    // <1> 那么就意味著不能直接new對象了
    // <2> 那么也意味著，在和很多的框架整合的時候，可能會出現問題
                // mybatis
                // FastJSON
                // RedissonClient
        // 為什么這些框架會有問題呢？
        // 比如使用RedissonClient存一個teacher對象到Redis中，那么此時Redis中存儲的是Teacher對象的JSON字符串
        // 但是在取這個對象的時候，首先RedissonClient會從Redis中查詢到這個JSON字符串
        // 然后需要把這個JSON字符串轉化為Teacher對象
                    // 使用無參構造方法創建一個teacher對象
                    // 設值
        // 因為現在增加了@Builder注解之后，沒有無參構造方法，所以此時就會報錯

// 記結論
    // 使用@builder注解的時候，需要配合 @NoArgsConstructor注解 和 @AllArgsConstructor注解一起使用

結構型

代理模式

行為型

責任鏈模式

上下文對象可以注冊到容器中嗎？

不可以，因為上下文對象中有值，每個訂單不同的訂單id。

哪些對象可以復用？

對象里面的數據可以復用，這個對象就能注冊到容器中。

posted @ 2025-01-31 18:20 yx1024 閱讀(70) 評論(0) 收藏舉報

刷新頁面返回頂部

yx-study

持續學習