" A single class that represents an entire subsystem"
The Facade defines a unified, higher level interface to a subsystem that makes it easier to use. Consumers encounter a Facade when ordering from a catalog. The consumer calls one number and speaks with a customer service representative. The customer service representative acts as a Facade, providing an interface to the order fulfillment department, the billing department, and the shipping department.
Rules of thumb
- Facade defines a new interface, whereas Adapter uses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.
- Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
- Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communications between colleague objects. It routinely "adds value", and it is known/referenced by the colleague objects. In contrast, Facade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes.
- Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
- Facade objects are often Singletons because only one Facade object is required.
- Adapter and Facade are both wrappers; but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects.
Question: So the way to tell the difference between the Adapter pattern and the Facade pattern is that the Adapter wraps one class and the Facade may represent many classes?
Answer: No! Remember, the Adapter pattern changes the interface of one or more classes into one interface that a client is expecting. While most textbook examples show the adapter adapting one class, you may need to adapt many classes to provide the interface a client is coded to. Likewise, a Facade may provide a simplified interface to a single class with a very complex interface. The difference between the two is not in terms of how many classes they "wrap", it is in their intent.
ĐƠN GIẢN HÓA CUỘC SỐNG VỚI MẪU FACADE
Một mẫu thiết kế tương tự với mẫu Adapter là mẫu Façade. Hai mẫu này làm việc theo cùng một cách, nhưng mục đích sử dụng của chúng khác nhau. Mẫu adapter chuyển đổi mã nguồn để làm việc được với mã nguồn khác. Nhưng mẫu Façade cho phép bạn bao bọc mã nguồn gốc để nó có thể giao tiếp với mã nguồn khác dễ dàng hơn.
Ví dụ như, có một người thiết kế ra một cái máy in, và đưa cho bạn một cách tự hào. “Làm sao để máy có thể in?” bạn hỏi
“Đầu tiên,” anh ta nói với bạn, “gọi hàm khởi động.”
“Được” bạn nói. “Bây giờ nó in chưa?”
“Chưa, bạn phải gọi turnFanOn”
“OK, giờ nó sẽ in chứ”, bạn hỏi
“Chưa, hãy gọi hàm làm nóng máy warmUp”
“Được rồi. Giờ nó sẽ in, phải không?”
“Vẫn chưa. Bạn phải gọi hàm getData để đưa dữ liệu từ máy vi tính tới máy in”
“OK, hàm getData. Còn gì nữa không?”
“Hàm định dạng dữ liệu formatData”
“Và gì nữa?”
“Hàm kiểm tra đầu mực checkToner, hàm kiểm tra giấy checkPaperSupply, hàm kiểm tra hệ thống runInternalDiagnostic, hàm …”
“Khoan đã”, bạn nói, vậy viết cho tôi một hàm đại diện façade cho tất cả cái đống lộn xộn này. Hàm façade này sẽ gọi tất cả các hàm khác bên trong nó, và đơn giản hóa một cách đáng kể việc giao tiếp. “Chỉ vậy thôi”
“Đó là cái gì?”, người thiết kế máy in hỏi
“Hàm in ấn print”, bạn nói. “Chỉ cần gọi hàm in ấn print, và máy in hoạt động. Không cần làm gì khác.”
“Hey”, anh ta nói “đó có thể là một ý tưởng tuyệt vời. Bây giờ bạn có thể thêm một hàm prepareToCallThePrintMethod , một hàm callThePrintMethod, một hàm cleanupAfterPrinting, một hàm…”
“Anh đúng là hết thuốc chữa” bạn nói.
Mẫu thiết kế Façade tạo ra một giao diện OOP dễ dàng để sử dụng. Nó là một vấn đề thiết kế cơ bản – nếu một đối tượng hay một lớp quá khó để giao tiếp, mẫu Façade tạo ra cho bạn một giao diện để giao tiếp dễ dàng hơn. Đây là định nghĩa chính thức của GoF về mẫu Façade: “Cung cấp một giao tiếp duy nhất cho tập hợp các giao tiếp của hệ thống. Façade định nghĩa một giao tiếp cao hơn để giúp các hệ thống con dễ dàng sử dụng”
Thông thường, bạn sử dụng mẫu Façade khi bạn làm việc với những mã nguồn đã được đóng gói một cách cẩu thả. Không phải ai cũng là một chuyên gia OOP, và bạn cũng nhanh chóng thấy được rằng, khi bạn làm việc trong một môi trường phát triển phần mềm thương mại rộng lớn. Khi bạn trở nên mệt mỏi để giao tiếp với những giao diện được thiết kế rắc rối và nhận thấy rằng, bạn nhận được x,y thay vì một cái z đơn giản hơn. Đó là lúc bạn nên sử dụng một giao diện mới.
Ý tưởng rất đơn giản; một façade làm đơn giản hóa một giao tiếp interface (sử dụng nghĩa chung của từ “interface”, không phải giao diện interface trong Java) giữa một lớp hay một đối tượng.
Bạn thường sử dụng mẫu thiết kế Façade khi bạn muốn mã nguồn đơn giản hơn nhưng lại không thể chỉnh sửa mã nguồn cũ. Thông qua việc sử dụng mẫu Façade bạn có thể giải quyết vấn đề, nó thêm vào một lớp khác bên trên, và nếu mã nguồn của lớp bên dưới thay đổi, bạn cũng phải thay đổi luôn mã nguồn của mẫu Façade.
Có một định nghĩa OOP làm việc ở đây, đôi khi còn được gọi là “Nguyên tắc về sự hiểu biết ít nhất” , đôi lúc được gọi là “Luật của Demeter” , đôi khi được gọi là “sự đóng gói hiệu quả”. Đây là ý tưởng nâng cao sự hiệu quả của OOP, bạn không muốn những thực thể riêng biệt (lớp hay đối tượng) phải biết quá nhiều về nhau. Càng ít càng tốt, bạn có thể che dấu chi tiết của từng lớp hay đối tượng và làm cho sự liên kết của chúng lỏng lẻo càng nhiều càng tốt. (Xem chương bốn để bíêt thêm về “tháo lỏng các mối liên kết” loose coupling) . Nếu một đối tượng cấn phải biết quá nhiều về đối tượng khác, đó chính là lúc cần sử dụng mẫu Façade.
Ghi chú: Hãy tháo lỏng các mối liên kết càng nhiều càng tốt.
Có một định nghĩa OOP làm việc ở đây, đôi khi còn được gọi là “Nguyên tắc về sự hiểu biết ít nhất” , đôi lúc được gọi là “Luật của Demeter” , đôi khi được gọi là “sự đóng gói hiệu quả”. Đây là ý tưởng nâng cao sự hiệu quả của OOP, bạn không muốn những thực thể riêng biệt (lớp hay đối tượng) phải biết quá nhiều về nhau. Càng ít càng tốt, bạn có thể che dấu chi tiết của từng lớp hay đối tượng và làm cho sự liên kết của chúng lỏng lẻo càng nhiều càng tốt. (Xem chương bốn để bíêt thêm về “tháo lỏng các mối liên kết” loose coupling) . Nếu một đối tượng cấn phải biết quá nhiều về đối tượng khác, đó chính là lúc cần sử dụng mẫu Façade.
Ghi chú: Hãy tháo lỏng các mối liên kết càng nhiều càng tốt.
Làm việc với một đối tượng khó khăn
Đây là một ví dụ minh họa cách thức mẫu Façade làm việc. Công ty bạn vừa mua một công ty đối thủ, người quản lý đang rất hân hoan.
“Hmm” bạn nói “ Chúng ta đang gặp rắc rối với vấn đề tương thích?. Sản phẩm của họ quá khác biệt với chúng ta”
“Phi lý”, Ông chủ lớn nói “Mọi việc không thể đơn giản hơn”
“Được,” bạn nói “Làm sao ông có thể đặt tên cho nó”
“Không thể đơn giản hơn. Cứ gọi hàm setFirstNameCharacter. Nó sẽ đặt kí tự đầu cho tên”
“OK, vậy kí tự thứ hai của tên thì sao?”
“Chỉ cần gọi hàm setSecondNameCharacter. Không thể đơn giản hơn”
“OK, để tôi tiếp tục.” bạn nói ”Vậy để đặt tên cho một sản phẩm, ông gọi hàm setFirstNameCharacter để thíêt lập kí tự đầu tiên cho tên, sau đó gọi hàm setSecondNameCharacter để thiết lập kí tự thứ hai, và bằng cách đó ông tiếp tục gọi hàm setFiveMillionNameCharacter để thiết lập kí thứ thứ năm triệu cho tên?”
“Không”, Ông chủ lớn nói “Bạn chỉ có thể đặt tên với bảy kí tự”
“À,” bạn nói “Không thể đơn giản hơn”
“Đúng”, ông chủ nói
Đây là đoạn mã, sau khi bạn hợp nhất với sản phẩm của công ty mới,
Ref
https://sourcemaking.com/design_patterns/facade
https://haihth.wordpress.com/2013/02/23/dp-chapter6/
0 comments:
Post a Comment