Java如何創(chuàng)建型模式

這篇文章主要為大家展示了“Java如何創(chuàng)建型模式”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Java如何創(chuàng)建型模式”這篇文章吧。

創(chuàng)建型模式

創(chuàng)建型模式的作用就是創(chuàng)建對(duì)象，說到創(chuàng)建一個(gè)對(duì)象，最熟悉的就是 new 一個(gè)對(duì)象，然后 set 相關(guān)屬性。但是，在很多場景下，我們需要給客戶端提供更加友好的創(chuàng)建對(duì)象的方式，尤其是那種我們定義了類，但是需要提供給其他開發(fā)者用的時(shí)候。

簡單工廠模式

和名字一樣簡單，非常簡單，直接上代碼吧：

public class FoodFactory {
    public static Food makeFood(String name) {
        if (name.equals("noodle")) {
            Food noodle = new LanZhouNoodle();
            noodle.addSpicy("more");
            return noodle;
        } else if (name.equals("chicken")) {
            Food chicken = new HuangMenChicken();
            chicken.addCondiment("potato");
            return chicken;
        } else {
            return null;
        }
    }
}

其中，LanZhouNoodle 和 HuangMenChicken 都繼承自 Food。

簡單地說，簡單工廠模式通常就是這樣，一個(gè)工廠類 XxxFactory，里面有一個(gè)靜態(tài)方法，根據(jù)我們不同的參數(shù)，返回不同的派生自同一個(gè)父類（或?qū)崿F(xiàn)同一接口）的實(shí)例對(duì)象。

我們強(qiáng)調(diào)職責(zé)單一原則，一個(gè)類只提供一種功能，F(xiàn)oodFactory 的功能就是只要負(fù)責(zé)生產(chǎn)各種 Food。

工廠模式

簡單工廠模式很簡單，如果它能滿足我們的需要，我覺得就不要折騰了。之所以需要引入工廠模式，是因?yàn)槲覀兺枰褂脙蓚€(gè)或兩個(gè)以上的工廠。

public interface FoodFactory {
    Food makeFood(String name);
}
public class ChineseFoodFactory implements FoodFactory {
    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new ChineseFoodA();
        } else if (name.equals("B")) {
            return new ChineseFoodB();
        } else {
            return null;
        }
    }
}
public class AmericanFoodFactory implements FoodFactory {
    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new AmericanFoodA();
        } else if (name.equals("B")) {
            return new AmericanFoodB();
        } else {
            return null;
        }
    }
}

其中，ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。

客戶端調(diào)用：

public class APP {
    public static void main(String[] args) {
        // 先選擇一個(gè)具體的工廠
        FoodFactory factory = new ChineseFoodFactory();
        // 由第一步的工廠產(chǎn)生具體的對(duì)象，不同的工廠造出不一樣的對(duì)象
        Food food = factory.makeFood("A");
    }
}

雖然都是調(diào)用 makeFood(“A”) 制作 A 類食物，但是，不同的工廠生產(chǎn)出來的完全不一樣。

第一步，我們需要選取合適的工廠，然后第二步基本上和簡單工廠一樣。

核心在于，我們需要在第一步選好我們需要的工廠。比如，我們有 LogFactory 接口，實(shí)現(xiàn)類有 FileLogFactory 和 KafkaLogFactory，分別對(duì)應(yīng)將日志寫入文件和寫入 Kafka 中，顯然，我們客戶端第一步就需要決定到底要實(shí)例化 FileLogFactory 還是 KafkaLogFactory，這將決定之后的所有的操作。

雖然簡單，不過我也把所有的構(gòu)件都畫到一張圖上，這樣讀者看著比較清晰：

轉(zhuǎn)存失敗重新上傳取消

抽象工廠模式

當(dāng)涉及到產(chǎn)品族的時(shí)候，就需要引入抽象工廠模式了。

一個(gè)經(jīng)典的例子是造一臺(tái)電腦。我們先不引入抽象工廠模式，看看怎么實(shí)現(xiàn)。

因?yàn)殡娔X是由許多的構(gòu)件組成的，我們將 CPU 和主板進(jìn)行抽象，然后 CPU 由 CPUFactory 生產(chǎn)，主板由 MainBoardFactory 生產(chǎn)，然后，我們再將 CPU 和主板搭配起來組合在一起，如下圖：

轉(zhuǎn)存失敗重新上傳取消

這個(gè)時(shí)候的客戶端調(diào)用是這樣的：

// 得到 Intel 的 CPU
CPUFactory cpuFactory = new IntelCPUFactory();
CPU cpu = intelCPUFactory.makeCPU();
// 得到 AMD 的主板
MainBoardFactory mainBoardFactory = new AmdMainBoardFactory();
MainBoard mainBoard = mainBoardFactory.make();
// 組裝 CPU 和主板
Computer computer = new Computer(cpu, mainBoard);

單獨(dú)看 CPU 工廠和主板工廠，它們分別是前面我們說的工廠模式。這種方式也容易擴(kuò)展，因?yàn)橐o電腦加硬盤的話，只需要加一個(gè) HardDiskFactory 和相應(yīng)的實(shí)現(xiàn)即可，不需要修改現(xiàn)有的工廠。

但是，這種方式有一個(gè)問題，那就是如果 Intel 家產(chǎn)的 CPU 和 AMD 產(chǎn)的主板不能兼容使用，那么這代碼就容易出錯(cuò)，因?yàn)榭蛻舳瞬⒉恢浪鼈儾患嫒?，也就?huì)錯(cuò)誤地出現(xiàn)隨意組合。

下面就是我們要說的產(chǎn)品族的概念，它代表了組成某個(gè)產(chǎn)品的一系列附件的集合：

當(dāng)涉及到這種產(chǎn)品族的問題的時(shí)候，就需要抽象工廠模式來支持了。我們不再定義 CPU 工廠、主板工廠、硬盤工廠、顯示屏工廠等等，我們直接定義電腦工廠，每個(gè)電腦工廠負(fù)責(zé)生產(chǎn)所有的設(shè)備，這樣能保證肯定不存在兼容問題。

這個(gè)時(shí)候，對(duì)于客戶端來說，不再需要單獨(dú)挑選 CPU廠商、主板廠商、硬盤廠商等，直接選擇一家品牌工廠，品牌工廠會(huì)負(fù)責(zé)生產(chǎn)所有的東西，而且能保證肯定是兼容可用的。

public static void main(String[] args) {
    // 第一步就要選定一個(gè)“大廠”
    ComputerFactory cf = new AmdFactory();
    // 從這個(gè)大廠造 CPU
    CPU cpu = cf.makeCPU();
    // 從這個(gè)大廠造主板
    MainBoard board = cf.makeMainBoard();
      // 從這個(gè)大廠造硬盤
      HardDisk hardDisk = cf.makeHardDisk();
    // 將同一個(gè)廠子出來的 CPU、主板、硬盤組裝在一起
    Computer result = new Computer(cpu, board, hardDisk);
}

當(dāng)然，抽象工廠的問題也是顯而易見的，比如我們要加個(gè)顯示器，就需要修改所有的工廠，給所有的工廠都加上制造顯示器的方法。這有點(diǎn)違反了對(duì)修改關(guān)閉，對(duì)擴(kuò)展開放這個(gè)設(shè)計(jì)原則。

單例模式

單例模式用得最多，錯(cuò)得最多。

餓漢模式最簡單：

public class Singleton {
    // 首先，將 new Singleton() 堵死
    private Singleton() {};
    // 創(chuàng)建私有靜態(tài)實(shí)例，意味著這個(gè)類第一次使用的時(shí)候就會(huì)進(jìn)行創(chuàng)建
    private static Singleton instance = new Singleton();
    public static Singleton getInstance() {
        return instance;
    }
    // 瞎寫一個(gè)靜態(tài)方法。這里想說的是，如果我們只是要調(diào)用 Singleton.getDate(...)，
    // 本來是不想要生成 Singleton 實(shí)例的，不過沒辦法，已經(jīng)生成了
    public static Date getDate(String mode) {return new Date();}
}

很多人都能說出餓漢模式的缺點(diǎn)，可是我覺得生產(chǎn)過程中，很少碰到這種情況：你定義了一個(gè)單例的類，不需要其實(shí)例，可是你卻把一個(gè)或幾個(gè)你會(huì)用到的靜態(tài)方法塞到這個(gè)類中。

飽漢模式最容易出錯(cuò)：

public class Singleton {
    // 首先，也是先堵死 new Singleton() 這條路
    private Singleton() {}
    // 和餓漢模式相比，這邊不需要先實(shí)例化出來，注意這里的 volatile，它是必須的
    private static volatile Singleton instance = null;
    public static Singleton getInstance() {
        if (instance == null) {
            // 加鎖
            synchronized (Singleton.class) {
                // 這一次判斷也是必須的，不然會(huì)有并發(fā)問題
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

雙重檢查，指的是兩次檢查 instance 是否為 null。

volatile 在這里是需要的，希望能引起讀者的關(guān)注。

很多人不知道怎么寫，直接就在 getInstance() 方法簽名上加上 synchronized，這就不多說了，性能太差。

嵌套類最經(jīng)典，以后大家就用它吧：

public class Singleton3 {
    private Singleton3() {}
    // 主要是使用了 嵌套類可以訪問外部類的靜態(tài)屬性和靜態(tài)方法 的特性
    private static class Holder {
        private static Singleton3 instance = new Singleton3();
    }
    public static Singleton3 getInstance() {
        return Holder.instance;
    }
}

注意，很多人都會(huì)把這個(gè)嵌套類說成是靜態(tài)內(nèi)部類，嚴(yán)格地說，內(nèi)部類和嵌套類是不一樣的，它們能訪問的外部類權(quán)限也是不一樣的。

最后，一定有人跳出來說用枚舉實(shí)現(xiàn)單例，是的沒錯(cuò)，枚舉類很特殊，它在類加載的時(shí)候會(huì)初始化里面的所有的實(shí)例，而且 JVM 保證了它們不會(huì)再被實(shí)例化，所以它天生就是單例的。不說了，讀者自己看著辦吧，不建議使用。

建造者模式

經(jīng)常碰見的 XxxBuilder 的類，通常都是建造者模式的產(chǎn)物。建造者模式其實(shí)有很多的變種，但是對(duì)于客戶端來說，我們的使用通常都是一個(gè)模式的：

Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();

套路就是先 new 一個(gè) Builder，然后可以鏈?zhǔn)降卣{(diào)用一堆方法，最后再調(diào)用一次 build() 方法，我們需要的對(duì)象就有了。

來一個(gè)中規(guī)中矩的建造者模式：

class User {
    // 下面是“一堆”的屬性
    private String name;
    private String password;
    private String nickName;
    private int age;
    // 構(gòu)造方法私有化，不然客戶端就會(huì)直接調(diào)用構(gòu)造方法了
    private User(String name, String password, String nickName, int age) {
        this.name = name;
        this.password = password;
        this.nickName = nickName;
        this.age = age;
    }
    // 靜態(tài)方法，用于生成一個(gè) Builder，這個(gè)不一定要有，不過寫這個(gè)方法是一個(gè)很好的習(xí)慣，
    // 有些代碼要求別人寫 new User.UserBuilder().a()...build() 看上去就沒那么好
    public static UserBuilder builder() {
        return new UserBuilder();
    }
    public static class UserBuilder {
        // 下面是和 User 一模一樣的一堆屬性
        private String  name;
        private String password;
        private String nickName;
        private int age;
        private UserBuilder() {
        }
        // 鏈?zhǔn)秸{(diào)用設(shè)置各個(gè)屬性值，返回 this，即 UserBuilder
        public UserBuilder name(String name) {
            this.name = name;
            return this;
        }
        public UserBuilder password(String password) {
            this.password = password;
            return this;
        }
        public UserBuilder nickName(String nickName) {
            this.nickName = nickName;
            return this;
        }
        public UserBuilder age(int age) {
            this.age = age;
            return this;
        }
        // build() 方法負(fù)責(zé)將 UserBuilder 中設(shè)置好的屬性“復(fù)制”到 User 中。
        // 當(dāng)然，可以在 “復(fù)制” 之前做點(diǎn)檢驗(yàn)
        public User build() {
            if (name == null || password == null) {
                throw new RuntimeException("用戶名和密碼必填");
            }
            if (age <= 0 || age >= 150) {
                throw new RuntimeException("年齡不合法");
            }
            // 還可以做賦予”默認(rèn)值“的功能
              if (nickName == null) {
                nickName = name;
            }
            return new User(name, password, nickName, age);
        }
    }
}

核心是：先把所有的屬性都設(shè)置給 Builder，然后 build() 方法的時(shí)候，將這些屬性復(fù)制給實(shí)際產(chǎn)生的對(duì)象。

看看客戶端的調(diào)用：

public class APP {
    public static void main(String[] args) {
        User d = User.builder()
                .name("foo")
                .password("pAss12345")
                .age(25)
                .build();
    }
}

說實(shí)話，建造者模式的鏈?zhǔn)?/strong>寫法很吸引人，但是，多寫了很多“無用”的 builder 的代碼，感覺這個(gè)模式?jīng)]什么用。不過，當(dāng)屬性很多，而且有些必填，有些選填的時(shí)候，這個(gè)模式會(huì)使代碼清晰很多。我們可以在 Builder 的構(gòu)造方法中強(qiáng)制讓調(diào)用者提供必填字段，還有，在 build() 方法中校驗(yàn)各個(gè)參數(shù)比在 User 的構(gòu)造方法中校驗(yàn)，代碼要優(yōu)雅一些。

題外話，強(qiáng)烈建議讀者使用 lombok，用了 lombok 以后，上面的一大堆代碼會(huì)變成如下這樣:

@Builder
class User {
    private String  name;
    private String password;
    private String nickName;
    private int age;
}

怎么樣，省下來的時(shí)間是不是又可以干點(diǎn)別的了。

當(dāng)然，如果你只是想要鏈?zhǔn)綄懛ǎ幌胍ㄔ煺吣Ｊ?，有個(gè)很簡單的辦法，User 的 getter 方法不變，所有的 setter 方法都讓其 return this 就可以了，然后就可以像下面這樣調(diào)用：

User user = new User().setName("").setPassword("").setAge(20);

原型模式

這是我要說的創(chuàng)建型模式的最后一個(gè)設(shè)計(jì)模式了。

原型模式很簡單：有一個(gè)原型實(shí)例，基于這個(gè)原型實(shí)例產(chǎn)生新的實(shí)例，也就是“克隆”了。

Object 類中有一個(gè) clone() 方法，它用于生成一個(gè)新的對(duì)象，當(dāng)然，如果我們要調(diào)用這個(gè)方法，java 要求我們的類必須先實(shí)現(xiàn) Cloneable 接口，此接口沒有定義任何方法，但是不這么做的話，在 clone() 的時(shí)候，會(huì)拋出 CloneNotSupportedException 異常。

protected native Object clone() throws CloneNotSupportedException;

java 的克隆是淺克隆，碰到對(duì)象引用的時(shí)候，克隆出來的對(duì)象和原對(duì)象中的引用將指向同一個(gè)對(duì)象。通常實(shí)現(xiàn)深克隆的方法是將對(duì)象進(jìn)行序列化，然后再進(jìn)行反序列化。

原型模式了解到這里我覺得就夠了，各種變著法子說這種代碼或那種代碼是原型模式，沒什么意義。

以上是“Java如何創(chuàng)建型模式”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！