принцип открыт-закрыт - рефакторинг для создания базового класса на основе новых функций

Я думаю, вы можете взглянуть на это с двух точек зрения: существующие требования и новые требования.

Если существующие требования не покрывают потребности в таких изменениях, я бы сказал, что на основе этих требований LabTest не нарушает OCP.

С новыми требованиями вам нужно добавить функциональность, которая не подходит для реализации LabTest. Добавление его в OCP нарушит SRP. Теперь требования создают новый вектор изменений, который заставит вас провести рефакторинг LabTest, чтобы сохранить его OCP. Если вам не удастся провести рефакторинг LabTest, это приведет к нарушению SRP и OCP. При рефакторинге помните о новом векторе изменений в любых классах, которые вы создаете или изменяете.

У этих классов много общего, поэтому имеет смысл иметь базовый класс.

Я думаю, вы нарушаете SRP. В конце концов, если каждый класс выполняет одну задачу, как два или более могут быть такими похожими? Если есть задача, которую они оба выполняют одинаково, то это отдельная задача и должна выполняться другим классом.

Итак, я бы сказал, сначала выполните рефакторинг LabTest на его составные части (надеюсь, у вас есть модульные тесты!). Затем, когда вы придете писать RadiologyTest, EKGTest они могут повторно использовать те части, которые имеют для них смысл. Это также известно как композиция по наследованию.

Но что бы вы ни делали, используйте интерфейсы для этих классов в клиенте. Не заставляйте тех, кто следит за вами, использовать ваши базовые классы для добавления расширений.

Я могу обжечься за этот ответ, но все равно рискну. На мой взгляд (IMO), OCP нельзя придерживаться в чистом смысле слова, как другие принципы, такие как SRP, DIP или ISP.

Если требования изменяются таким образом, что вы должны изменить ответственность класса, чтобы соответствовать их представлению модели предметной области, тогда мы должны изменить этот класс.

IMO, OCP не дает нам повторно использовать код для отслеживания эволюции системы.

Пожалуйста, поправьте меня, если я ошибаюсь.

Обновление: после дальнейших исследований я подумал вот о чем: допустим, я автоматизировал тестирование как на уровне единицы, так и на уровне интеграции, а затем, ИМО, мы должны перепроектировать всю систему, чтобы она соответствовала новой модели, OCP. здесь за дверью. ИМО, цель эволюции системы всегда состоит в том, чтобы избежать взлома (не изменять класс LabTest и соответствующую таблицу БД, чтобы не нарушать старый код [не нарушать OCP], и использовать LabTest для хранения общих данных EKGTest и использовать LabTest внутри EKGTest или EKGTest, унаследованный от LabTest, будет взломом, IMO) будет и для того, чтобы система представляла свою модель как можно точнее.

Я думаю, что принцип «открытость-закрытость» (в любом случае изложенный дядей Бобом в сравнении с Бертраном Мейерсом) не в том, чтобы никогда не изменять классы (если программное обеспечение никогда не собиралось менять, это могло бы также быть аппаратным).

& в вашем собственном случае, я не думаю, что вы нарушаете OCP, поскольку вы упомянули, что все ваши способы использования вашего класса зависят от абстракции LabTest, а не от реализации RadiologyTest.

Из вводной статьи дяди Боба у него есть пример DrawAllShapes класса, который, если он был разработан в OCP, не нужно менять каждый раз, когда в систему добавляется новый подкласс Shape. Что касается того, на каком уровне вы его применяете, дядя Боб говорит, что ...

Должно быть понятно, что ни одна значимая программа не может быть закрыта на 100%. Например, подумайте, что случилось бы с функцией DrawAllShapes из листинга 2, если бы мы решили, что все Circles должны быть нарисованы перед любым Squares. Функция DrawAllShapes не закрывается от подобных изменений. В общем, каким бы «закрытым» ни был модуль, всегда будет какое-то изменение, от которого он не закрыт.

Поскольку закрытие не может быть полным, оно должно быть стратегическим. То есть дизайнер должен выбрать виды изменений, от которых следует закрыть свой дизайн.

Я бы не стал читать «закрыто для модификации» как «без рефакторинга», более того, вы должны проектировать свои классы таким образом, чтобы другие классы не могли вносить изменения, которые могут повлиять на вас - например, применение базового объектно-ориентированного подхода - инкапсуляция через геттеры / сеттеры и частные переменные-члены.