Анализ влияния на подкласс

Question

Я модифицировал переопределенный метод подкласса. Чтобы определить влияние изменений, я рассмотрел все возможные сценарии и протестировал их.

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

Есть ли надежный или программный способ узнать о последствиях? Например, если это не переопределенный метод, я могу просто «Найти все экземпляры» или даже использовать grep, чтобы найти, куда он вызывается. Есть ли аналогичная мера для переопределенных методов? Или это просто неудобство полиморфизма?

Answer 1

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

Я знаю, что есть люди, которые категорически против любого ОО по этой самой причине. Фактически это также стало причиной того, что методы .Net, в отличие от Java, по умолчанию НЕ могут быть переопределены.

Если вы ищете в Google инкапсуляцию разрывов полиморфизма или инкапсуляцию разрывов наследования, вы найдете множество обсуждений на эту тему.

Answer 2

Я не знаю всех подробностей, поэтому трудно предположить, но какое влияние вы ожидаете от изменения?

Пока вы не меняете сигнатуру метода, просто проверяйте поведение класса в изоляции. Это ключевой принцип модульного тестирования. Поскольку вы упоминаете точки останова, я предполагаю, что вы тестируете вручную в отладчике. Модульное тестирование может избавить вас от всего этого; это стоит посмотреть.

Если метод изменяет глобальное состояние или класс тесно связан с другими классами, изолированное тестирование может быть затруднено. См. Добавление модульных тестов к устаревшему коду .

В качестве другой опции, ReSharper имеет функцию Find Usages, которая может находить вызывающие методы и, необязательно, базовые классы. Также есть возможность найти переопределяющие методы в Расширенном поиске пользователей.

Answer 3

Быстрое предложение было бы переименовать функцию. Компилятор быстро сообщит вам о том, что нужно посмотреть и, возможно, изменить. Очевидно, это полностью зависит от того, как вы контролируете весь возможный код клиента.