構建器模式

有三種方法可以用Java編程語言創建新對象：

伸縮構造函數（反）模式

Javabeans模式

建造者模式

與其他兩種方法相比，我更喜歡使用構建器模式。

為什么？

Joshua Bloch描述了構建器模式以及在Effective Java中使用它的好處。 他的工作非常出色，在這篇博客文章中，我將不再重復這些好處。

取而代之的是，我將描述為什么我更喜歡構建器模式而不是伸縮構造器模式和Javabeans模式的三個其他原因。

1.幫助您進行更好的設計

使用伸縮構造函數模式或Javabeans模式意味著必須在創建實際對象之前創建所創建對象的屬性。

這可能是問題，也可能不是問題。

如果使用外部服務獲取創建的對象的屬性，則不會有問題。 但是，如果屬性是在創建“目標”對象的方法中創建的，則會出現問題。

在后一種情況下，創建的對象的生命周期通常綁定到“目標”對象的生命周期。

在這種情況下，構建器模式可以幫助您使用稱為聚合的域驅動設計（DDD）模式。 Martin Fowler指定聚合模式如下：

DDD聚合是域對象的群集，可以將它們視為一個單元。 一個示例可能是訂單及其訂單項，它們將是單獨的對象，但是將訂單（連同其訂單項）視為一個單獨的集合很有用。

構建器模式可以幫助您以將域模型劃分為聚合的方式來設計代碼。 這意味著屬于聚合的所有對象都是由聚合根對象（訂單）創建的，并且只能通過聚合根對象進行訪問。

這將構造關系與邏輯關系移到它所屬的地方。

2.讓你思考

以傳統方式編寫代碼很容易，因為您無需思考。 您所要做的就是編寫將信息從一個地方復制到另一個地方的代碼。 可能要花一些時間，但這對您來說不是問題，因為您處于舒適區。

也許您只是想處理代碼而不考慮自己在做什么。

我不是那樣的人（你也不應該那樣）。

構建器模式迫使您考慮對象。 更具體地說，它迫使您考慮以下事項：

• 您必須找出對象的必需和可選屬性。
• 您必須確定將生命周期綁定到所創建對象的生命周期的屬性，并設計構建器，以便其強調這一點。
• 您必須確定在創建對象后不能更新哪些屬性（并將這些屬性標記為最終屬性）。
• 您必須決定可以更新哪些屬性，并找到更新它們的最佳方法。

找到這些問題的答案有助于您編寫更好的代碼。 我可以保證，如果您花時間找到這些問題的答案，您的代碼將比自動駕駛儀上編寫的代碼好得多。

3.它幫助您創建特定于域的語言

如果使用伸縮構造器模式或Javabeans模式創建新對象，則很難在代碼中添加業務含義。 您可以按照以下原則嘗試改善情況：

• 您可以向構造函數參數添加業務含義的唯一方法是以適當的方式命名參數。 這很難做到，即使您做對了，結果也不是最佳的。
• 如果使用設置器，則當然可以用一種添加設置器方法的方式來命名它們。 但是，您有多少次看到以該原理命名的setter方法？

在100個對象中，有99個創建的對象只是沒有意義的對象。 他們保存數據。 就這些。

使用構建器模式時，可以通過命名構建器類的方法來創建用于創建新對象的域特定語言（DSL） 。 這可以幫助您在創建新對象的代碼中添加業務含義。

這就提出了一個問題：如何更新對象的屬性？

當然，您可能會很無聊，并使用setter方法來更新對象的各個屬性。 但是您也可以做一些完全不同的事情。

您可以將這些屬性分組為有意義的組，而不用更新單個屬性，并且可以通過一種方法更新這些屬性的值。 如果正確命名此方法，則可以創建DSL來更新現有對象的信息。

這不是銀彈

布雷克?考德威爾（Blake Caldwell）表示， 對于構造器來說，構造器模式本質上不太容易出錯 。 我同意他的觀點。

當您開始使用構建器模式時，首先要注意的是創建新對象的代碼更易于編寫和閱讀。 但是，一段時間后，您可能還會注意到其他好處。 我知道我做到了。

但是，重要的是要了解構建器模式不是靈丹妙藥 。

我認為， 沒有人會因為一種最佳實踐而遵循最佳實踐 。 這也適用于構建器模式。

如果您的對象只有幾個構造函數參數，則使用構建器模式沒有任何意義。 但是，由于此博客文章（和Effective Java）中所述的好處，您每次必須創建新對象時都應考慮使用構建器模式。

參考： Petri Kainulainen博客上我喜歡 JCG合作伙伴 Petri Kainulainen 的構建器模式的三個原因 。

翻譯自: https://www.javacodegeeks.com/2014/02/three-reasons-why-i-like-the-builder-pattern.html

構建器模式

總結

以上是生活随笔為你收集整理的构建器模式_我喜欢构建器模式的三个原因的全部內容，希望文章能夠幫你解決所遇到的問題。

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