Tổng quan về phân tích và thiết kế hướng đối tượng (OOAD)

Trong bài viết này chúng ta sẽ tiếp cận bằng cách đơn giản những kiến thức về Phân tích và thiết kế hướng đối tượng (OOAD) và những nguyên tắc trong khi thiết kế hướng đối tượng để cùng hiểu và áp dụng vào thực tế. Dù được đưa vào các trường học để giảng dạy, tuy nhiên hầu như các bạn sinh viên đều cảm thấy sợ vì môn học này tương đối khó.

I. Tổng quan về OOAD

OOAD (viết tắt của Object Oriented Analysis and Design) là một kỹ thuật tiếp cận phổ biến dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên bộ các nguyên tắc chung, đó là một tập các hướng dẫn để giúp chúng ta tránh khỏi một thiết kế xấu.

Có 3 đặc điểm quan trọng của 1 thiết kế xấu nên tránh là:

• Cứng nhắc (Rigidity) : Khó thay đổi vì mọi thay đổi đều ảnh hưởng đến quá nhiều các bộ phận khác của hệ thống
• Mong manh (Fragility) : Khi thực hiện một thay đổi, hệ thống có thể đổ vỡ một cách bất ngờ
• Bất động (Immobility) : Khó tái sử dụng trong ứng dụng khác bởi vì nó không thể được gỡ từ các ứng dụng hiện hành.

II. Sơ lược 5 nguyên tắc SOLID trong thiết kế hướng đối tượng

1. Single Responsibility Principle (SRP)

“A class should have only one reason to change”

Một lớp chỉ nên có một lý do để thay đổi, tức là một lớp chỉ nên xử lý một chức năng đơn lẻ, duy nhất thôi. Nếu đặt nhiều chức năng vào trong một lớp sẽ dẫn đến sự phụ thuộc giữa các chức năng với nhau và mặc dù sau đó ta chỉ thay đổi ở một chức năng thì cũng phá vỡ các chức năng còn lại.

2. Open-Closed Principle (OCP)

“Software entities like classes, modules and functions should be open for extension but closed for modifications”

Các lớp, module, chức năng nên dễ dàng Mở (Open) cho việc mở rộng (thêm chức năng mới) và Đóng (Close) cho việc thay đổi.

3. Liskov’s Substitution Principle (LSP)

“Derived types must be completely substitutable for their base types”
Lớp dẫn xuất phải có khả năng thay thế được lớp cha của nó.

4. Interface Segregation Principle (ISP)

“Clients should not be forced to depend upon interfaces that they don’t use”
Chương trình không nên buộc phải cài đặt một interface mà nó không sử dụng đến.

5. Dependency Inversion Principle (DIP)

“High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.”

Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc thông qua lớp trừu tượng. Lớp trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết nên phụ thuộc vào trừu tượng

Ngoài các nguyên tắc SOLID ở trên, còn có các nguyên tắc khác cũng rất hữu ích gồm:

• Don’t Repeat Yourself (DRY) : không viết những đoạn code trùng lặp trong cùng một chương trình mà nên dùng lớp trừu tượng hoặc viết thành phương thức để dùng chung
• Encapsulate Whate Varies : Đóng gói những gì dễ thay đổi
• Favor Composition over Inheritance: Nên dùng Composition hơn là Inheritance
• Programming for Interface, not Implementation: Luôn lập trình cho Interface, không lập trình cho việc cài đặt.
• Delegation principle: Đừng tự mình làm hết mọi thứ, hãy ủy nhiệm nó cho lớp tương ứng
• Strive for loosely coupled designs between objects that interact: Giữ liên kết giữa các đối tượng không quá chặt
• Only talk to your friends: Chỉ trao đổi với bạn bè, không phải với tất cả

Nguồn: https://quyetdo289.wordpress.com/2016/02/03/ooad-tong-quan-ve-phan-tich-va-thiet-ke-huong-doi-tuong/

Các bạn có thể tham khảo các bài viết hay về JavaScript tại đây.

---

Hãy tham gia nhóm Học lập trình để thảo luận thêm về các vấn đề cùng quan tâm.