Как реорганизовать тесно связанные классы?

Question

Я пытаюсь реорганизовать большое тесно связанное приложение и пытаюсь сделать его более удобным и гибким.

У меня есть много модульных тестов, поэтому я надеюсь реорганизовать шаг за шагом.

Какой дизайн & Рефакторинг шаблонов следует рассмотреть при реализации/применении для выполнения этой задачи?

я могу думать о некоторых:

• Extract Interface
• Extract Method
• Dependency Injection

Также вы можете поделиться своим собственным опытом и передовой практикой для такого рода рефакторинга работы.

UPDATE

Я несу этот рефакторинг because of the reasons explained in this question. В принципе, я не могу внедрить систему плагинов, не извлекая пару интерфейсов, и эти интерфейсы сильно связаны, что требует отдельного приложения в 40 + DLL, чтобы просто компилировать без циклической ссылки.

Answer 1

Спасибо за все ответы. После того, как я изо всех сил старался изо всех сил, я обнаружил, что лучше всего создавать интерфейсы для всего. Это позволило мне свободно менять дизайн, и я только разбил сборку на день (день, потому что проект был большой, и мне нужно исправить так много ссылок и модульных тестов + некоторый рефакторинг).

После того, как вы извлекли и зафиксировали все интерфейсы, я могу создавать отдельные решения и свободно работать с дизайном.

В основном первое перемещение, я думаю, нужно переместить все на интерфейсы, а затем попытаться избавиться от внутренних зависимостей.

Answer 2

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

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

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

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

Answer 3

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

Answer 4

Это большой вопрос, и в ответ на него можно написать целую книгу. К счастью, у кого-то уже есть. Возьмите себе копию Эффективно работайте с устаревшим кодом от Michael Feathers. Это целая книга, посвященная ответе на ваш вопрос.

Это действительно хорошая книга.Я бы определенно поставил его там с Код Завершить, Дизайн шаблонов и Pragmatic Programmer на список книг, которые должны быть в библиотеке каждого разработчика.

Answer 5

Все вышеперечисленное, а затем некоторые. Но прежде чем вы начнете что-либо из этого, я думаю о большой картине. Определите разделы вашей программы (пакеты, проекты и т. Д.), А затем планируйте перемещение функциональных возможностей в соответствующий пакет. Затем, когда все, где логически, должно быть начато использование интерфейса экстракта, инъекции зависимостей и заводских методов для начала удаления пакетов.

Answer 6

Некоторые большие советы от Phlip: Refactor the Low-hanging Fruit

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