Decorator Design Pattern: Phân tích và ví dụ

Hế lô hế lô, Ông dev đây!
Trong phần này mình sẽ nói về định nghĩa và một vài ví dụ về Decorator Design Pattern.
Tóm tắt:
Decorator là cách để chúng ta thêm các hành vi của một đối tượng trong runtime nhưng vẫn giữ nguyên đối tượng.
Ví dụ như khi ta đi mua trà sữa, chúng ta muốn mua món Trà sữa chocolate bạc hà trân châu trắng trân châu đen pudding trứng pudding sữa chua, thì người ta sẽ tính tiền như thế nào?
Thì khi đấy là lúc ta có thể sử dụng decorator để mở rộng hành vi tính tiền bằng việc bọc object ban đầu bằng các decorator và thêm giá cho nó, còn để hiểu rõ hơn, thì xem cả 3 video nhé :D
Giống như trong lập trình, nếu chúng ta sử dụng kế thừa bình thường và phải đáp ứng một đối tượng phức tạp, thay vì tạo các class lớn và có khả năng bị trùng code hoặc mang lại khó khăn cho việc bảo trì sau này. Chúng ta có thể sử dụng Decorator để tách những phần nhỏ ra và thêm vào nếu muốn trong runtime vì ta (không muốn hoặc không thể) (làm phình hoặc thay đổi) class khi compile.
Bạn có thể xem các phần sau ở đây:
-Class diagram: • Decorator Design Patte...
-Code: • Decorator Design Patte...
Link của cả playlist design pattern:
• Design Pattern
Source code: github.com/Mil...
-- Để xem những video về lập trình và gaming --
Nhấn vào đây để theo dõi kênh mình nhé: duyngd.com/Sub...
-- Blog của mình --
duyngd.com
-- Facebook page của mình --
/ ongdevvuitinh
-- Ủng hộ Ông Dev --
Cảm ơn các bạn đã quan tâm theo dõi
#Ôngdev #Decorator #DesignPattern

[@ethannguyen9123]

Great video, Ông Dev! Nhưng có 1 số vấn đề: 1. Định nghĩa: Decorator là cách để chúng ta thêm các hành vi cũng như trạng thái của một đối tượng. => Đúng nhưng thiếu: Decorator cho phép thêm hành vi bằng cách đặt object vào trong 1 object khác, "object khác" đó gọi là decorator. 2. Ví dụ: Trà sữa => Cách ví dụ của bạn không sát với ứng dụng của Decorator pattern. Theo ví dụ của bạn, để tách topping ra ngoài thì mình có thể đơn giản làm như sau: interface IMilkTea{ void AddTopping(Topping topping) } Đơn giản như vậy và bạn không cần phải ứng dụng Decorator pattern. Vậy ví dụ thế nào mới đúng? Xem phần 3. 3. Quay lại với Design pattern, design pattern được sử dụng để solve một cái problem, nếu bạn không có problem thì bạn không cần dùng Design Pattern. Trong description bạn có ghi: Chúng ta có thể sử dụng Decorator để tách những phần nhỏ ra và thêm vào nếu muốn trong runtime. => Nếu bạn có thể tách object ra những phần nhỏ hơn thì nghĩa là bạn có khả năng thay đổi object lúc compile mà không cần làm trong runtime. Decorator nên ứng dụng khi bạn không thể (hoặc không muốn) thay đổi object nhưng vẫn muốn thêm hành vi. Ví dụ: Bạn có class MilkTea với method Build() để làm 1 ly trà sữa trân châu bình thường. Nếu bạn muốn thêm Pudding mà không phải sửa class MilkTea thì làm thế nào. Bạn tạo một class BaseMilkTeaDecorator kế thừa MilkTea với constructor có parameter là MilkTea và attach behaviour vào trong Build{} method class BaseMilkTeaDecorator{ MilkTea wrappee; BaseMilkTeaDecorator(MilkTea wrappee){} void Build(){} } Và mỗi loại topping thì bạn kế thừa từ cái BaseDecorator. Client nếu muốn đặt trà sữa trân trân châu chocolate pudding thì có thể làm như sau: var milkTea = new PuddingMilkTea(new ChocolateMilkTea(new MilkTea())); milkTea.Build();

[@ethannguyen9123]

@ Điểm 2: Ở đây chúng ta không bàn về việc làm gì trong method đó, chúng ta không đi sâu vào việc làm thế nào để add topping vào trong 1 ly trà sữa. Chúng ta đang discuss về high level. Nếu bạn nói đến việc mỗi loại topping có 1 cách khác nhau để add vào thì đó là chúng ta có thể ứng dụng những design pattern khác hoặc có cách khác để solve problem (ví dụ như define một method trong topping hoặc strategy pattern) Ý chính của mình ở đây là việc bạn có thể KHÔNG phải sử dụng Decorator pattern để solve cái problem trong ví dụ trà sữa nếu bạn có thể thay đổi class hay object. Điểm 3: Sorry vì không để ý đến việc bạn có thêm 2 phần sau. Về việc bạn nói tách nhỏ thì có thể thay đổi ngay compile, ừ đúng bạn có thể đổi, nhưng có phải bạn cần phải có 1 class mới để ôm cái đống rúi nhùi đấy không. Và đó là thứ chúng ta không muốn. => Không cần thiết phải sử dụng 1 class duy nhất, bạn có thể tìm 1 design khác để giải quyết bài toán hoặc ứng dụng một design pattern khác. Câu trả lời của bạn đã phản bác lại ví dụ của bạn, mình đồng ý là những method đi theo như tính tiền chẳng hạn là một ứng dụng tốt cho Decorator nhưng bạn không đề cập đó trong description mà bạn lại dùng ví dụ thêm topping. Mình nhấn mạnh rằng mình không phải ở đây để bắt lỗi bạn, nhưng mình muốn góp ý để bạn có thể đặt đúng trọng tâm khi nói về 1 cái design pattern. Chúng ta có thể hiểu một design pattern nhưng phải ứng dụng sao cho hợp lý mới là điều cốt lỗi. Nếu không nó chỉ dẫn đến "Needless complexity" mà thôi

Sorry bạn rất nhiều vì mình chuyển kênh từ Brand account sang account chính nên toàn bộ comments của mình bị mất hết. Dù sao thì cũng cảm ơn bạn đã cùng mình trao đổi vấn đề trên, mình cũng đã rút kinh nghiệm và luôn nhắc mọi người chú ý về tính cần thiết của việc sử dụng design pattern và phải phân tích thật kĩ vấn đề để tránh việc làm phức tạp hóa vấn đề một cách không cần thiết. Rất mong tiếp tục nhận được những phản hồi từ bạn trong các video tiếp theo nhé.

[@hlong22]

Em đang tìm hiểu về design pattern, em rất cảm ơn những video của anh và hy vọng anh sẽ ra thật nhiều video về chủ đề này ạ

[@ucmanhpham5647]

Cảm ơn kênh của anh, nhiều video chất lượng cũng như gãi đúng chỗ ngứa quá ạ !

[@wilokelearning3060]

Giải thích siêu dễ hiểu bạn ơi

[@vrains24]

theo mình hiểu đơn giản thì mục đích của Decorator là để thêm 1 tính năng và sử dụng nó trước khi gọi tính năng của class cũ (đúng với ý nghĩa Trang trí). Ví dụ: class UserRepo có phương thức Create để tạo User mới, bây giờ mình muốn thêm phương thức Valid trước khi Create user thì mình sẽ dùng class Decorator để bọc UserRepo (kế thừa củng Interface và thêm 1 phương thức Valid). Khi người dúng đứng từ ngoài gọi phương thức Create của class Decorator thì nó sẽ bao gồm gọi Valid trước rồi mới gọi Create. Hiểu như thế này sẽ thực tế hơn là ví dụ Trà sữa chỉ tính giá cộng thêm, nó giống Builder pattern cộng thêm các chi tiết cho 1 object hơn.😁

Hi Ông Dev, cho mình hỏi là Decorator Pattern này có được phép thay đổi thuộc tính của đối tượng được dùng để decorator không?

[@Dtanphat9388]

ở phút 3:57 mình nghĩ nó là builder pattern, vd: trasua.addTopping('trung') .addTopping('tranchau') .size('M')

[@huynhthanh5207]

Mình cũng mới tìm hiểu về design pattern này. Nếu thêm những thuộc tính cũng như method vào object trong thời điểm runtime thì mình cũng phải đánh đổi về tốc độ? Môt video giải thích rất hay.

Thực ra thì nó cũng sẽ ngang với lại khi chúng ta dùng kế thừa thôi, vì nếu kế thừa bạn cũng sẽ phải có base class rồi các class con sẽ override và call base function.

[@huyttran4355]

mình cảm thấy cách giải thích của anh về ứng dụng của decorator sao giống với composite design pattern. Anh có thể làm một video giải thích về dynamic linkage ko. Cảm ơn anh

[@vohoanghaduong6639]

ủa anh ở Đà Nẵng à, em cũng ở ĐN nè. Trước giở tưởng anh ở HN cơ

Uh a ở ĐN á

[@vohoanghaduong6639]

được ở cùng tp với idol ​ @ongdev, zui quá đê 😁

[@ThongMr]

Ư thích quá

[@tranttlc4645]

CÓ THỂ LÀM VỀ DEPENDENCE INJECTION ĐƯỢC KHÔNG ÔNG GIÁO ? THANKS

Đc chớ :v mà viết thường thôi :’( viết hoa đọc hơi sợ huhu

[@phamvanhan7037]

ông dev này người đà nẽn hả?

Uh, mình người Đà Nẵng :D