Design Principles

* Đây là bài dịch lại theo ý hiểu của tác giả từ trang oodesign.

Software Design Principles là gì?

Software Design Principles đưa ra một tập các qui tắc, giúp chúng ta có thể tránh được việc sử dụng một design không tốt. Các nguyên lý thiết kế, được Robert Martin nhắc tới trong quyển sách: ‘Agile Software Development: Principles, Parttens, and Practices’. Theo Martin, có 3 nhân tố quan trọng cần phải tránh để thiết kế của bạn không trở nên tồi tệ:
– Rigidity (sự cứng nhắc) – Sẽ không dễ dàng gì để thay đổi bởi mỗi thay đổi đều ảnh hưởng tới quá nhiều phần khác của hệ thống.
– Fragility (tính dễ vỡ) – Khi bạn thay đổi ở đâu đó, hệ thống dễ bị đổ vỡ ở những phần không mong muốn.
– Immobility (Tính bất biến) – Rất khó để tái sử dụng trong ứng dụng khác.

Nguyên tắc đóng mở

Những thực thể của phần mềm như lớp, module và hàm cần mở để tái sử dụng nhưng đóng đối với việc chỉnh sửa

Đây là nguyên tắc chung trong lập trình. Khi viết một class, bạn hãy làm cho nó dễ dàng để tái sử dụng. Hoặc khi cần phát triển bổ sung, bạn không cần phải thay đổi, mà mở rộng chúng. Nguyên lý này được áp dụng với các modules, các packages, hay libraries. Nếu bạn có một thư viện với rất nhiều class, và vì một lí do gì đó khiến bạn muốn mở rộng thư viện đó. Khi đó, bạn sẽ thấy một loạt các lí do để bạn mở rộng thư viện mà không muốn thay đổi source code đang có (tính tương thích với các app sử dụng version cũ, tests …). Điều này lí giải lí do tại sao chúng ta phải đảm bảo nguyên lí đóng – mở

Khi nói tới các classes, nguyên lý này có thể được đảm bảo bởi việc sư dụng các lớp trìu tượng và các lớp con để thực hiện chương trình. Điều này sẽ bắt buộc các lớp con sẽ mở rộng từ các lớp trìu tượng thay vì thay đổi chúng. Một số mẫu điển hình của nguyên lý này là mẫu Template (mẫu có sẵn) và mẫu Strategy (chiến lược)

Nguyên lý phụ thuộc đảo ngược

Các modules dù là high-level hay low-level thì cũng nên kế thừa từ lớp trừu tượng
Các lớp trừu tượng không nên phụ thuộc vào các lớp cụ thể. Mà ngược lại, mọi đối tượng cụ thể đều phải phụ thuộc vào các đối tượng trừu tượng

Nguyên lý này chỉ ra rằng chúng ta nên tách biệt high-level modules và low-level modules, bằng cách sử dụng lớp trìu tượng. Và các thực thể nên kế thừa từ lớp trìu tượng, không nên có chiều ngược lại.

Theo cách truyền thống, khi một module cần kế thừa 1 module khác, khi khởi tạo nó chúng ta có một biến tham chiếu tới module kia. Điều này gắn kết 2 module này với nhau rất chặt.

Nhưng nếu chúng ta sử dụng nguyên lý này ngay từ đầu, việc thay đổi có thể dễ dàng thực hiện bằng cách thay đổi module phụ thuộc. Có một số frameworks cụ thể cho nguyên lý này được biết tới với cái tên Inversion of Control Container.

Nguyên lý tách biệt giao diện

Khách hàng không nên bị buộc phải phụ thuộc vào những giao diện mà họ không sử dụng.

Nguyên lý này nhắc nhở chúng ta quan tâm hơn tới giao diện người dùng. Chúng ta cần suy nghĩ về phía người dùng thật họ sẽ cần những chức năng gì ở trang giao diện đó. Vì lý do đơn giản chúng ta vẫn phải làm chức năng không cần ở đó. Những giao diện như vậy gọi là fat interfaces (bị phình, béo), và bị rác. Chúng ta nên tránh việc đó.

Nguyên lý đơn nhiệm

Mỗi một class chỉ nên có duy nhất 1 lý do để thay đổi chúng.

Nguyên lý này chỉ ra rằng, mỗi một class chỉ nên thay đổi nếu và chỉ nếu với duy nhất một lý do nào đó. Nếu chúng ta có 2 lý do để thay đổi class, chúng ta nên chia chúng ra thành hai class riêng biệt. Một class chỉ nên đảm nhiệm một vai trò, một chức năng, để về sau nếu cần thay đổi, chúng ta sẽ chỉ phải thay đổi duy nhất ở 1 chỗ, trong class đảm nhận vai trò đó. Nếu class đó đảm nhận nhiều vai trò, chúng ta có thể gây ảnh hưởng tới chức năng của những class khác.

Nguyên lý này lần đầu được giới thiệu bởi Tom DeMarco vào năm 1979, trong cuốn Structured Analysis and Systems Specification. Theo ông lý do duy nhất để thay đổi class chính là chức năng mà class đó đảm nhiệm.

Nguyên lý thay đổi Liskov

Những kiểu kế thừa bắt buộc phải có khả năng thay thế những kiểu cơ bản của chúng.

Nguyên lý này là sự mở rộng của nguyên lý đóng mở, chúng ta tuyệt đối không thay đổi lớp các lớp cơ bản khi tạo ra những lớp kế thừa mới. Lớp kế thừa phải hoàn toàn có khả năng thay thế lớp cơ bản mà không phải thay đổi gì trong source code.

Nguyên lý này được đưa ra bởi Barbara Liskov vào năm 1987 trong cuộc hội thảo về Ứng dụng và ngôn ngữ lập trình hệ thống hướng đổi tượng.