Лучшее место для начала развязки объектов

Question

Это вопрос C #, но на самом деле он может не зависеть от языка

Я унаследовал большую объектную модель (более 100 типов) с иерархией объектов, которые «владеют» 0..n другими типизированными объектами, которые имеют общую базу (где существует «относительно» иерархия строгих типов) .

Я хочу начать разъединение этих объектов через наследование, чтобы собрать систему на основе IoC, чтобы начать реализовывать некоторые модульные тесты с большей глубиной, чем в настоящее время.

С чего бы начать лучше?

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

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

Я также мог бы начать с базовых объектов (тех, от которых наследуются все объекты), которые запустили бы процесс в логической точке, но почти наверняка создали бы некомпилируемое приложение, пока мы не получим выгружать все наследования объектов и вызовы функций.

Есть мысли?

Answer 1

если вы можете завершить весь процесс в разумные сроки, начните с основ и пройдитесь по всему; приложение будет сломано, пока вы не закончите

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

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

базовые вопросы:

• сколько времени займет каждый подход?
• будет ли каждая тактика в конечном итоге производить один и тот же окончательный код?
• Насколько важно, чтобы приложения работали во время завершения преобразования?
• Достаточно ли у вас юнит-тестов, чтобы доверять масштабному рефакторингу?

Answer 2

Я бы сказал

• Внимательно посмотрите на существующий дизайн ... сформулируйте подход ... найдите компьютер, чтобы опробовать его. (руководство Кента Бека ... ни одно обсуждение дизайна не должно выходить за рамки того, чем оно было .. 30 минут. Как только вы столкнетесь с барьером, возьмите машину, закодируйте ее и посмотрите, работает ли она.)
• По истечении одного часа (или более по вкусу), если вы чувствуете, что делаете успехи ... продолжайте. Остальное обратно к чертежной доске.

Просто начните ... вместо того, чтобы тратить время BDUF, пытаясь выяснить способ ... все прояснится. Конечно, наличие сети безопасности хороших AT было бы жизненно важно.

Answer 3

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

Answer 4

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

Первой статьей в этой цепочке была "Годин и Мили". «Построение и поддержка иерархий классов на уровне анализа с использованием решеток Галуа» (Google, и вы найдете PDF-файлы), и была целая серия следующих работ (см. статьи, которые цитировали это) по различным трюкам.