Như tôi đã giải thích, nguyên tắc mở / đóng nói rằng một lần viết mã không nên được sửa đổi (ngoài sửa lỗi). Nhưng nếu quy tắc kinh doanh của tôi thay đổi, tôi có nên sửa đổi mã thực hiện những thay đổi đó không? Tôi nghi ngờ tôi không hiểu gì về nguyên tắc này vì nó không có ý nghĩa với tôi.
Câu trả lời:
Đây có lẽ là khó nhất trong các nguyên tắc vững chắc để giải thích. Để tôi thử. Hãy tưởng tượng bạn đã viết một lớp Hóa đơn hoạt động hoàn hảo và không có lỗi. Nó tạo ra một bản PDF của một hóa đơn.
Sau đó, một người nào đó nói rằng họ muốn có một hóa đơn HTML có liên kết trong đó. Bạn không thay đổi bất kỳ mã nào trong Hóa đơn để đáp ứng yêu cầu này. Thay vào đó, bạn tạo một lớp khác, HTMLInvoice, đó là những gì họ muốn bây giờ. Bạn tận dụng sự kế thừa để bạn không phải viết nhiều mã trùng lặp trong HTMLInvoice.
Mã cũ đã sử dụng Hóa đơn cũ không bị hỏng hoặc thực sự bị ảnh hưởng theo bất kỳ cách nào. Mã mới có thể sử dụng HTMLInvoice. (Nếu bạn cũng thực hiện Thay thế Liskov , L of solid, bạn có thể cung cấp các phiên bản HTMLInvoice cho mã hiện tại đang mong đợi các phiên bản Hóa đơn.) Mọi người đều sống hạnh phúc mãi mãi.
Hóa đơn được đóng để sửa đổi, mở để mở rộng. Và bạn phải viết Hóa đơn đúng trước để làm việc này, btw.
Bạn đã đọc bài viết Nguyên tắc đóng mở của những người bạn của chú Bob tại ObjectMentor chưa? Tôi nghĩ đó là một trong những lời giải thích tốt hơn ngoài kia.
Có rất nhiều heuristic liên quan đến thiết kế hướng đối tượng. Ví dụ, tất cả các biến thành viên nên được sử dụng là riêng tư, hoặc các biến toàn cầu có thể tránh được, hoặc sử dụng nhận dạng loại thời gian chạy (RTTI) là nguy hiểm. Nguồn gốc của các heuristic này là gì? Điều gì làm cho chúng đúng? Họ luôn luôn đúng? Cột này nghiên cứu nguyên tắc thiết kế làm cơ sở cho các heuristic này - nguyên tắc đóng mở.
Như Ivar Jacobson đã nói: tất cả các hệ thống thay đổi trong vòng đời của chúng. Điều này phải được lưu ý khi phát triển các hệ thống dự kiến sẽ tồn tại lâu hơn phiên bản đầu tiên. Làm thế nào chúng ta có thể tạo ra các thiết kế ổn định khi đối mặt với sự thay đổi và nó sẽ tồn tại lâu hơn phiên bản đầu tiên? Bertrand Meyer đã cho chúng tôi hướng dẫn từ năm 1988 khi ông đưa ra nguyên tắc đóng mở nổi tiếng hiện nay. Để diễn giải anh ta:
PHẦN MỀM PHẦN MỀM (LỚP, MÔ HÌNH, CHỨC NĂNG, ETC.) NÊN ĐƯỢC MỞ RA KHAI THÁC, NHƯNG ĐÓNG CỬA ĐỂ SỬA ĐỔI.
Khi một thay đổi duy nhất đối với chương trình dẫn đến một loạt các thay đổi đối với các mô đun phụ thuộc, chương trình đó thể hiện các thuộc tính không mong muốn mà chúng ta đã liên kết với thiết kế của Bad bad. Chương trình trở nên mong manh, cứng nhắc, không thể đoán trước và không thể sử dụng được. Nguyên tắc đóng mở tấn công điều này theo một cách rất đơn giản. Nó nói rằng bạn nên thiết kế các mô-đun không bao giờ thay đổi . Khi yêu cầu thay đổi, bạn mở rộng hành vi của các mô-đun đó bằng cách thêm mã mới, không phải bằng cách thay đổi mã cũ đã hoạt động.
Sự miêu tả
Các mô-đun tuân thủ nguyên tắc đóng mở có hai thuộc tính chính.
- Họ đang mở rộng để mở rộng.
Điều này có nghĩa là hành vi của mô-đun có thể được mở rộng. Rằng chúng ta có thể làm cho mô-đun hoạt động theo những cách mới và khác nhau khi các yêu cầu của ứng dụng thay đổi hoặc để đáp ứng nhu cầu của các ứng dụng mới.- Họ đang đóng cửa để sửa đổi.
Mã nguồn của một mô-đun như vậy là bất khả xâm phạm. Không ai được phép thực hiện thay đổi mã nguồn cho nó.Có vẻ như hai thuộc tính này là bất hòa với nhau. Cách thông thường để mở rộng hành vi của một mô-đun là thay đổi mô-đun đó. Một mô-đun không thể thay đổi thường được cho là có hành vi cố định. Làm thế nào hai thuộc tính đối lập này có thể được giải quyết?
Trừu tượng là chìa khóa ...
Câu trả lời của Kate Gregory là rất tốt, nhưng hãy xem xét một tình huống khác trong đó một yêu cầu mới có thể được thỏa mãn bằng một thay đổi tương đối nhỏ trong Invoicelớp hiện có . Ví dụ: giả sử một trường mới phải được thêm vào Hóa đơn PDF. Theo OCP, chúng ta vẫn nên tạo một lớp con mới, ngay cả khi trường mới có thể được thêm vào trong triển khai hiện có bằng cách thay đổi một vài dòng mã.
Theo hiểu biết của tôi, OCP phản ánh thực tế của thập niên 80 và đầu thập niên 90, nơi các dự án thường không sử dụng kiểm soát phiên bản, ít có các thử nghiệm hồi quy tự động hoặc lợi ích của các công cụ tái cấu trúc tinh vi. OCP là một nỗ lực để tránh nguy cơ phá vỡ mã đã được kiểm tra thủ công và đưa vào sản xuất. Ngày nay, chúng ta có những cách tốt hơn để quản lý rủi ro phá vỡ phần mềm hoạt động (cụ thể là hệ thống kiểm soát phiên bản, TDD và kiểm tra tự động và các công cụ tái cấu trúc).
Cá nhân tôi nghĩ rằng nguyên tắc này nên được thực hiện với một chút muối. Mã là hữu cơ, doanh nghiệp thay đổi và mã thay đổi theo nhu cầu của một doanh nghiệp khi thời gian tiếp tục.
Tôi cảm thấy rất khó khăn để hiểu rằng sự trừu tượng là chìa khóa. Điều gì xảy ra nếu sự trừu tượng ban đầu là sai? Nếu chức năng kinh doanh đã thay đổi đáng kể thì sao?
Nguyên tắc này về cơ bản đảm bảo rằng các ý định và hành vi GỐC của thiết kế không bao giờ phải thay đổi. Điều đó có thể hoạt động cho những người có API công khai và khách hàng của họ gặp khó khăn trong việc theo kịp các bản phát hành mới và một số trường hợp khác. Tuy nhiên, nếu một công ty sở hữu TẤT CẢ mã, thì tôi thách thức nguyên tắc này.
Có phạm vi kiểm tra tốt về mã của bạn sẽ giúp việc tái cấu trúc cơ sở mã của bạn trở nên dễ dàng. Điều đó có nghĩa là không sao khi hiểu sai - các bài kiểm tra của bạn sẽ giúp hướng dẫn bạn thiết kế tốt hơn.
Nói rằng, nếu không có bất kỳ thử nghiệm nào, thì nguyên tắc này là âm thanh.