SOLID – 5 nguyên lý “vàng” giúp viết code sạch và dễ bảo trì

Trong hành trình phát triển phần mềm, chắc hẳn bạn đã từng gặp phải những đoạn code dài, khó hiểu và rất khó mở rộng hay sửa chữa. Đó là dấu hiệu cho thấy thiết kế phần mềm đang gặp vấn đề.

Để giải quyết điều này, SOLID ra đời – một tập hợp 5 nguyên lý thiết kế hướng đối tượng do Robert C. Martin (Uncle Bob) đề xuất, giúp bạn:

• Viết code sạch, dễ hiểu, dễ mở rộng
• Giảm lỗi, tăng khả năng tái sử dụng
• Dễ dàng test và bảo trì

1. S – Single Responsibility Principle (Nguyên lý trách nhiệm duy nhất):

📌 Ý nghĩa: Một class nên chỉ đảm nhiệm một vai trò cụ thể trong hệ thống. Điều này giúp code dễ đọc, dễ test và ít bị ảnh hưởng dây chuyền khi sửa đổi.

✅ Ví dụ tốt:

// Tách rõ trách nhiệm
class InvoicePrinter {
  print(invoice: Invoice) { /* logic in ra hoá đơn */ }
}

class InvoiceSaver {
  save(invoice: Invoice) { /* logic lưu hoá đơn vào DB */ }
}

❌ Ví dụ xấu:

// Gộp quá nhiều chức năng
class InvoiceHandler {
  print(invoice: Invoice) { ... }
  save(invoice: Invoice) { ... }
  sendEmail(invoice: Invoice) { ... }
}

2. O – Open/Closed Principle (Mở để mở rộng, đóng để chỉnh sửa)

"Các thực thể phần mềm nên mở để mở rộng, nhưng đóng để thay đổi."

📌 Ý nghĩa: Thay vì sửa code cũ, hãy thiết kế sao cho có thể mở rộng tính năng mà không ảnh hưởng đến phần đang hoạt động ổn định.

✅ Ví dụ tốt:

interface PaymentMethod {
  pay(amount: number): void;
}

class CreditCard implements PaymentMethod {
  pay(amount: number) { console.log("Paid by credit card"); }
}

class Paypal implements PaymentMethod {
  pay(amount: number) { console.log("Paid by Paypal"); }
}

function checkout(method: PaymentMethod) {
  method.pay(100);
}

➡️ Nếu muốn thêm phương thức khác như Momo, chỉ cần tạo class mới mà không sửa code checkout.

3. L – Liskov Substitution Principle (Nguyên lý thay thế Liskov)

"Class con có thể thay thế class cha mà không làm sai logic."

📌 Ý nghĩa: Các class con không nên thay đổi hành vi mong đợi của class cha.

❌ Ví dụ xấu:

class Rectangle {
  setWidth(w: number) { ... }
  setHeight(h: number) { ... }
}

class Square extends Rectangle {
  setWidth(w: number) {
    this.setHeight(w); // Thay đổi hành vi gốc
  }
}

➡️ Khi bạn dùng Square thay cho Rectangle, bạn có thể nhận được hành vi không mong muốn → vi phạm Liskov.

4. I – Interface Segregation Principle (Nguyên lý phân tách interface)

"Client không nên phụ thuộc vào những interface mà nó không cần."

📌 Ý nghĩa: Thay vì tạo một interface “khổng lồ” chứa mọi thứ, hãy tách thành nhiều interface nhỏ, mỗi interface phục vụ đúng 1 nhu cầu.

❌ Ví dụ xấu:

interface Machine {
  print(): void;
  scan(): void;
  fax(): void;
}

➡️ Máy in chỉ cần print() nhưng vẫn phải implement scan và fax.

✅ Giải pháp:

interface Printer {
  print(): void;
}

interface Scanner {
  scan(): void;
}

5. D – Dependency Inversion Principle (Nguyên lý đảo ngược phụ thuộc)

"Module cấp cao không nên phụ thuộc vào module cấp thấp. Cả hai nên phụ thuộc vào abstraction."

📌 Ý nghĩa: Thay vì để class phụ thuộc trực tiếp vào class khác, hãy để chúng phụ thuộc vào interface hoặc abstraction → giúp code dễ test, dễ thay đổi.

✅ Ví dụ tốt:

interface IMessageService {
  sendMessage(msg: string): void;
}

class EmailService implements IMessageService {
  sendMessage(msg: string) {
    console.log("Send email:", msg);
  }
}

class Notification {
  constructor(private service: IMessageService) {}

  notify() {
    this.service.sendMessage("You have a new message");
  }
}

➡️ Giờ bạn có thể dễ dàng thay thế EmailService bằng SMSService hay PushService mà không cần sửa Notification.

Có thể nói, khi áp dụng đúng SOLID, bạn sẽ thấy hệ thống của mình trở nên dễ mở rộng, dễ test, ít lỗi và dễ bảo trì hơn rất nhiều. Một số tài liệu bạn có thể tham khảo để code trở nên chuyên nghiệp hơn:

• Clean Code – Robert C. Martin
• Clean Architecture – Robert C. Martin
• SOLID principles: https://solidprinciples.com
• Video học SOLID (YouTube): "SOLID Principles Explained – Tech With Tim"