5. Một thực thể (Entity) / Một nhiệm vụ

Estimated reading: 5 minutes 310 views

Tóm tắt

Hãy tập trung vào một việc tại một thời điểm: Ưu tiên giao cho mỗi thực thể (biến, lớp, hàm, không gian tên, module, thư viện) một nhiệm vụ được xác định rõ ràng. Khi một thực thể phát triển, phạm vi nhiệm vụ của nó tăng lên một cách tự nhiên, nhưng nhiệm vụ (mục đích) của nó không được phân tán.

Thảo luận

Người ta nói rằng một ý tưởng kinh doanh tốt có thể được giải thích chỉ bằng một câu. Tương tự như vậy, mỗi thực thể trong chương trình chỉ nên có một mục đích rõ ràng.

Thông thường một thực thể mang nhiều mục đích sẽ khó sử dụng hơn. Những thực thể như vậy không chỉ gây quá tải tri thức (việc học và hiểu những chức năng, mục đích của thực thể sẽ tốn nhiều thời gian, công sức hơn), mà còn tăng độ phức tạp của mã code, tăng số lượng bug. Chúng được sinh ra (thường cũng không có lý do chính đáng) cũng cồng kềnh hơn, gây khó khăn trong việc sử dụng và tái sử dụng. Cho dù dưới mục đích gì đi chăng nữa, giao diện (interface) của thực thể cũng không thể tự nhiên. Các tính năng của thực thể sẽ chồng chéo lên nhau, các mục đích sử dụng cũng trở nên không rõ ràng.

Những thực thể phụ trách nhiều công việc khác nhau (mà không có điểm chung) sẽ gây khó dễ trong thiết kế và sử dụng. “Đa nhiệm” thường ám chỉ “Đa nhân cách” (một tổ hợp hành vi và trạng thái có thể xảy ra). Hãy luôn ghi nhớ ưu tiên các hàm một nhiệm vụ ngắn gọn (Mục 39), các lớp một mục đích nhỏ và các module gắn kết với ranh giới rõ ràng.

Hãy xây dựng các bản trừu tượng hoá cấp cao từ các bản trừu tượng hoá cấp thấp hơn. Không sử dụng các bản trừu tượng hoá cấp thấp để xây dựng một bản trừu tượng hoá cấp thấp khác với qui mô lớn hơn. Việc tổng hợp một hành vi phức tạp từ một số hành vi đơn giản sẽ dễ dàng hơn so với làm ngược lại.

Ví dụ

Ví dụ 1: Hàm realloc()

				
					void *realloc(void *ptr, size_t size)

Trong lập trình C tiêu chuẩn, hàm realloc là một ví dụ khét tiếng về thiết kế tồi. Nó phải làm quá nhiều thứ: Cấp phát bộ nhớ nếu tham số con trỏ là NULL, giải phóng bộ nhớ nếu tham số kích thước là 0, nếu có thể sẽ phân bổ lại bộ nhớ với địa chỉ hiện tại, nếu không thể sẽ cấp phát lại bộ nhớ ở một địa chỉ khác. Một hàm không dễ dàng mở rộng! Nó được coi là một ví dụ thất bại kinh điển khi thiết kế quá thiển cận.

Ví dụ 2: basic_string

Trong lập trình C++ tiêu chuẩn, std::basic_string là một ví dụ nổi tiếng không kém về thiết kế lớp đơn khối. Nó đã trở thành một lớp cồng kềnh bởi có quá nhiều tính năng “tốt muốn có” đã được thêm vào, nhưng lại không hoàn toàn trở thành một container, một mặt chưa quyết định được trở thành lặp phần tử (iteration) hay lập chỉ mục (indexing), một mặt sao chép vô cớ nhiều thuật toán tiêu chuẩn trong khi để lại ít không gian cho khả năng mở rộng (Ví dụ của Mục 44).

Tham khảo

[HenneyO2a] • [HenneyO2b] • [McConnell93] §10.5 • [StroustrupOO] §3.8, §4.9.4, §23.4.3.1 • [SutterOO] §10, §12, §19, §23 • [SutterO2] §1 • [SutterO4] §37-40

Link