馬丁花背著灰色的雙肩背包走進了公司寫字樓，浮現在眼前的是排成長蛇狀的一群上班族，正按照單雙層各自分成兩隊等候著電梯。低樓層的童鞋等不及了，甩開雙腿開始爬樓梯，就當是減肥鍛煉身體了，不著急的依舊排在隊伍里，低頭看著手機，玩著游戲或者刷著朋友圈。手機掃去了等待的急躁與不安，一個個安靜如花，只待電梯像殷勤的主人把他們一批一批接走。

終于踏進了電梯，馬丁花被擠到了角落里，電梯里的人互不相識，肅穆像開追悼會，只聽得電梯不斷發出“叮”的一聲響，電子合成聲開始匯報多少層到了，門打開，隨著不斷有人走出，空間變得逐漸開闊起來。

“十八層到了！”自從新搬到這棟寫字樓后，馬丁花每次聽到呆板而不帶感情的電子合成聲匯報所在樓層到達時，都忍不住翻一下白眼，心里不由腦補出“地獄”兩個字眼兒。搖搖頭，緩緩走出電梯。

刷卡。自動門剛一打開，就瞥見一道身影正要到正前方拐角處的茶水間倒水，看見自己來了，又趕緊退了回去，似乎故意躲著馬丁花。這道身影再熟悉不過，自然躲不過馬丁花敏銳的法眼，趕緊叫到：“蔡了！”

“啊……這么倒霉，一上班就被頭兒盯住了，昨天布置的作業沒完成，怎么辦！”蔡了內心不由哀嚎，聽到馬丁花的聲音，只得停下來，無奈裝出一副笑臉，言不由衷地說道：“老大，早上好啊！”

“躲著我啊！昨天的作業沒做，對吧？”馬丁花看到她一副強顏歡笑的樣子，哪還不知道古靈精怪的她打的甚么主意，即刻開啟了嚴師模式。

“哼，勤奮如我怎么會沒有完成作業呢？”蔡了趕緊辯解，“——只是，我雖然搞清楚了靜態工廠實際用的是簡單工廠模式，卻不知道它能給設計帶來什么好處？查了好多資料，發現居然有各種各樣的工廠模式，不看還好，越看越糊涂了！”

“嗯，看來你還是做了些功夫的。一會開完站會，到我工位來，我給你簡單講一講吧！”

蔡了點點頭，謝過馬丁花，徑直到茶水間倒水去了。

站會一開完，蔡了就規規矩矩前來受教。馬丁花開門見山，直截了當地說到：“工廠在設計模式中，其實就是一種比喻，目的自然是為了更好地創建對象。既然在Java中已有構造函數能夠擔負實例化的職責，為何還需要引入工廠呢？要明白工廠的價值，你就需要先明確構造函數的缺陷，對吧？”蔡了不由得點頭稱是，似乎得到了一絲啟發。

“你想想，Java語法中構造函數是怎么定義的？它有哪些語法上的限制？”馬丁花循循善誘地提出了問題。

蔡了在腦海中搜索著這段時間學習的Java語法，心里組織著語言，回答道：“類的構造函數與類名必須保持一致；構造函數支持方法重載，但不允許出現相同方法簽名；每個具體類的構造函數都只能創建類自身；如果定義了帶參構造函數，且又需要無參構造函數，還需要顯式定義無參的構造函數。”

“不錯！語法記得很清楚。那么，根據這些語法限制，你想想：如果需要創建代碼給出清晰的創建目的，構造函數能不能做到？如果創建的對象有可能發生變化，構造函數能不能做到？如果希望控制對象的創建邏輯，構造函數能不能做到？”

“好像是這么回事，不過大叔啊，你可否給我個例子，這樣枯燥的理論講解讓人很難理解呢。”小姑娘有些得寸進尺了。

“好吧。”馬丁花看著她一臉困惑的樣子，無奈地搖搖頭，打開IntelliJ，找到JDK中的Optioanal<T>類，展示給蔡了：

“你看JDK 8提供的Optional<T>類，它就定義了諸如empty()、of()和ofNullable()這幾個簡單工廠，它們創建的雖然都是Optional<T>對象，可相較于直接調用構造函數，它們有什么價值？”

蔡了陷入沉思中。馬丁花提醒道：“還是昨天那句話，你要學會站在調用者的角度看待API設計。”這么一說，小姑娘就回過味來，說道：“對啊，有了這些簡單工廠，就能更加清晰地告訴調用者究竟創建了什么樣的Optional對象，尤其那個empty()，實在太傳神了！這實際上就是可讀性的要求嘛，很好理解喲。”馬丁花看著她一副不屑一顧的樣子，想到她剛才一臉茫然抱怨不好理解，真恨不得給她腦門上來一記頭粟！

蔡了倒是沒來得及察言觀色，繼續想著老馬剛才問的幾個問題，想不通，只得問道：“嘿，大叔，你剛才說控制對象的創建邏輯，我有些不清楚，構造函數就是方法啊，難道還不能控制創建的邏輯？”

“如果創建邏輯只是驗證、組裝、計算等邏輯，構造函數確實辦得到；但是，你注意到沒有，Java類的構造函數是沒有return的，如果你希望控制對象創建的次數，又或者希望引入緩存提升創建對象的性能，構造函數還能做到嗎？更不用說，在有些情況下，如果需要通過反射創建對象，就更需要引入靜態工廠方法來封裝對象創建的邏輯了。”

“例如有Composer繼承體系。”馬丁花繪制出如下類圖：

“考慮Composer的擴展性，需要通過反射創建各個Composer實現類，類名遵循格式：文件擴展名+Composer，你想想看，可以通過YamlComposer或其他實現類的構造函數來完成嗎？”

蔡了使勁搖頭！馬丁花把一段示例代碼打開，指著代碼繼續講道：“這個時候，就需要引入一個專門的工廠類，為其定義一個靜態工廠方法，用來封裝創建邏輯。”

“大叔！”蔡了認真看著這個案例，忽然靈機一動，想到一點，趕緊指出來：“那你說的創建對象有可能發生變化，是不是也屬于這種情況啊？”

“孺子可教！”馬丁花很高興看到蔡了能夠觸類旁通，繼續講道：“剛才說到的Composer對象的創建之所以引入反射，確實考慮到了創建對象的變化，不過，在多數情況下，不一定要使用反射來解決這一問題。只要你希望調用者無需了解產品對象創建變化的邏輯，在工廠方法返回父類產品的前提下，你都可以使用簡單工廠。例如JDK中的Collections類，就定義了許多靜態工廠方法，用于創建Collection<T>對象。創建的這些對象可能是不同的集合類型，但對于調用者而言，可以不必知道產品對象的具體類型。”馬丁花一邊說著，一邊打開Collections類的定義，將光標快速移到unmodifiableCollection()方法上：

“你看！unmodifiableCollection()方法表面上返回的是一個Collection<T>對象，實際上，在其內部定義了一個內部類UnmodifiableCollection，它屏蔽了集合的修改功能，使之成為一個不可修改的集合。你想想看，這樣做的好處是什么？”

“嗯……”思索良久，蔡了想到了答案：“我想，這樣做應該有兩個好處。一個好處是unmodifiableCollection()方法清晰地向調用者傳遞了創建不可變集合的語義，另一個好處是將來如果修改了UnmodifiableCollection內部類的定義與實現，也不會影響到該工廠方法的調用者。我說的對嗎，馬大叔？”

“不錯，不錯！我看你徹底理解了簡單工廠的含義！”

“噢耶！”得到馬大叔的肯定，蔡了不由得歡呼起來，不過想到其他工廠模式，又苦下臉來，說道：“可是——我還是不太明白簡單工廠模式與工廠方法模式、抽象工廠模式的區別和使用場景呢。”

馬丁花想了想，指著茶水間，向蔡了說道：“說了半天，口也渴了，不如我們去那邊沖一杯咖啡，邊喝邊講，如何？”蔡了點點頭，和馬丁花一起走到了茶水間的咖啡機旁。

---

? 屐痕處處：2019年1月19日攝于法國巴黎

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

技術人成長精彩文章推薦

阿里高級技術專家宋意：平凡人在阿里十年的成長之旅

RocketMQ 大神丁威親述參與開源社區的方式

多隆：從工程師到阿里巴巴合伙人

為什么說IT科技公司應該留住35歲員工？

工程師的基本功是什么？如何練習？聽美團技術大咖怎么說

美團技術專家云鵬:寫給工程師的十條精進原則!

找CTO杜仲：再談中年危機和應對策略

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

Erik Dietrich：二十年的編程，教會我的五件事！

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結

奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考

Netstars CTO陳斌：架構師的成長之路

阿里技術專家麒燁：修煉測試基本功

左耳朵耗子：程序員如何把控自己的職業？

阿里6年，我的技術蛻變之路！

程序員管理思維修煉，只需要反復閱讀本篇

“教授”洪強寧和他穿越的技術江湖

大神手把手教你投身技術18年而沒有中年危機的秘訣

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

CTO 技術管理的“三板斧”

技術管理者必備管理模板

張一鳴：優秀年輕人的五個特點

技術團隊的工程師文化：效率與價值

美團大咖：程序員35歲前應做好的技術積累

史海峰：萬字長文剖析技術人如何成長

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的领域驱动专家张逸文字脱口秀：简单工厂不简单的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。