Nội dung nguyên lý
Có thể thoải mái mở rộng một module, nhưng hạn chế sửa đổi bên trong module đó (open for extension but closed for modification).
Theo nguyên lý này, một module cần đáp ứng 2 điều kiện sau:
Dễ mở rộng: Có thể dễ dàng nâng cấp, mở rộng, thêm tính năng mới cho một module khi có yêu cầu.
Khó sửa đổi: Hạn chế hoặc cấm việc sửa đổi source code của module sẵn có.
Ví dụ minh họa
Cùng xem đoạn code dưới đây
Ta có 3 class là Square, Circle, Rectangle. Class AreaDisplay tính diện tích các hình này và in ra. Theo code cũ, để tính diện tích, ta cần dùng hàm if để check và ép kiểu object đưa vào, sau đó bắt đầu tính. Dễ thấy nếu trong tương lại ta thêm nhiều class nữa, ta phải sửa class AreaDisplay, 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 AreaDisplay, dài dòng và dễ lỗi.
Áp dụng OCP, code có thể được cải tiến lại như sau:
Ta chuyển module tính diện tích vào mỗi class. Class AreaDisplay chỉ việc in ra. Trong tương lai, khi thêm class mới, ta chỉ việc cho class này kế thừa class Shape ban đầu. Class AreaDisplay có thể in ra diện tích của các class thêm vào mà không cần sửa gì tới source code của nó cả.
Kết luận
Nguyên lý OCP xuất hiện khắp mọi ngóc ngách của ngành lập trình. Một ứng dụng của nguyên lý này là hệ thống plug-in (cho Eclipse, Visual Studio, add-on Chrome). Để thêm các tính năng mới cho phần mềm, ta chỉ việc cài đặt các plug-in này, không cần can thiệp gì đến source code sẵn có.
Nguyên lý này cũng được áp dụng chặt chẽ khi viết các thư viện/framework.
Khi áp dụng nguyên lý này trong thiết kế, ta cần phải xác định được những thứ cần thay đổi, để thiết kế phù hợp với thay đổi đó. Đây là một việc rất rất khó, kể cả với developer lâu năm. Nó đòi hỏi nhiều kinh nghiệm, tầm nhìn và một ít khả năng dự đoán. Còn nếu như lỡ đoán sai những điều cần thay đổi thì sao? Cứ viết code cho chạy trước đã rồi refactor dần dần là được thôi.
Tiếp tục cập nhật ...
