"Separates object construction from its representation"
The Builder pattern separates the construction of a complex object from
its representation so that the same construction process can create
different representations. This pattern is used by fast food
restaurants to construct children's meals. Children's meals typically
consist of a main item, a side item, a drink, and a toy (e.g., a
hamburger, fries, Coke, and toy dinosaur). Note that there can be
variation in the content of the children's meal, but the construction
process is the same. Whether a customer orders a hamburger,
cheeseburger, or chicken, the process is the same. The employee at the
counter directs the crew to assemble a main item, side item, and toy.
These items are then placed in a bag. The drink is placed in a cup and
remains outside of the bag. This same process is used at competing
restaurants.
Explore My Other Channel for More Cool and Valuable Insights
👉 Youtube Learn Tech Tips👉 Tiktok
👉 Facebook:
Rules of thumb
- Sometimes creation patterns are complementory: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
- Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
- Builder often builds a Composite.
- Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
Download full source code here
Xây dựng Robots với mẫu Builder
“Tin tốt!” Giám đốc điều hành của GigundoCorp reo lên, trong khi phóng như bay vào phòng họp.
“Khách hàng của chúng ta nói rằng họ muốn kiểm soát nhiều hơn tính năng của Robot, vì vậy chúng ta không thể sử dụng những bộ khuôn Template đã viết sẵn được nữa. Bây giờ họ muốn họ có thể chọn hành động mà robot sẽ thực hiện”
“Để tôi làm rõ chỗ này”, bạn nói “Đầu tiên, chúng ta thiết lập mọi thứ , robot khởi động, nhận nguyên liệu, lắp ráp, kiểm tra và dừng. Nhưng bây giờ khách hàng lại muốn kiểm soát trình tự này và chọn lựa những chức năng họ muốn? Có thể là robot khởi động, rồi kiểm tra, rồi lắp ráp, rồi dừng?”
“Đúng vậy”, Giám đốc nói
“Đây là thời điểm để sử dụng một mẫu thiết kế mới”, bạn nói
“Tôi e rằng phải làm như vậy”, Giám đốc nói.
Những quy định của khách hàng
Trong mẫu thiết kế Template Method, vấn đề chính là những thuật toán nhiều bước – bạn có thể cài đặt nó theo cách bạn muốn, và những lớp con sử dụng theo cách bạn đã thiết lập (Mặc dù bạn có thể viết lại một số bước, nhưng quy trình vẫn không thay đổi ). Nhưng bây giờ tình hình đã khác – khách hàng muốn họ thiết lập trình tự hoạt động và số lượng các bước của thuật toán. Vì vậy mã nguồn mà bạn đã phát triển không còn là trung tâm chính nữa, bạn phải đóng gói nó trong một lớp mới, lớp builder.
Mẫu Template Method mà ta đã được làm quen trong phần trước cho phép bạn tùy chỉnh các bước của một thuật toán bằng cách viết lại các bước trong thuật toán như hình sau:
Mọi chức năng đều dựa trên khuôn mẫu Template trong mẫu thiết kế này, và bạn có thể tùy chỉnh template theo cách bạn muốn. Nhưng bây giờ bạn không còn điều khiển thuật toán nữa, thay vào đó chính khách hàng thực hiện. Họ tạo robot với những chức năng và trình tự họ muốn. Ví dụ để thêm hành động khởi động, khách hàng có thể gọi hàm addStart. Để thêm hành động kiểm tra, họ gọi hàm addTest và ....
Để có thể đáp ứng yêu cầu kiếm soát hành động robot của khách hàng
GigundoCorp, bạn phải chuyển mã nguồn cũ qua một lớp mới, lớp
CookieRobotBuilder, lớp này hỗ trợ các hàm addStart, addTest,
addAssemble và hàm addStop:
Nhờ đó, khách hàng có thể sử dụng CookieRobotBuilder để tạo robot nướng bánh. Khi khách hàng tạo xong robot, mã nguồn sẽ gọi hàm getRobot của đối tượng CookieRobotBuilder để nhận về một robot mới,
Và bây giờ khách hàng đã nắm quyền kiểm soát các thuật toán, bạn
không phải kế thừa một template mẫu nữa.Thay vì vậy, để tạo một loại
khác của robot, bạn cho phép khách hàng sử dụng những đối tượng builder
khác nhau.
Ý tưởng chính như sau: bây giờ khách hàng có thể thiết lập trình tự
và số lượng các bước trong thuật toán, và chọn lựa đúng đối tượng
builder để tạo ra robot mà họ muốn.
Sách của GoF nói rằng, mẫu thiết kế Builder “Tách rời việc tạo dựng
một đối tượng phức tạp ra khỏi bản thân đối tượng vì vậy cho phép cùng
một quá trình tạo dựng có thể tạo ra nhiều loại đối tượng khác nhau”
Khác biệt lớn nhất giữa mẫu Template Method và mẫu Builder là ai sẽ
tạo ra trình tự các bước trong thuật toán. Trong mẫu Template, bạn là
người tạo ra trình tự, và các lớp con sẽ hiện thực chúng. Trong mẫu
Builder, khách hàng sẽ thiết lập trình tự và số lượng các bước trong
thuật toán, và hoán đổi giữa các builder mà phải cung cấp để tạo ra các
đối tượng khác nhau thể hiện thuật toán đó.
Sử dụng mẫu thiết kế Builder khi bạn muốn khách hàng kiểm soát được
quá trình tạo dựng. Ví dụ, đây là mẫu thiết kế mà bạn muốn khi bạn xây
dựng robot sử dụng cùng một quá trình khởi tạo nhưng muốn có thể tạo ra
những con robot khác nhau. Tất cả những gì khách hàng cần là gọi những
builder khác nhau – quá trình xây dựng vẫn như cũ. Đây là một ví dụ
khác, bạn muốn đọc một đoạn văn bản và xây dựng một tài liệu, nhưng bạn
lại không biết định dạng chính xác của nó là RTF, Microsoft Word, hay
văn bản đơn giản… Mặc dù quá trình tạo dựng là giống nhau cho từng tài
liệu, bạn có thể sử dụng những builder khác nhau để tạo dựa vào kiểu của
loại tài liệu.
Nói cách khác, khi khách hàng muốn kiểm soát quá trình tạo dựng,
nhưng bạn vẫn muốn có thể tạo ra nhiều đối tượng khác nhau, mẫu Builder
sẽ giúp bạn thực hiện điều đó.
Ghi nhớ: Mẫu thiết kế này tương tự với mẫu Factory, nhưng mẫu
Factory là trung tâm trong quá trình khởi tạo một bước, chứ không cài
đặt nhiều bước như ở đây.
Cho phép khách hàng tạo Robot
Khi bạn sử dụng mẫu Builder, khách hàng sẽ phụ trách quá trình tạo
dựng. Khách hàng sử dụng đối tượng xây dựng builder của bạn để làm những
gì họ muốn. Để cho phép khách hàng tạo robot thể hiện một loạt các hành
động – khởi động, lắp ráp, ngừng… – Tôi tạo ra một giao diện interface
Robot Builder hỗ trợ các hàm như sau: addStart, addGetParts,
addAssemble, addTest và addStop:
Ví dụ để tạo một robot với các hành động start, test, assemble và sau
đó là stop, khách hàng chỉ cần gọi hàm addStart, addTest, addAssemble
và addStop của đối tượng xây dựng builder theo đúng trình tự đó. Khi
robot đã được tạo xong, khách hàng chỉ cần gọi hàm getRobot của Builder
để nhận về một robot mới. Và đối tượng robot mới này có hỗ trợ hàm go,
hàm này sẽ thực hiện hàng loạt hành động mà bạn đã tạo dựng trước đó.
Bởi vì bạn có nhiều loại đối tượng builder để tạo nhiều loại robot
khác nhau – ví dụ như builder xây dựng robot làm bánh, builder xây dựng
robot lắp ráp ô tô – Tôi sẽ tạo một giao diện interface RobotBuilder mà
tất cả các builder sẽ hiện thực giao diện này. Đây là những hàm mà các
robot builder phải hiện thực, từ hàm addStart tới hàm addStop, kể cả hàm
getRobot. Xem mã sau:
Bạn thấy đó:
Khách hàng có thể cài đặt các hành động cho robot như start, stop, test,
assemble, getParts … theo trình tự bất kì.
Tuyệt vời. Bạn có thể đưa builder cho khách hàng, giúp khách hàng có thể kiểm soát quá trình tạo dựng đối tượng.
Ref
https://sourcemaking.com/design_patterns/builder
https://haihth.wordpress.com/2013/02/23/dp-chapter7/
Thank you for reading this post. I hope you found it helpful and easy to follow. If you have any feedback or questions about
Builder Pattern: A Design Pattern for Creating Complex Objects ,
please share them in the comments below. I would love to hear from you and discuss this topic further
✋✋✋✋
Webzone Tech Tips, all things Tech Tips for web development
- I am Zidane, See you next time soon ✋✋✋✋
