Nguyên tắc mở/đóng dường như là về ngăn ngừa các hồi quy trong một đối tượng hoặc phương pháp. Cho rằng mã của bạn được bao phủ bởi các bài kiểm tra vì bạn đang thực hành BDD, điều này dường như là một yêu cầu thừa. Ngoài ra, nó dường như giới thiệu thêm sự phức tạp bằng cách yêu cầu mở rộng ở cấp API chứ không phải cấp độ ngôn ngữ.Có bất kỳ lợi ích nào để tuân thủ nguyên tắc mở/đóng khi sử dụng BDD không?
Hoàn toàn có lợi ích. Trong thực tế, hai hiệu trưởng (BDD và Open/Closed) được thiết kế cho các mục đích khác nhau. BDD được thiết kế để dẫn dắt quá trình phát triển, và đó là nơi mà các lợi ích của nó được cảm nhận (rút ngắn thời hạn, tạo mã chất lượng cao hơn, v.v.). Open/Closed được thiết kế để thực hiện trong quá trình phát triển, nhưng giúp bảo trì.
Lợi ích của BDD dễ nắm bắt. Các mốc thời gian ngắn hơn để phát triển ban đầu có nghĩa là chi phí ít hơn cho toàn bộ dự án, đúng không? Sai rồi. Dựa trên The 60/60 Rule, 60% chi phí của dự án là từ việc duy trì nó (và 60% chi phí đó là từ các yêu cầu thay đổi sau triển khai). Vì vậy, trong khi nó có lợi để tiết kiệm tiền trong giai đoạn phát triển ban đầu, tiết kiệm lớn hơn là phải có trong quá trình bảo trì.
Và đó là trường hợp Người đóng/mở đã thanh toán. Bằng cách làm theo hiệu trưởng đó, bạn sẽ tiết kiệm được rất nhiều thời gian để bảo trì (vì bạn không cần theo dõi các Bài kiểm tra Đơn vị bị hỏng vì bạn thay đổi chức năng của một phương thức).
Và hiệu trưởng mở/đóng không phải là về ngăn ngừa sự hồi quy quá nhiều vì nó ngăn chặn một API thay đổi mà hầu như không thể theo kịp. Nếu bạn nhận thấy, các API tốt không bao giờ thay đổi. Chúng có thể được mở rộng. Các bộ phận có thể không được chấp nhận. Nhưng bạn không bao giờ thấy setFoo(string bar) thay đổi thành setFoo(int bar). Đó là những gì mở/đóng là để ngăn chặn ...
Tôi hiểu tại sao bạn không muốn api của bạn thay đổi. Nơi tôi không chắc chắn là khi bạn muốn thêm vào api của một lớp học. Tôi không chắc chắn nếu tôi đã groked mở/đóng một cách chính xác nhưng có vẻ như đề nghị rằng bạn không nên thay đổi một lớp học ở tất cả một khi nó đóng cửa. Nếu đây là trường hợp sau đó nó cảm thấy như nó xung đột với các nguyên tắc khác như không tối ưu hóa thiết kế sớm và nổi lên thông qua tái cấu trúc. Có lẽ tôi là sai mặc dù và nó chỉ đề cập đến đóng các phương pháp cá nhân? – opsb
@opsb: Tôi nghĩ bạn đã thực hiện chính xác. Áp dụng cho các lớp, nguyên tắc mở/đóng nói, "bạn biết cách bạn có thể thêm các phương thức mới vào một lớp, và nó vẫn hoàn toàn tương thích ngược với tất cả các mã hiện có? Vâng, đừng làm thế. Thay vào đó, hãy tạo một lớp mới với tất cả các chức năng của lớp cũ, cộng thêm. Lớp mới này có thể là một lớp con của lớp cũ nếu nó giúp ". Bạn cũng có thể cố gắng dự đoán nhu cầu thay đổi thông qua tiêm phụ thuộc, mẫu chiến lược và bất kỳ thủ thuật nào khác mà bạn có thể nghĩ rằng điều đó giúp lớp học của bạn trở nên linh hoạt hơn mà không cần phải thay đổi chúng. –
Đó là phân lớp để thêm chức năng mới khiến tôi không thoải mái. Cho rằng api của bạn không thay đổi và bạn chỉ thêm chức năng tôi không thể thấy lợi ích để phân mảnh những gì nên là một lớp duy nhất trên 2 lớp tức là bạn đã đảm bảo không có hồi quy trong api hiện tại của bạn, những gì biện minh là có cho việc sử dụng một thiết kế mà tại bất kỳ điểm nào khác trong quá trình sẽ được coi là kém hơn. – opsb
Có một loạt các kỹ thuật nhanh không áp dụng cho API mà bạn đã xuất bản bên ngoài tổ chức của riêng mình, bởi vì đơn giản là không thể cập nhật tất cả mã phụ thuộc trên giao diện bạn đang thay đổi. mở/đóng là phù hợp hơn với loại điều đó, tôi nghĩ, hoặc nói chung để giao diện (nếu có) mà bạn thiết kế cho lâu dài. –