Nguồn: https://dotnettutorials.net/lesson/open-closed-principle/

Series: SOLID Design Principles trong C#

• Single Responsibility Principle (SRP) trong C#:
• Open-Closed Principle (OCP) trong C#:

Nguyên lý Mở–Đóng (Open-Closed Principle - OCP) là một trong những nguyên lý thuộc bộ nguyên lý SOLID trong thiết kế hướng đối tượng, được đưa ra bởi Bertrand Meyer.

🔸 OCB phát biểu rằng:

Các thực thể phần mềm (như module, lớp, hàm, v.v.) nên được mở để mở rộng nhưng đóng để sửa đổi.

Nguyên lý này khuyến khích việc bạn nên có khả năng thêm chức năng mới vào một thành phần phần mềm mà không cần thay đổi mã nguồn hiện có.

Tại sao điều này lại quan trọng?

Giả sử chúng ta đã phát triển xong một lớp/module/hàm và nó đã được kiểm thử đơn vị (unit test) đầy đủ. Nếu chúng ta thay đổi mã nguồn của nó, có thể sẽ gây ảnh hưởng đến các chức năng hiện tại hoặc làm hỏng những phần đã hoạt động ổn định.

Nói một cách đơn giản:

Chúng ta nên phát triển một lớp/module/hàm sao cho hành vi của nó có thể được mở rộng mà không cần chỉnh sửa mã nguồn của nó.

Thay vì chỉnh sửa hàm/mã gốc, chúng ta nên sử dụng tính chất như đa hình (polymorphism) hoặc các kỹ thuật khác để thêm chức năng mới thông qua việc viết mã mới, chứ không phải chỉnh sửa mã cũ.

Hướng dẫn triển khai Open-Closed Principle (OCP) trong C#

Cách đơn giản nhất để áp dụng Open-Closed Principle (OCP) trong C# là:

• Thêm các chức năng mới bằng cách tạo các lớp dẫn xuất (derived classes) mới, và các lớp này sẽ kế thừa từ một lớp cơ sở (base class) ban đầu.

Một cách khác là:

• Cho phép client truy cập lớp gốc thông qua một giao diện trừu tượng (abstract interface).

Nguyên tắc thực hiện:

Khi có sự thay đổi yêu cầu hoặc xuất hiện một yêu cầu mới, thay vì chỉnh sửa trực tiếp mã nguồn hiện tại, ta nên:

✅ Tạo một lớp dẫn xuất mới

❌ Không chỉnh sửa lớp gốc đã tồn tại

Điều này giúp bảo vệ các chức năng hiện tại, tránh làm hỏng những phần đã hoạt động ổn định, đồng thời cho phép mở rộng hệ thống một cách linh hoạt và an toàn.

Chúng ta sẽ làm gì tiếp theo?

1. Trước tiên, ta sẽ xem một ví dụ không tuân theo OCP, để hiểu các vấn đề phát sinh nếu không áp dụng nguyên lý này.
2. Sau đó, ta sẽ xem lại chính ví dụ đó, nhưng được viết theo đúng nguyên lý OCP trong C#, giúp bạn hiểu rõ hơn cách áp dụng nguyên lý này trong thực tế.

Ví dụ minh họa ĐỂ HIỂU Open-Closed Principle (OCP) bằng C#

Hãy cùng xem xét đoạn mã sau để hiểu vấn đề:

Giả sử chúng ta có một lớp tên là Invoice, trong đó có phương thức GetInvoiceDiscount() dùng để tính toán chiết khấu dựa trên loại hóa đơn (Invoice Type).

Hiện tại, hệ thống chỉ có hai loại hóa đơn:

• Final Invoice (Hóa đơn chính thức)
• Proposed Invoice (Hóa đơn đề xuất)

Vì vậy, trong phương thức GetInvoiceDiscount(), chúng ta sử dụng cấu trúc if-else để xử lý logic dựa trên loại hóa đơn.

Vấn đề là gì?

Ngày mai, nếu có thêm một loại hóa đơn mới (ví dụ: "InvoiceType.RecurringInvoice"), chúng ta sẽ phải quay lại và chỉnh sửa phương thức GetInvoiceDiscount() để thêm một khối if mới vào mã nguồn.

➡️ Điều này vi phạm Nguyên lý Mở–Đóng, vì:

• Lớp Invoice không đóng với việc sửa đổi, do chúng ta phải chỉnh sửa mã hiện tại mỗi khi có thay đổi yêu cầu.
• Chúng ta đang mở rộng bằng cách sửa đổi, thay vì mở rộng bằng cách thêm mã mới.

Ví dụ KHÔNG tuân theo Open-Closed Principle (OCP) trong C#

namespace SOLID_PRINCIPLES.OCP
{ public class Invoice { public double GetInvoiceDiscount(double amount, InvoiceType invoiceType) { double finalAmount = 0; if (invoiceType == InvoiceType.FinalInvoice) { finalAmount = amount - 100; } else if (invoiceType == InvoiceType.ProposedInvoice) { finalAmount = amount - 50; } return finalAmount; } } public enum InvoiceType { FinalInvoice, ProposedInvoice };
}

Vấn đề với ví dụ trên:

Trong ví dụ này, nếu bạn muốn thêm một loại hóa đơn mới, ví dụ: RecurringInvoice, thì bạn buộc phải:

• Sửa đổi phương thức GetInvoiceDiscount() bằng cách thêm một khối else if mới.
• Điều đó đồng nghĩa với việc bạn phải chỉnh sửa mã nguồn lớp Invoice hiện có.

Tại sao điều này vi phạm Open-Closed Principle (OCP) ?

1. Lớp Invoice không đóng với việc sửa đổi — mỗi khi có yêu cầu mới, bạn phải sửa phương thức GetInvoiceDiscount.
2. Việc sửa mã cũ có thể làm hỏng logic hiện tại nếu không kiểm tra kỹ.
3. Bạn phải kiểm thử lại toàn bộ chức năng hiện có để đảm bảo rằng mọi thứ vẫn hoạt động đúng, kể cả khi bạn chỉ thêm một loại hóa đơn nhỏ.

➡️ Đây là lý do tại sao ta nên áp dụng OCP — bằng cách tách riêng các logic theo từng loại hóa đơn, sử dụng đa hình (polymorphism) để thêm tính năng mới mà không đụng vào mã cũ.

Những vấn đề khi KHÔNG tuân theo Open-Closed Principle (OCP) trong C#

Nếu bạn không áp dụng Nguyên lý Mở–Đóng (Open-Closed Principle) trong quá trình phát triển ứng dụng, thì bạn có thể gặp phải những vấn đề nghiêm trọng sau đây:

1. Phải kiểm thử lại toàn bộ hệ thống

   Nếu bạn thêm logic mới trực tiếp vào một lớp hoặc hàm hiện có, bạn – với tư cách là lập trình viên – sẽ phải kiểm tra lại toàn bộ chức năng của ứng dụng, bao gồm cả phần cũ và phần mới.

2. Phải thông báo cho đội QA (Kiểm thử chất lượng)

   Khi có sự thay đổi mã nguồn, bạn cần chủ động thông báo cho nhóm QA để họ chuẩn bị:

   • Kiểm thử hồi quy (Regression Testing): đảm bảo tính năng cũ vẫn chạy tốt.
   • Kiểm thử tính năng mới: xác minh logic mới được thêm vào hoạt động đúng.

3. Vi phạm Nguyên lý Trách nhiệm Duy nhất (SRP)

   Khi bạn thêm quá nhiều logic vào một lớp/module, lớp đó sẽ gánh nhiều trách nhiệm, dẫn đến việc vi phạm SRP – một nguyên lý quan trọng khác trong SOLID.

4. Bảo trì phức tạp, khó mở rộng

   Nếu tất cả logic đều nằm trong một lớp duy nhất, việc bảo trì, sửa lỗi, hoặc mở rộng sẽ trở nên khó khăn và dễ phát sinh lỗi.

Áp dụng Open-Closed Principle (OCP) trong C#

Theo Open-Closed Principle:

✅ Chúng ta nên mở rộng (Extension) thay vì sửa đổi (Modification)

Cách áp dụng vào ví dụ hóa đơn:

Trong ví dụ trước, mỗi khi cần thêm loại hóa đơn mới, bạn phải chỉnh sửa phương thức GetInvoiceDiscount() — việc này vi phạm OCP.

✅ Cách đúng là: khi có loại hóa đơn mới, hãy tạo một lớp mới kế thừa từ lớp cơ sở, thay vì sửa lớp hiện tại.

Khi đó, các chức năng hiện có không bị thay đổi, bạn chỉ cần kiểm thử lớp mới – không cần kiểm tra lại toàn bộ hệ thống.

Ví dụ CÓ tuân theo Open-Closed Principle (OCP) trong C#

Đoạn mã dưới đây là một ví dụ chuẩn về OCP trong C#. Ở đây, chúng ta có:

• Một lớp cơ sở Invoice
• Ba lớp kế thừa: FinalInvoice, ProposedInvoice, và RecurringInvoice
• Mỗi lớp con có thể ghi đè (override) phương thức GetInvoiceDiscount() theo logic riêng.

namespace SOLID_PRINCIPLES.OCP
{ public class Invoice { public virtual double GetInvoiceDiscount(double amount) { return amount - 10; } } public class FinalInvoice : Invoice { public override double GetInvoiceDiscount(double amount) { return base.GetInvoiceDiscount(amount) - 50; } } public class ProposedInvoice : Invoice { public override double GetInvoiceDiscount(double amount) { return base.GetInvoiceDiscount(amount) - 40; } } public class RecurringInvoice : Invoice { public override double GetInvoiceDiscount(double amount) { return base.GetInvoiceDiscount(amount) - 30; } }
}

Phân tích theo OCP:

• Invoice là lớp đóng với sửa đổi – bạn không cần sửa đổi lớp này khi thêm loại hóa đơn mới.
• Nhưng Invoice vẫn mở để mở rộng, vì bạn có thể tạo lớp mới kế thừa và ghi đè logic nếu cần.
• Khi có loại hóa đơn mới (ví dụ SpecialInvoice), bạn chỉ cần tạo lớp kế thừa, mà không đụng vào mã cũ.

Kiểm thử chức năng – Tuân theo Open-Closed Principle (OCP)

Bạn có thể kiểm tra hoạt động của các lớp Invoice bằng cách cập nhật phương thức Main() trong lớp Program như sau:

using System;
namespace SOLID_PRINCIPLES.OCP
{ class Program { static void Main(string[] args) { Console.WriteLine("Invoice Amount: 10000"); Invoice FInvoice = new FinalInvoice(); double FInvoiceAmount = FInvoice.GetInvoiceDiscount(10000); Console.WriteLine($"Final Invoive : {FInvoiceAmount}"); Invoice PInvoice = new ProposedInvoice(); double PInvoiceAmount = PInvoice.GetInvoiceDiscount(10000); Console.WriteLine($"Proposed Invoive : {PInvoiceAmount}"); Invoice RInvoice = new RecurringInvoice(); double RInvoiceAmount = RInvoice.GetInvoiceDiscount(10000); Console.WriteLine($"Recurring Invoive : {RInvoiceAmount}"); Console.ReadKey(); } }
}

Ouput:

Invoice Amount: 10000
Final Invoice : 9940
Proposed Invoice : 9950
Recurring Invoice : 9960

Phân tích logic:

Ưu điểm của Open-Closed Principle (OCP) trong C#

Áp dụng nguyên lý OCP trong C# mang lại nhiều lợi ích quan trọng cho quá trình phát triển phần mềm. Dưới đây là các điểm nổi bật:

1. 🐞 Giảm thiểu rủi ro lỗi (Bug)
   • Khi thêm tính năng mới, bạn không cần chỉnh sửa mã cũ đã được kiểm thử kỹ.
   • Nhờ đó, bạn giảm nguy cơ tạo ra lỗi ở phần mã đang hoạt động ổn định.
   • Tăng độ tin cậy và ổn định cho toàn bộ hệ thống.
2. ♻️ Tăng khả năng tái sử dụng (Reusability)
   • Các lớp/module được thiết kế theo OCP có thể tái sử dụng dễ dàng ở các vị trí khác nhau trong dự án hoặc thậm chí là dự án khác.
   • Bạn chỉ cần kế thừa lớp gốc và mở rộng chức năng thay vì viết lại từ đầu.
3. 🛠️ Dễ bảo trì (Maintainability)
   • Khi thay đổi yêu cầu, bạn chỉ cần thêm lớp mới chứ không phải sửa lớp hiện tại.
   • Giúp giữ cho mã sạch sẽ, gọn gàng, tránh tích lũy lỗi (technical debt).
   • Dễ hiểu hơn cho các lập trình viên khác hoặc nhóm QA kiểm thử.
4. ⚙️ Tận dụng hiệu quả các khái niệm lập trình hướng đối tượng (OOP)
   • OCP khuyến khích dùng kế thừa, giao diện (interface) và đa hình (polymorphism).
   • Nhờ đó, kiến trúc phần mềm trở nên linh hoạt và có khả năng mở rộng cao.
   • Cho phép bạn thay đổi hành vi tại runtime, rất hữu ích trong các hệ thống lớn/phức tạp.

Tóm lại:

Open-Closed Principle = An toàn khi mở rộng + Không ảnh hưởng mã cũ + Mạnh mẽ về kiến trúc OOP