Đây là bí quyết để học MVC: MVC chỉ là một vài Design pattern khác được ghép lại với nhau. Khi bạn tiếp cận việc học MVC bằng cách xem xét các design pattern khác, thì đột nhiên MVC bắt đầu dễ hiểu.
Có ai đoán rằng các mẫu thiết kế có thể làm việc với nhau? Chà, tin hay không, một số…
Sẵn sàng cho Virtual Proxy Được rồi, cho đến giờ bạn đã biết định nghĩa về Proxy Pattern là gì…
Proxy Pattern – Kiểm soát truy cập đối tượng Bạn đã bao giờ chơi trò “Good cop, bad cop” (cảnh…
State Pattern – Trạng thái của vạn vật. State Pattern là gì? Hãy ngầm hiểu đây là một mẫu đại diện cho các trạng thái khác nhau của một đối tượng. Ví dụ một thang máy sẽ có trạng thái: đóng cửa, mở cửa, chuông báo động, số tầng…hay một vận động viên bơi lội sẽ có các trạng thái: khởi động, vào vị trí, sẵn sàng, bơi, chạm đích…chúng đều có liên quan đến mẫu thiết kế được đề cập trong chương này: Mẫu Trạng thái – State Pattern.
Ở chương này, bạn sẽ tìm hiểu qua Composite Pattern:
Composite Pattern là mẫu cho phép kết hợp các đối tượng thành các cấu trúc cây để thể hiện hệ thống phân cấp.
Composite Pattern cho phép client xử lý các đối tượng đơn và các composite con theo cùng một kiểu.
Có rất nhiều cách để nhét objects vào một collection. Đặt chúng trong một Array, một Stack, một List, một Hashtable, tùy lựa chọn. Mỗi loại có những lợi thế và sự đánh đổi riêng. Nhưng đến một lúc nào đó, client của bạn sẽ muốn duyệt qua những đối tượng đó, và khi đó, bạn sẽ tự tay cài đặt thuật toán duyệt của mình, bạn có muốn như vậy? Chúng tôi hy vọng không! Điều đó không chuyên nghiệp. Khi xem qua phần Iterator pattern, bạn sẽ thấy cách bạn có thể cho phép client của mình duyệt qua các đối tượng mà không cần phải xem qua cách bạn lưu trữ các đối tượng. Bạn cũng sẽ học cách tạo ra một số bộ super collection có thể bỏ qua một số cấu trúc dữ liệu trong một ràng buộc duy nhất. Và nếu điều đó chưa đủ, bạn cũng sẽ học được một hoặc hai thứ về trách nhiệm của đối tượng.
Chúng ta đang trên một chuỗi các đóng gói: chúng tôi đã đóng gói việc tạo đối tượng (Factory method), đóng gói lời gọi phương thức (Command), đóng gói giao diện phức tạo (Facade pattern), vịt, pizza … tiếp theo sẽ là gì? Với Template method pattern, chúng tôi sẽ tiếp tục đóng gói các phần của thuật toán để các lớp con có thể tự móc (hook) vào một tính toán bất cứ lúc nào chúng muốn. Chúng tôi thậm chí sẽ tìm hiểu về một nguyên tắc thiết kế lấy cảm hứng từ Hollywood.
Bây giờ chúng ta sẽ xem xét một mô hình có thể thay đổi giao diện, nhưng cho một lý do khác: để đơn giản hóa giao diện. Nó được đặt tên một cách khéo léo là Facade Pattern (mặt tiền) vì mẫu này che giấu tất cả sự phức tạp của một hoặc nhiều lớp đằng sau mặt tiền sạch sẽ, thiết kế rõ ràng.
Adapter Pattern và Facade Pattern – Trong chương này, chúng tôi sẽ cố gắng thực hiện những chiến-công-bất-khả-thi như ghép một cái chốt vuông vào một cái lỗ tròn. Hoàn toàn có thể khi chúng ta có các mẫu thiết kế. Bạn nhớ Decorator Pattern chứ? Chúng tôi bọc các đối tượng để cung cấp cho chúng trách nhiệm mới. Bây giờ, chúng tôi sẽ bọc một số đối tượng với một mục đích khác: để làm cho giao diện của chúng trở nên khác đi. Tại sao cần làm điều đó? Khi đó, chúng ta có thể điều chỉnh một thiết kế mong đợi một interface thành một lớp implements một interface khác (Adapter Pattern). Đó chưa phải là tất cả; Trong khi chúng tôi làm việc với nó, chúng tôi sẽ xem xét một mẫu khác bao bọc các đối tượng để đơn giản hóa interface của chúng (Facade Pattern).