Chương 10: State Pattern – Trạng thái vạn vật

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.

Tiếp tục đọc →

Chương 9: Iterator Pattern và Composite Pattern (P2)

Ở 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.

Tiếp tục đọc →

Chương 9: Iterator Pattern và Composite Pattern (P1)

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.

Tiếp tục đọc →

Chương 8: Template Method Pattern

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.

Tiếp tục đọc →

Chương 7: Adapter Pattern và Facade Pattern – Trở nên thích nghi (P2)

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.

Tiếp tục đọc →

Chương 7: Adapter Pattern và Facade Pattern – Trở nên thích nghi (P1)

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).

Tiếp tục đọc →

Chương 6: Command Pattern – Đóng gói yêu cầu

Command Pattern – Đóng gói yêu cầu. Trong chương này, chúng tôi đưa việc đóng gói lên một cấp độ hoàn toàn mới: đóng gói lời gọi phương thức. Đúng vậy, bằng cách đóng gói lời gọi phương thức, Command pattern có thể kết tinh các phần xử lý để đối tượng gọi xử lý không cần phải lo lắng về cách thực hiện, nó chỉ sử dụng phương thức của chúng ta để hoàn thành nó. Với Command pattern, chúng ta cũng có thể thực hiện một số điều với các cách gọi phương thức được đóng gói này, như lưu chúng để ghi log hoặc tái sử dụng chúng để thực hiện undo trong code của chúng ta.

Tiếp tục đọc →