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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Если метод изменяет глобальное состояние или если класс тесно связан с другими классами, тестирование в изоляции может быть затруднено. См. Adding unit tests to legacy code.

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