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

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

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

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

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

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

Это тоже очень хорошая книга. Я определенно включил бы ее вместе с Code Complete, Шаблоны проектирования и Pragmatic Programmer в список книг, которые должны быть в арсенале каждого разработчика. библиотека.

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

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

Несколько полезных советов от Phlip: Рефакторинг низко висящих фруктов

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

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

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

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