Giới thiệu
Trong thiết kế phần mềm, nguyên tắc Đóng/Mở (Open/Closed Principle) thuộc nhóm nguyên tắc SOLID luôn là một chủ đề nóng. Nó giúp lập trình viên tạo ra những hệ thống dễ bảo trì và mở rộng. Tuy nhiên, việc triển khai nguyên tắc này không phải lúc nào cũng dễ dàng, và trong thực tế, nhiều lập trình viên vẫn chưa thực sự nắm vững ý nghĩa của nó.
Câu chuyện từ thực tế
Tôi đã nghe hai lần kể về một incident ở một công ty lớn tại Việt Nam, nơi một Solution Architect từ chối một pull request vì lý do rằng các thay đổi không tuân thủ nguyên tắc Đóng/Mở. Theo câu chuyện, có một yêu cầu từ khách hàng, và lập trình viên đã sửa đổi một lớp có sẵn để giải quyết yêu cầu đó. Tuy nhiên, Solution Architect cho rằng việc sửa đổi lớp đã tồn tại là điều không được phép, mà thay vào đó, nên mở rộng lớp đó.
Tại sao tôi không tin vào câu chuyện này?
Có những lý do sau đây khiến tôi nghi ngờ về tính xác thực của câu chuyện:
-
Từ chối dựa trên lý thuyết: Việc từ chối một pull request chỉ dựa trên lý thuyết Đóng/Mở là thiếu thuyết phục. Chúng ta cần có những giải pháp cụ thể để chứng minh.
-
Tính thực tiễn: Khả năng mở rộng một chức năng không phải lúc nào cũng có sẵn. Trong nhiều trường hợp, mã nguồn thực tế không đáp ứng được yêu cầu mở rộng mà không cần thay đổi.
-
Tính phụ thuộc giữa các nguyên tắc SOLID: Nguyên tắc Đóng/Mở không đứng một mình. Các nguyên tắc khác cũng phải được xem xét cùng nhau. Để đạt được Đóng/Mở, bạn cần hiểu và áp dụng cả các nguyên tắc khác trong SOLID.
Ý Nghĩa Thực Sự của Đóng/Mở
Thiết kế là yếu tố quyết định
Nguyên tắc Đóng/Mở là một nguyên tắc liên quan đến thiết kế phần mềm. Điều này có nghĩa là việc đạt được tính mở có thể được quyết định ngay từ khâu thiết kế, chứ không phải trong quá trình lập trình khi nhận yêu cầu từ khách hàng. Nếu bạn có thể mở rộng mã nguồn cũ, đó là nhờ vào thiết kế tốt của người lập trình trước.
Tính đơn nhiệm trong thay đổi mã nguồn
Một phiên bản mã nguồn không thể được coi là mở rộng nếu các thay đổi không giữ nguyên nguyên tắc Đơn nhiệm (Single Responsibility Principle). Cần coi xét kỹ lưỡng từng yêu cầu thay đổi và xác định xem chúng có độc lập hay không.
Ví dụ cụ thể
Xét một quy trình xử lý đơn hàng:
- Đơn hàng
- Tính tổng giá
- Nhập thông tin khách
- Chọn phương thức thanh toán
- Thanh toán
- Giao hàng
Nếu có thêm yêu cầu:
- Tính giảm giá/khuyến mãi.
- Chọn phương thức giao hàng.
Yêu cầu thứ hai có thể tách rời và thêm vào, trong khi yêu cầu thứ nhất lại phức tạp và có thể đòi hỏi thay đổi lớn đối với mã nguồn.
Kết luận
Trong thực tế, có thể bạn không mấy chú trọng đến nguyên tắc Đóng/Mở, nhưng việc hiểu và áp dụng nó có thể giúp bạn viết những mã nguồn dễ bảo trì hơn. Đừng ngần ngại sửa đổi mã nguồn khi cần thiết, chỉ cần bạn luôn nhớ rằng tính mở rộng đích thực thường bắt đầu từ việc thiết kế tốt ngay từ đầu. Tôi hi vọng rằng những chia sẻ này sẽ giúp bạn có cái nhìn rõ ràng hơn về nguyên tắc Đóng/Mở trong thiết kế phần mềm.
source: viblo
