2013-03-06 3 views
1

У меня есть класс, который определяет преобразование из AST (абстрактное дерево синтаксиса) в промежуточное представление (IR) на основе шаблона посетителя. Обе модели представляют собой модели EMF, поэтому посетитель расширяет абстрактный класс EMF Switch модели AST (я использую Xtext для определения AST). Посетитель имеет состояние как несколько частных полей для создаваемого им IR (отображение локальных переменных, текущая процедура, переводимая, список блоков для добавления инструкций и т. Д.).Параметры рефакторинга для посетителя Java

Посетитель реализует методы для всех конструкций AST, поэтому это происходит от caseExpressionInteger до caseStatementIf, в общей сложности 21 общедоступный метод «case». У меня также есть 22 частных метода, и, за исключением нескольких методов, которые являются просто помощниками, большинство из них работают с государством.

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

Вот что я подумал:

  • Есть несколько классов продолжают друг друга, а «главный» класс каждого класса добавив реализацию некоторых методов посетителя
  • имеют несколько независимых классов, и что делегаты этих классов, передавая их состояние в отдельный класс
  • Смешайте два подхода (некоторые делегата, некоторые INHERIT)

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

+0

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

+0

Извините, я отредактировал оригинальный вопрос, чтобы добавить дополнительную информацию о модели и посетителя, это должно помочь :) –

ответ

2

Из вашего описания кажется, что класс посетителей довольно сплочен (что хорошо :)). Единственное, что я могу предложить, это перевести логику перевода в IR Builder и быть посетителем, который отправляет команды строителю (т. Е. Роль директора). В этом случае строитель будет иметь внутреннее состояние, таким образом, используя эту нагрузку у посетителя.

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

HTH

+0

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

1

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

Звучит как другой класс, которому будет делегирована часть работы.

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

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

+0

Благодарим вас за ответ. Извините, я не знал, какой уровень детализации мне нужно предоставить, я отредактировал исходный вопрос. –

Смежные вопросы