Tìm hiểu về nguyên lý “vàng” SOLID trong lập trình hướng đối tượng

1569

Chắc hẳn tất cả lập trình viên chúng ra khi viết ra những dòng code đều mong muốn rằng những dòng code chúng ta viết ra có thể làm cho mọi người dễ dàng hiểu được và dễ bảo trì. Đặc biệt với dự án đặc thù khách hàng thay đổi yêu cầu liên tục thì việc này lại trở nên rất quan trọng. Chúng ta sẽ cùng tìm hiểu nguyên lý SOLID là gì để có thể viết ra những dòng code dễ hiểu, dễ maintain.

SOLID là tên viết tắt của 5 nguyên lý hợp thành lại bao gồm:

S – Single Responsibility Principle
O – Open/Closed Principle
L – Liskov’s Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

Có thể bạn quan tâm

  67 công cụ hữu ích, thư viện và tài nguyên để tiết kiệm thời gian cho web developer
  Kinh nghiệm xương máu sau 9 tháng làm Kỹ sư phần mềm (Phần 1)

1. Single Responsibility Principle

Nguyên lý đầu tiên, tương ứng với chữ S trong SOLID. Nội dung nguyên lý:

Một class có quá nhiều chức năng cũng sẽ trở nên cồng kềnh và phức tạp. Nếu requirement hay thay đổi, dẫn tới sự thay đổi code. Nếu một class có quá nhiều chức năng, quá cồng kềnh, việc thay đổi code sẽ rất khó khăn, mất nhiều thời gian, còn dễ gây ảnh hưởng tới các module đang hoạt động khác.

Ví dụ:

Class Student có quá nhiều chức năng: chứa thông tin học sinh, format hiển thị thông tin, lưu trữ thông tin. Khi code lớn dần, thêm chức năng nhiều hơn, class Student sẽ bị phình to ra. Chưa kể, nếu như có thêm các class khác như Person, Teacher v…v, đoạn code hiển thị/lưu trữ thông tin sẽ nằm rải rác ở nhiều class dẫn đến khó sửa chữa và nâng cấp.
Để giải quyết, ta chỉ cần tách ra làm nhiều class, mỗi class có một chức năng riêng. Khi cần nâng cấp, sửa chữa, sẽ diễn ra ở từng class, không ảnh hưởng tới các class còn lại.

2. Open/Closed Principle

Nguyên lý thứ hai, tương ứng với chữ O trong SOLID. Nội dung nguyên lý:

Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) không nên sửa đổi class cũ.
Ví dụ:

Dễ thấy nếu trong tương lại ta thêm nhiều class nữa, muốn tính diện tích của nó ta lại phải sửa class Geometry, viết thêm chừng đó hàm if nữa. Sau khi chỉnh sửa, ta phải compile và deploy lại class Geometry.
Sau khi chỉnh sửa lại như sau:

Ta dùng một interface và chuyển hàm tính diện tích vào trong các hình, như vậy khi thêm một lớp mới ta chỉ cần thực thi trong lớp đó mà không ảnh hưởng đến các lớp khác.

Video: Artificial Intelligence driven Mobile Apps

3. Liskov’s Substitution Principle

Nguyên lý thứ ba, tương ứng với chữ L trong SOLID. Nội dung nguyên lý:

Một ví dụ đơn giản là class RecyclerView.Adapter trong android. Lập trình viên có thể dễ dàng extend class này và viết lớp adapter riêng của mình mà không cần phải thay đổi lớp RecyclerView.Adapter đã có sẵn.
Ví dụ ta có một class animal

Nguyên lý chỉ ra ở đây chúng ta có thể thay thể những chỗ đã sử dụng class Animal bằng class Dog hoặc Cat mà không làm chết chương trình. Chúng ta không nên thực thi đoạn code ở lớp con mà khi thay thế lớp cha sẽ làm chết chương trình. Ví dụ

4. Interface Segregation Principle

Nguyên lý thứ tư, tương ứng với chữ I trong SOLID. Nội dung nguyên lý:

Nguyên lý này khá dễ hiểu. Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100 methods. Việc implements sẽ khá cực khổ, ngoài ra còn có thể dư thừa vì 1 class không cần dùng hết 100 method. Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc implement và quản lý sẽ dễ hơn.
Ví dụ trong android:

Nếu chúng ta định nghĩa một interface gộp cả 2

Khi implement interface này ta sẽ phải thêm những method không dùng đến vào, chưa kể khi thêm nhiều chức năng khác interface này sẽ phình to ra, nội dung của nguyên lý này chính là khuyên ta nên tách các interface cho các mục đích cụ thể, tránh việc gộp lại chúng thành 1 interface.

5. Dependency Inversion Principle

Nguyên lý cuối cùng, tương ứng với chữ D trong SOLID. Nội dung nguyên lý:

Ví dụ

6. Kết luận

Như vậy bài viết đã trình bày về 5 nguyên lý để tạo nên SOLID. Hi vọng đã giúp mọi người hiểu được các nguyên lý này để giúp code của mình trở nên “solid” và dễ bảo trì.

Người viết: Dat Nguyen

TopDev via Viblo