Các nguyên tắc SOLID, YAGNI, KISS, DRY trong lập trình

Nguyên tắc được đúc kết từ những kinh nghiệm đã được kiểm nghiệm bằng xương và máu. Vì thế, để công việc của bạn trở nên dễ dàng hơn. Hãy áp dụng nguyên tắc.

Trong lập trình cũng tương tự như vậy. Chúng ta cùng tìm hiểu một số nguyên tắc cơ bản.

Nguyên tắc SOLID:

1. Single responsibility principle

Nội dung: Một class chỉ nên giữ 1 trách nhiệm duy nhất (Chỉ có thể sửa đổi class với 1 lý do duy nhất)

VD:

public class DuLieu()
{
   public void DocDuLieu();
   public void TruyenDuLieu();
   public void XuatDuLieu();
}

Class này giữ tới 3 trách nhiệm: Đọc dữ liệu từ DB, xử lý dữ liệu, in kết quả. Do đó, chỉ cần ta thay đổi DB, thay đổi cách xuất kết quả, … ta sẽ phải sửa đổi class này. Càng về sau class sẽ càng phình to ra.

--> Theo đúng nguyên lý, ta phải tách class này ra làm 3 class riêng. Tuy số lượng class nhiều hơn những việc sửa chữa sẽ đơn giản hơn, class ngắn hơn nên cũng ít bug hơn như sau:

public class DocDuLieu() { }

public class TruyenDuLieu() { }

public class XuatDuLieu() { }

2. Open/closed principle

Nội dung: Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó (open for extension but closed for modification)

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ũ.

3. Liskov Substitution Principle

Nội dung: Trong một chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình

VD: Hãy tưởng tượng bạn có 1 class cha ChóThật.

Các Class con là ChóCỏ, ChóPhúQuốc, ChóBecGie thì chương trình chạy bình thường. Nhưng nếu Bạn viết Class ChóBecGieNhựa thì khi kế thừa class cha Chó sẽ gây lỗi vì ChóNhựa không phải thực thể sống. Điều này vi phạm nguyên lý.

4. Interface Segregation Principle

Nội dung: Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể

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.

5. Dependency inversion principle

Nội dung:

Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả 2 nên phụ thuộc vào abstraction.

Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại. ( Các class giao tiếp với nhau thông qua interface, không phải thông qua implementation.)

VD:

Sạc iPhone type C có thể sạc 5s, 6, 6s... Chúng ta có thể thay đổi điện thoại dễ dàng. 

Ở đây, interface chính là sạc iPhone, implementation là các dòng iPhone. Ta có thể dễ dàng sạc vì ổ điện chỉ quan tâm đến interface (dây sạc), không quan tâm tới implementation.

Nguyên tắc YAGNI:

YAGNI = You Aren’t Gonna Need It

Nguyên tắc này là dự án của bạn đang làm thì chỉ cần tập trung xây dựng chức năng quyết vấn đề ở thời điểm hiện tại, vấn đề mà khách hàng cần giải quyết, không cần lãng phí thời gian vào một chức năng "Có thể sử dụng đến".

=>  Đừng tự vẽ việc cho mình.

Nguyên tắc KISS

KISS = Keep It Simple Stupid

KISS có nhiều biến thể khác nhau như "Keep It Short and Simple", "Keep It Simple and Straightforward" và "Keep It Small and Simple".

Tóm lại, hàm ý của nó vẫn hướng về một sự đơn giản và rõ ràng trong mọi vấn đề. Và như vậy, sự đơn giản là mục đích trọng tâm trong thiết kế, còn những cái phức tạp không cần thiết thì nên tránh.

Trong lập trình, KISS nghĩa là hãy làm cho mọi thứ (mã lệnh của bạn) trở nên đơn giản và dễ nhìn hơn. Hãy chia nhỏ vấn đề và giải quyết từng cái. Hãy để số lượng dòng code của một lớp hay phương thức ở con số hàng chục thôi.

Đừng viết những lớp hay phương thức theo kiểu tổng hợp hay lẫn lộn (tất cả trong một), hãy để mọi thứ thật đơn giản để bạn luôn có thể hiểu được, và kết hợp chúng với nhau để giải quyết được các bài toán lớn.

Nguyên tắc DRY:

DRY = Don’t Repeat Yourself

Nguyên tắc này có nghĩa là đừng có viết lặp bất kỳ lại một đoạn mã nào mà hãy đóng gói nó thành phương thức riêng. Đến khi cần thì chỉ cần gọi tên nó ra.

Nguyên tắc này nó giống như tính chất kế thừa trong lập trình hướng đối tượng OOP mà chúng ta đã quá quen thuộc rồi.

Trên đây là một số nguyên tắc nổi tiếng trong lập trình mình muốn chia sẻ với các bạn. Phần SOLID có lẽ sẽ hơi khó hiểu nếu bạn lần đầu nghe đến, nhưng dần dần, khi áp vào vấn đề thực tế các bạn sẽ hiểu ngay thôi.