Java設計模式中的建造者模式詳解
前言
建造者模式使我們?nèi)粘9ぷ髦斜容^常見的一種設計模式,和工廠模式一樣屬于創(chuàng)建型設計模式,用于解耦對象創(chuàng)建和對象使用的邏輯。
建造者設計模式和對象的構(gòu)造函數(shù)或者set方法比較類似,那既然用構(gòu)造函數(shù)或者set方法能創(chuàng)建對象,那我們?yōu)槭裁催€需要建造者設計模式勒?
建造者和是工廠模式都是建造型的設計模式,那這兩者的區(qū)別是什么勒?建造者的應用場景是什么勒?
為什么需要建造者模式
假設我們有如下的設計要求,我們需要定義一個資源池配置類 ResourcePoolConfig。
這里的資源池,你可以簡單理解為線程池、連接池、對象池等。
在這個資源池配置類中,有以下幾個成員變量,(name、maxTotal、maxIdle、minIdle)也就是可配置項。
現(xiàn)在,請你編寫代碼實現(xiàn)這個 ResourcePoolConfig 類。
如果有構(gòu)造函數(shù)的方式去創(chuàng)建這個類的話,代碼示例如下:
public class ResourcePoolConfig {
private static final int DEFAULT_MAX_TOTAL = 8;
private static final int DEFAULT_MAX_IDLE = 8;
private static final int DEFAULT_MIN_IDLE = 0;
private String name;
private int maxTotal = DEFAULT_MAX_TOTAL;
private int maxIdle = DEFAULT_MAX_IDLE;
private int minIdle = DEFAULT_MIN_IDLE;
public ResourcePoolConfig(String name, Integer maxTotal, Integer maxIdle, Integer minIdle) {
if (StringUtils.isBlank(name)) {
throw new IllegalArgumentException("name should not be empty.");
}
this.name = name;
if (maxTotal != null) {
if (maxTotal <= 0) {
throw new IllegalArgumentException("maxTotal should be positive.");
}
this.maxTotal = maxTotal;
}
if (maxIdle != null) {
if (maxIdle < 0) {
throw new IllegalArgumentException("maxIdle should not be negative.");
}
this.maxIdle = maxIdle;
}
if (minIdle != null) {
if (minIdle < 0) {
throw new IllegalArgumentException("minIdle should not be negative.");
}
this.minIdle = minIdle;
}
}
//...省略getter方法...
}現(xiàn)在,ResourcePoolConfig 只有 4 個可配置項,對應到構(gòu)造函數(shù)中,也只有 4 個參數(shù),參數(shù)的個數(shù)不多。
但是,如果可配置項逐漸增多,變成了 8 個、10 個,甚至更多,那繼續(xù)沿用現(xiàn)在的設計思路,構(gòu)造函數(shù)的參數(shù)列表會變得很長,代碼在可讀性和易用性上都會變差。
在使用構(gòu)造函數(shù)的時候,我們就容易搞錯各參數(shù)的順序,傳遞進錯誤的參數(shù)值,導致非常隱蔽的 bug。
用set方法的方式去創(chuàng)建這個類的話,代碼示例如下:
// ResourcePoolConfig使用舉例
ResourcePoolConfig config = new ResourcePoolConfig("dbconnectionpool");
config.setMaxTotal(16);
config.setMaxIdle(8);如果我們把問題的難度再加大點,比如,還需要解決下面這三個問題,那現(xiàn)在的設計思路就不能滿足了。
我們剛剛講到,name 是必填的,所以,我們把它放到構(gòu)造函數(shù)中,強制創(chuàng)建對象的時候就設置。如果必填的配置項有很多,把這些必填配置項都放到構(gòu)造函數(shù)中設置,那構(gòu)造函數(shù)就又會出現(xiàn)參數(shù)列表很長的問題。如果我們把必填項也通過 set() 方法設置,那校驗這些必填項是否已經(jīng)填寫的邏輯就無處安放了。
除此之外,假設配置項之間有一定的依賴關系,比如,如果用戶設置了 maxTotal、maxIdle、minIdle 其中一個,就必須顯式地設置另外兩個;或者配置項之間有一定的約束條件,比如,maxIdle 和 minIdle 要小于等于 maxTotal。如果我們繼續(xù)使用現(xiàn)在的設計思路,那這些配置項之間的依賴關系或者約束條件的校驗邏輯就無處安放了。
如果我們希望 ResourcePoolConfig 類對象是不可變對象,也就是說,對象在創(chuàng)建好之后,就不能再修改內(nèi)部的屬性值。要實現(xiàn)這個功能,我們就不能在 ResourcePoolConfig 類中暴露 set() 方法。
為了解決這些問題,建造者模式就派上用場了。
public class ResourcePoolConfig {
private String name;
private int maxTotal;
private int maxIdle;
private int minIdle;
private ResourcePoolConfig(Builder builder) {
this.name = builder.name;
this.maxTotal = builder.maxTotal;
this.maxIdle = builder.maxIdle;
this.minIdle = builder.minIdle;
}
//...省略getter方法...
//我們將Builder類設計成了ResourcePoolConfig的內(nèi)部類。
//我們也可以將Builder類設計成獨立的非內(nèi)部類ResourcePoolConfigBuilder。
public static class Builder {
private static final int DEFAULT_MAX_TOTAL = 8;
private static final int DEFAULT_MAX_IDLE = 8;
private static final int DEFAULT_MIN_IDLE = 0;
private String name;
private int maxTotal = DEFAULT_MAX_TOTAL;
private int maxIdle = DEFAULT_MAX_IDLE;
private int minIdle = DEFAULT_MIN_IDLE;
public ResourcePoolConfig build() {
// 校驗邏輯放到這里來做,包括必填項校驗、依賴關系校驗、約束條件校驗等
if (StringUtils.isBlank(name)) {
throw new IllegalArgumentException("...");
}
if (maxIdle > maxTotal) {
throw new IllegalArgumentException("...");
}
if (minIdle > maxTotal || minIdle > maxIdle) {
throw new IllegalArgumentException("...");
}
return new ResourcePoolConfig(this);
}
public Builder setName(String name) {
if (StringUtils.isBlank(name)) {
throw new IllegalArgumentException("...");
}
this.name = name;
return this;
}
public Builder setMaxTotal(int maxTotal) {
if (maxTotal <= 0) {
throw new IllegalArgumentException("...");
}
this.maxTotal = maxTotal;
return this;
}
public Builder setMaxIdle(int maxIdle) {
if (maxIdle < 0) {
throw new IllegalArgumentException("...");
}
this.maxIdle = maxIdle;
return this;
}
public Builder setMinIdle(int minIdle) {
if (minIdle < 0) {
throw new IllegalArgumentException("...");
}
this.minIdle = minIdle;
return this;
}
}
}
// 這段代碼會拋出IllegalArgumentException,因為minIdle>maxIdle
ResourcePoolConfig config = new ResourcePoolConfig.Builder()
.setName("dbconnectionpool")
.setMaxTotal(16)
.setMaxIdle(10)
.setMinIdle(12)
.build();實際上,如果我們并不是很關心對象是否有短暫的無效狀態(tài),也不是太在意對象是否是可變的。比如,對象只是用來映射數(shù)據(jù)庫讀出來的數(shù)據(jù),那我們直接暴露 set() 方法來設置類的成員變量值是完全沒問題的。而且,使用建造者模式來構(gòu)建對象,代碼實際上是有點重復的,ResourcePoolConfig 類中的成員變量,要在 Builder 類中重新再定義一遍。
與工程模式的區(qū)別?
在前言中,我們有提到建造者模式與工廠模式都是創(chuàng)建型的設計模式,那他們之間的區(qū)別是什么?
實際上,工廠模式是用來創(chuàng)建不同但是相關類型的對象(繼承同一父類或者接口的一組子類),由給定的參數(shù)來決定創(chuàng)建哪種類型的對象。建造者模式是用來創(chuàng)建一種類型的復雜對象,通過設置不同的可選參數(shù),“定制化”地創(chuàng)建不同的對象。
總結(jié)
如果一個類中有很多屬性,為了避免構(gòu)造函數(shù)的參數(shù)列表過長,影響代碼的可讀性和易用性,我們可以通過構(gòu)造函數(shù)配合 set() 方法來解決。
但是,如果存在下面情況中的任意一種,我們就要考慮使用建造者模式了。
我們把類的必填屬性放到構(gòu)造函數(shù)中,強制創(chuàng)建對象的時候就設置。
如果必填的屬性有很多,把這些必填屬性都放到構(gòu)造函數(shù)中設置,那構(gòu)造函數(shù)就又會出現(xiàn)參數(shù)列表很長的問題。
如果我們把必填屬性通過 set() 方法設置,那校驗這些必填屬性是否已經(jīng)填寫的邏輯就無處安放了。
如果類的屬性之間有一定的依賴關系或者約束條件,我們繼續(xù)使用構(gòu)造函數(shù)配合 set() 方法的設計思路,那這些依賴關系或約束條件的校驗邏輯就無處安放了。
如果我們希望創(chuàng)建不可變對象,也就是說,對象在創(chuàng)建好之后,就不能再修改內(nèi)部的屬性值,要實現(xiàn)這個功能,我們就不能在類中暴露 set() 方法。
構(gòu)造函數(shù)配合 set() 方法來設置屬性值的方式就不適用了。
除此之外,在今天的講解中,我們還對比了工廠模式和建造者模式的區(qū)別。
工廠模式是用來創(chuàng)建不同但是相關類型的對象(繼承同一父類或者接口的一組子類),由給定的參數(shù)來決定創(chuàng)建哪種類型的對象。
建造者模式是用來創(chuàng)建一種類型的復雜對象,可以通過設置不同的可選參數(shù),“定制化”地創(chuàng)建不同的對象。
到此這篇關于Java設計模式中的建造者模式詳解的文章就介紹到這了,更多相關Java建造者模式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
Java解除文件占用即Dom4j操作后實現(xiàn)xml關流
這篇文章主要介紹了Java解除文件占用即Dom4j操作后實現(xiàn)xml關流,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-04-04
SpringBoot使用Kaptcha實現(xiàn)驗證碼的生成與驗證功能
這篇文章主要介紹了SpringBoot使用Kaptcha實現(xiàn)驗證碼的生成與驗證功能,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-03-03
在SpringBoot里自定義Spring MVC配置的三種方法
SpringBoot幫我們自動配好了 MVC 的核心組件,但實際開發(fā)中,光用默認配置肯定不夠今天就教你 3 種自定義 Spring MVC 配置的方法,從簡單到復雜,新手也能一步步跟著做,需要的朋友可以參考下2026-03-03
實例化JFileChooser對象報空指針異常問題的解決辦法
今天小編就為大家分享一篇關于實例化JFileChooser對象報空指針異常問題的解決辦法,小編覺得內(nèi)容挺不錯的,現(xiàn)在分享給大家,具有很好的參考價值,需要的朋友一起跟隨小編來看看吧2019-02-02
Springboot3統(tǒng)一返回類設計全過程(從問題到實現(xiàn))
文章介紹了如何在SpringBoot3中設計一個統(tǒng)一返回類,以實現(xiàn)前后端接口返回格式的一致性,該類包含狀態(tài)碼、描述信息、業(yè)務數(shù)據(jù)和時間戳,并提供了便捷的靜態(tài)工廠方法和全局異常處理機制,感興趣的朋友跟隨小編一起看看吧2025-12-12

