Принцип open/closed, по-видимому, касается предотвращения регрессий в объекте или методе. Учитывая, что ваш код покрыт испытаниями, потому что вы практикуете BDD, это кажется излишним требованием. Кроме того, он, похоже, создает дополнительную сложность, требуя расширения на уровне API, а не на уровне языка.Существуют ли какие-либо преимущества для использования принципа открытого/закрытого при использовании BDD?
Абсолютно все выгоды. Фактически, два принципала (BDD и Open/Closed) предназначены для разных целей. BDD призван возглавить процесс разработки, и именно там ощущаются его преимущества (сокращение сроков, создание более качественного кода и т. Д.). Open/Closed предназначен для разработки в процессе разработки, но помогает в обслуживании.
Преимущества BDD легко понять. Более короткие сроки для первоначального развития означают меньшую стоимость проекта в целом, не так ли? Неправильно. Основываясь на The 60/60 Rule, 60% стоимости проекта - от его сохранения (и 60% этой стоимости зависит от изменений требований после развертывания). Поэтому, хотя полезно экономить деньги на начальном этапе разработки, большая экономия должна быть обеспечена при обслуживании.
И вот там, где принципал Open/Closed окупится. Следуя этому принципу, вы сэкономите много времени на обслуживание (так как вам не нужно отслеживать сломанные тесты Unit, потому что вы меняете функциональность метода).
И принцип Open/Closed не связан с предотвращением регрессий, поскольку он предотвращает изменение API, что почти невозможно не отставать. Если вы заметили, хорошие API никогда не будут меняться. Они могут быть расширены. Части могут быть устаревшими. Но вы никогда не увидите setFoo(string bar) изменить на setFoo(int bar). Это то, что Open/Closed существует для предотвращения ...
Я понимаю, почему вы не хотите, чтобы ваш апи изменился. Где я не уверен, это когда вы хотите добавить к api класса. Я не уверен, правильно ли я открывал/закрывал, но кажется, что вы не должны менять класс вообще, как только он закрыт. Если это так, то кажется, что он противоречит другим принципам, таким как не оптимизировать ранний и эмерджентный дизайн с помощью рефакторинга. Возможно, я ошибаюсь, и это относится только к закрытию отдельных методов? – opsb
@opsb: Я думаю, вы правильно это сделали. Применительно к классам, принцип open/closed говорит: «Вы знаете, как добавить новые методы в класс, и он по-прежнему полностью обратно совместим со всем существующим кодом? Ну, не делайте этого. Вместо этого создайте новый класс со всеми функциональными возможностями старого класса и т. д. Этот новый класс может быть подклассом старого класса, если он помогает ». Вы также можете попытаться предвидеть необходимость изменений через инъекцию зависимостей, стратегический паттерн и любые другие подобные трюки, о которых вы можете думать, что сделает ваши классы более гибкими, не изменяя их. –
Это подклассификация, чтобы добавить новую функциональность, которая делает меня неудобным. Учитывая, что ваш api не изменился, и вы только добавляете функциональность, я не вижу преимущества фрагментации того, что должно быть одним классом в двух классах, т. Е. Учитывая, что вы не обеспечивали никаких регрессий в вашем существующем api, какое оправдание есть для использования конструкции, которая в любой другой точке процесса будет считаться неполной. – opsb
Существует множество гибких методов, которые не применяются к API, которые вы опубликовали вне своей собственной организации, потому что просто невозможно обновить весь код, который зависит на интерфейсе, который вы меняете. open/closed более подходит для такого рода вещей, я думаю, или вообще для интерфейсов (если они есть), которые вы разрабатываете для обеспечения стабильности. –