Как провести рефакторинг тесно связанных классов? - PullRequest
3 голосов
/ 27 апреля 2009

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

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

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

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

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

ОБНОВЛЕНИЕ

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

Ответы [ 6 ]

8 голосов
/ 27 апреля 2009

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

Это действительно хорошая книга. Я определенно поставил бы это с Code Complete , Design Patterns и Pragmatic Programmer в списке книг, которые должны быть в библиотеке каждого разработчика. 1011 *

8 голосов
/ 27 апреля 2009

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

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

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

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

5 голосов
/ 27 апреля 2009

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

2 голосов
/ 27 апреля 2009

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

0 голосов
/ 30 апреля 2009

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

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

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

0 голосов
/ 27 апреля 2009

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

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

...