Java идиома для определения паттерна вызова, соответствующего CFG - PullRequest
1 голос
/ 08 июля 2011

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

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

public class StaticDocument {
  private StringBuilder doc;
  protected StaticDocument() {}
  protected void nonNestedA() { doc.append("<A/>"); }
  protected void nonNestedB() { doc.append("<B/>"); }
  public String toString() { return doc.toString(); }
}

Используя StaticDocument в качестве базового класса, можно определять документы, используя только Java для описания их абстрактной структуры. Пример документа с последовательным составом элементов A и B: -

public class ExampleDocument extends StaticDocument
{
  public ExampleDocument()
  {
    nonNestedA();
    nonNestedB();
    nonNestedA();
  }
}

Ситуация становится немного сложнее, когда мы пытаемся расширить этот подход, чтобы охватить рекурсивно вкладываемый элемент .... В C ++ я мог бы использовать защищенный внутренний класс StaticDocument для определения элемента Z - затем использовать блоки в ExampleDocument, чтобы убедиться, что каждый соответствует - с использованием идиома / шаблон RAII. В C # я мог бы использовать интерфейс IDisposable и «использовать» для аналогичной цели. Другая возможность состоит в том, чтобы передать аргумент методу nestedZ и сделать так, чтобы этот аргумент инкапсулировал то, что нужно выполнить, чтобы сгенерировать документ, окруженный элементом Z ... но это несколько громоздко - особенно потому, что Java (6) не поддерживает ни делегаты, ни Лямбда-выражения изначально.

[В сторону: я знаю о таких инструментах, как JaxB для XML ... и о том, что я могу встраивать XML-файлы в jar-файлы, но здесь вопрос призван охватить более сложную задачу - XML ​​просто демонстрирует ту же абстрактную структуру .]

Итак ... наконец ... вопрос: существует ли в сообществе Java консенсус относительно наилучшего способа решения подобных проблем? Задачи состоят в том, чтобы минимизировать посторонние промежуточные объекты во время создания документов - и сделать так, чтобы документы были как компактными, так и «естественными» (то есть легко распознаваемыми при сопоставлении с соответствующим документом XML).

Мне было бы интересно услышать некоторые экспертные мнения ... и / или ссылки на соответствующие статьи.

Ответы [ 2 ]

2 голосов
/ 08 июля 2011

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

Это примеры использует их для создания тестовых объектов данных.Но это относится и к вашему сценарию.

0 голосов
/ 08 июля 2011

Как насчет того, чтобы просто взять ваши доменные объекты и сериализовать их в XML, используя XStream ?

...