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

Ответ 1

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

Другие советы:

• Подумайте, прежде чем вытаскивать методы: по каким данным этот метод работает? Какую ответственность он несет?
• Сначала попробуйте сохранить интерфейс класса богов и делегировать вызовы новым выделенным классам. В конце концов, класс богов должен быть чистым фасадом без собственной логики. Затем вы можете сохранить его для удобства или выбросить и начать использовать только новые классы.
• Помогите с помощью Unit Tests: напишите тесты для каждого метода, прежде чем извлекать его, чтобы убедиться, что вы не нарушаете функциональность.

Ответ 2

Я предполагаю, что "объект Бога" означает огромный класс (измеренный в строках кода).

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

Чтобы найти те, которые вы можете найти

• поля/параметры, которые часто используются вместе. Они могут перемещаться в новый класс

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

• примитивные типы (int, String, boolean). Они часто являются ценностными объектами до их выхода. Когда они являются объектами ценности, они часто привлекают методы.

• Посмотрите на использование объекта god. Существуют ли разные методы, используемые разными клиентами? Это могут быть отдельные интерфейсы. Эти intefaces, в свою очередь, могут иметь отдельные реализации.

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

• Тесты: У вас есть (возможно, сгенерированный) исчерпывающий набор тестов, которые вы можете запускать часто. Будьте предельно осторожны с изменениями, которые вы делаете без тестов. Я делаю это, но ограничиваю их такими, как метод extract, который я могу сделать полностью с помощью одного действия IDE.

• Управление версиями: вы хотите иметь контроль версий, который позволяет совершать каждые 2 минуты, не замедляя вас. SVN не работает. Git делает.

• Метод Микадо: Идея метода Микадо - попытаться изменить. Если он отлично работает. Если не принимать во внимание то, что ломается, добавьте их как зависимость от изменения, с которым вы начали. Откат вы меняете. В полученном графике повторите процесс с помощью node, у которого пока нет зависимостей. http://mikadomethod.wordpress.com/book/

Ответ 3

Прежде чем начать: как вы узнали, что класс Бога плох?

или, по крайней мере, как вы измеряете класс Бога?

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

Например: класс с некоторыми дополнительными помощниками, свойствами и встроенными утилитами-методами, является кандидатом на будущий класс в будущем, но он также может быть очень хорошим кодом.

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

Общий совет здесь - использование:

• наследование и микшины,
• делегирование (например: utils файлы, внешние классы, API/фасад),
• класс разделения: добавление подклассов или связанных классов,
• используя хороший шаблон, например S.O.L.I.D,
• развивая в себе искусство рефакторинга,

Ответ 4

Здесь действительно две темы:

• Учитывая класс Бога, как его члены рационально делятся на подмножества? Фундаментальная идея состоит в том, чтобы сгруппировать элементы по концептуальной последовательности и по вынужденным зависимостям. Очевидно, детали этого специфичны для системы, подвергаемой рефакторингу. Результатом является желаемое разделение (набор групп) элементов класса Бога.

• Учитывая желаемый раздел, на самом деле внесение изменений. Это сложно, если кодовая база имеет какой-либо масштаб. Делая это вручную, вы почти вынуждены сохранять класс God, в то время как вы изменяете его методы доступа, чтобы вместо этого вызывать новые классы, сформированные из разделов. И, конечно, вам нужно тестировать, тестировать, тестировать, потому что при внесении этих изменений вручную легко ошибиться. Когда все доступы к классу Бога исчезли, вы можете, наконец, удалить его. Это звучит великолепно в теории, но это занимает много времени, если вы сталкиваетесь с тысячами модулей компиляции, и вы должны заставить членов команды прекратить добавлять доступ к интерфейсу Бога, пока вы делаете это. Однако можно применить автоматизированные инструменты рефакторинга для реализации этого; с помощью такого инструмента вы указываете раздел на инструмент, а затем надежно изменяете кодовую базу. Наша DMS может реализовать эти классы рефакторинга Бога и использовалась для таких изменений в системах с 3000 единицами компиляции.