Tìm hiểu về nguyên lý SOLID

Tram Ho

SOLID là từ viết tắt của 5 nguyên tắt thiết kế hướng đối tượng (OOP). Một project áp dụng những nguyên lý này sẽ có code dễ đọc, dễ test, rõ ràng. Và hơn hết nó giúp dev dễ maintain và phát triển project rất nhiều, cụ thể như sau:

  • S: Single-responsibility principle
  • O: Open-closed principle
  • L: Liskov substitution principle
  • I: Interface segregation principle
  • D: Dependency Inversion Principle

Ok, bây giờ cùng mình tìm hiểu rõ hơn nguyên lý này nhé!

S — Single Responsibility Principle(S.R.P)

Một class chỉ nên xử lý duy nhất cho một công việc (Chỉ có thể sửa class cho một lý do duy nhất).

  • Nếu code vi phạm nguyên lý này – tức là 1 class xử lý nhiều nhiệm vụ:

Class OrdersReport đang thực hiện 3 công việc: lấy thông tin Order, đọc dữ liệu Order từ DB và hiển thị Order. Khi thay đổi DB hay thay đổi cách get dữ liệu,…, bắt buộc ta phải sửa class. Càng về sau class sẽ càng phình to ra, dẫn đến khó maintain, khó hiểu, khó clear các chức năng.

Khi requirements thay đổi, code tái cấu trúc, có nghĩa các class được sửa đổi. Nếu một lớp xử lý càng nhiều nhiệm vụ , thì càng có nhiều yêu cầu thay đổi, và những thay đổi đó sẽ càng khó thực hiện. Vậy nên ta cần tách class ra thành các class riêng để xử lý từng công việc.

Ở ví dụ này ta cần tách ra như sau

O — Open-Closed Principle

Bạn có thể mở rộng class mà không sửa đổi bên trong nó.

  • Nguyên tắt này là nền tảng để xây dựng code dễ maintain và tái sử dụng.

Ở nguyên tắt này khi có yêu cầu mới, ta có thể tạo một class mới mở rộng (bằng cách kế thừa hoặc sở hữu) class cũ mà không sửa đến class cũ.
Hãy cùng mình xem ví dụ sau:

Khi muốn tính diện tích của hình tròn, nếu ta thay đổi method calculate trong class CostManager. Nó sẽ phá vỡ nguyên lý Open-closed. Theo nguyên lý này, chúng ta không thể sửa đổi mà cần mở rộng. Vậy làm thế nào để giải quyết vấn đề này, hãy theo dõi đoạn code bên dưới:

Bây giờ có thể tính diện tích mà không sửa đổi class CostManager.

L — Liskov Substitution Principle

Nguyên lý này nói rằng, objects phải thay thế được bằng instance của subtype mà không thay đổi việc chạy đúng của chức năng hệ thống.

Hãy tưởng tượng bạn quản lý hai loại máy pha cà phê. Theo kế hoạch người dùng, chúng tôi sẽ sử dụng máy pha cà phê cơ bản hoặc cao cấp, sự khác biệt duy nhất là máy cao cấp tạo ra cà phê vani tốt hơn máy cơ bản. Hành vi chương trình chính phải giống nhau cho cả hai máy

I — Interface Segregation Principle

Không nên sử dụng Interface lớn mà thay vào đó tách ra thành các Interface nhỏ hơn, với các mục đích cụ thể.

Nguyên tắt này cho phép phát triển các Interface cụ thể thay vì các Interface chung chung.

Hãy tưởng tượng, tương lai bạn sẽ tạo một FutureCar có thể chạy và bay 😄 (tưởng tượng cao tí), như sau:

Vấn đề chính ở đây bạn có thể thấy, đó là Car và Airplane có những phương thức trên nhưng mà không sử dụng lại được. Giải pháp là chia VehicleInterface thành hai Interface cụ thể hơn, chỉ được sử dụng khi cần thiết, như sau:

D — Dependency Inversion Principle

A. Các modules cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả hai nên phụ thuộc vào abstractions.
B. Abstractions không nên phụ thuộc vào chi tiết. Thông tin chi tiết nên phụ thuộc vào abstractions.
Robert C. Martin

Nguyên tắc này cho phép lập trình viên viết code tách rời và dễ dàng tái sử dụng nhiều nơi.

Hãy xét ví dụ sau:

Trong trường hợp này, class UserDB phụ thuộc trực tiếp từ cơ sở dữ liệu MySQL. Điều đó có nghĩa là nếu chúng ta thay đổi công cụ cơ sở dữ liệu đang sử dụng, chúng ta cần viết lại class này và việc này làm vi phạm nguyên tắc Open-Closed.

Giải pháp là phát triển abstraction kết nối cơ sở dữ liệu:

Lợi ích

Tuân theo các Nguyên tắc SOLID cho chúng ta nhiều lợi ích, chúng làm cho hệ thống của chúng ta có thể tái sử dụng, tái cấu trúc, dễ dàng maintain, mở rộng, phát triển và hơn thế nữa.

Trên đây là bài viết tìm hiểu về nguyên lý SOLID mình tham khảo từ các bài viết:
SOLID Principles made easy của tác giả Dhurim Kelmendi
SOLID Principles Simplified with Examples in PHP của tác giả Ideneal.

Hy vọng bài viết sẽ giúp bạn cải thiện chất lượng trong quá trình code hơn.

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo