You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Giả sử bạn có một class Notifier với method send, method này chỉ gửi message đi mà thôi, thế nhưng bạn còn muốn nhiều hơn thế, thay vì chỉ gửi message bạn còn muốn gửi
Mail
Tin nhắn slack
Tin nhắn facebook
...
Một cách giải quyết đơn giản đó là extends từ class Notifier thành các classes:
FacebookNotifier
SlackNotifier
...
Thế nhưng cách làm này có một nhược điểm có thể thấy rõ đó là việc nó sẽ làm tăng số lượng classes lên một cách "đáng kể".
Solution
Việc kế thừa không giúp chúng ta có thể thay đổi hoặc chỉnh sửa behavior của obj tại runtime. Mà ta chỉ có thể thay thế toàn bộ object mà thôi.
Thông thường các ngôn ngữ OOP chỉ cho phép đơn kế thừa (1 subclass extend 1 parentClass only).
Một cách giải quyết ở đây đó là Aggregation hoặc Composition, bản thân 1 object sẽ kết tập từ nhiều objects thuộc về các classes khác, từ đó "chuyển tiếp - delegate" công việc cho các classes kia.
Có thể mô tả pattern này trong 1 từ đó là "Wrapper", khái niệm wrapper ở đây sẽ được hiểu như việc một object có thể "link" tới các target objects khác. Wrapper thường delegate các requests mà nó nhận được (trong thực tế thì wrapper có thể chỉnh sửa kết quả hoặc param sau hoặc trước khi delegate cho các target objects).
Bản thân các wrapper cũng sẽ implements các interface giống như các objects được "bao" bên trong wrapper, từ phương diện của client thì các objects này là như nhau.
Các decorator sẽ bao lấy nhau thành 1 stack, stack cuối cùng sẽ được sử dụng bởi client. Do các decorator đều implement 1 interface nên client code sẽ không quan tâm tới việc đó là "pure" object hay là một decorator.
Structure
Pros
Có thể mở rộng object behavior mà không cần tạo subclass
Có thể thêm chức năng cho object ở runtime
Có thể kết hợp các behaviors lại bằng cách wrap một object với nhiều decorators.
Cons
Khó có thể loại bỏ một wrapper khỏi wrapper stack.
Khó có thể triển khai một decorator theo cách mà các behaviors của nó không phụ thuộc vào thứ tự của decorators stack.
The text was updated successfully, but these errors were encountered:
Problem
Giả sử bạn có một class
Notifier
với methodsend
, method này chỉ gửi message đi mà thôi, thế nhưng bạn còn muốn nhiều hơn thế, thay vì chỉ gửi message bạn còn muốn gửiMột cách giải quyết đơn giản đó là
extends
từclass Notifier
thành các classes:Thế nhưng cách làm này có một nhược điểm có thể thấy rõ đó là việc nó sẽ làm tăng số lượng classes lên một cách "đáng kể".
Solution
Một cách giải quyết ở đây đó là Aggregation hoặc Composition, bản thân 1 object sẽ kết tập từ nhiều objects thuộc về các classes khác, từ đó "chuyển tiếp - delegate" công việc cho các classes kia.
Có thể mô tả pattern này trong 1 từ đó là "Wrapper", khái niệm wrapper ở đây sẽ được hiểu như việc một object có thể "link" tới các
target objects
khác. Wrapper thường delegate các requests mà nó nhận được (trong thực tế thì wrapper có thể chỉnh sửa kết quả hoặc param sau hoặc trước khi delegate cho các target objects).Bản thân các wrapper cũng sẽ implements các interface giống như các objects được "bao" bên trong wrapper, từ phương diện của client thì các objects này là như nhau.
Các decorator sẽ bao lấy nhau thành 1 stack, stack cuối cùng sẽ được sử dụng bởi client. Do các decorator đều implement 1 interface nên client code sẽ không quan tâm tới việc đó là "pure" object hay là một decorator.
Structure
Pros
Cons
The text was updated successfully, but these errors were encountered: