Как бороться с чудовищными действиями Struts?

Question

Я унаследовал это гигантское унаследованное веб-приложение на Java с помощью Struts 1.2.4. У меня есть конкретный вопрос относительно действий. Большинство страниц имеют ровно одно действие, а методы processExecute () - отвратительные монстры (очень длинные и тонны вложенных операторов if, основанных на параметрах запроса).

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

1. Это правильное направление?
2. Есть ли какой-то промежуточный шаг, который я мог бы предпринять, шаблон, который имеет дело с беспорядком внутри монолитных действий? Может быть, другой шаблон команды внутри действия?

Answer 1

Мой способ борьбы с этим будет:

• не делай все сразу
• всякий раз, когда вы что-то меняете, оставьте это лучше, чем вы нашли
  • замена условных выражений отдельными реализациями Action - это один шаг.
  • Еще лучше: отделите свои реализации от классов Action, чтобы их можно было использовать при изменении каркасов
  • Сохраните вашу новую реализацию Команды абсолютно без ссылок на Struts, используйте ваши новые Действия как Оболочку вокруг этих реализаций.
  • Возможно, вам понадобится предоставить интерфейсы для ваших бланков действий Struts, чтобы передавать их без копирования всех данных. С другой стороны - возможно, вы захотите передать другие объекты, кроме ActionForms, которые обычно представляют собой набор строк (см. Другой вопрос о Struts 1.2 ActionForms )
• начать миграцию деталей на более новую и лучшую технологию. Struts 1.2 был великолепен, когда он вышел, но это определенно не то, что вы хотите поддерживать в вечности. Сейчас есть несколько поколений лучших фреймворков.

Там определенно больше ... Извините, у меня заканчивается время ...

Answer 2

Struts Действия, на мой взгляд, вообще не должны содержать много кода. Они должны просто взаимодействовать напрямую с запросом и ответом - взять некоторые данные из формы или параметра запроса, передать эту информацию на уровень обслуживания, а затем поместить некоторые данные в объект Response или, возможно, сохранить некоторые данные в сеансе пользователя.

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

Это только мой личный опыт.

Answer 3

1. По одному методу за раз
2. Запишите некоторые тестовые случаи, которые вы можете воспроизвести позже. Пример здесь (убедитесь, что в коде проложено как можно больше путей, т. Е. Все жесты пользователя на странице, которые вызывают это действие)
3. Реорганизовать метод, чтобы уменьшить его сложность, создав меньшие методы, которые делают меньшие вещи.
4. Повторно запустите тесты, как вы это делаете

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

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

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

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

Answer 4

Я имел дело с такими вещами раньше. Хороший первый шаг - вставить еще один базовый класс в цепочку наследования между Action и одним из оригинальных чудовищных классов действий (назовем его ClassA). Особенно, если у вас нет времени, чтобы сделать все сразу. Затем вы можете начать вытягивать части функциональности в меньшие параллельные классы действий (ClassB, ClassC). Все, что является общим между исходным ClassA и новыми переработанными классами, может быть перенесено в новый базовый класс. Итак, иерархия теперь выглядит так:

Original Hierarchy:      New Hierarchy:

     Action                   Action
       |                        |
       |                      BaseA
  (old)ClassA                   |
                       +--------+----------+
                       |        |          |
                   ClassB (new)ClassA   ClassC

Answer 5

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

Answer 6

Один длинный метод никогда не подходит, если только это не один оператор switch, где случаи очень короткие (разбор токена или что-то в этом роде).

Вы могли бы по крайней мере реорганизовать длинный метод в меньшие методы с описательными именами.

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

enum Operation {
  ADD, DELETE;
}

...

Operation operation = determineOperation(form);
if (operation == Operation.DELETE) { 
  doDelete(form); 
} else if (operation == Operation.ADD) {
  doAdd(form);
}

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

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

Answer 7

Сложная проблема, но типичная для ранней разработки веб-приложений.

Прежде всего, вам нужно начать думать о том, какая логика представляет собой деловое поведение, какая логика представляет собой «поток» (то есть то, что видит пользователь) и какая логика получает контент для того, что он видит.

Вам не нужно идти по пути заводов и интерфейсов и всего такого; ретроактивная реализация гораздо менее полезна ... но объединяет бизнес-логику и логику извлечения данных в каких-то делегатах ... и оставляет действия в Struts для определения потока страниц на основе успеха / неудачи этой логики.

Оттуда нужно просто занять несколько недель и заточить