Структура шаблона дизайна кода - PullRequest
2 голосов
/ 15 сентября 2010

У меня есть дилемма, которая нуждается в том, что я долго размышлял, но до сих пор не понял, как эффективно и эффективно кодировать (проектировать) это.

У меня есть объектные данные, которые возвращаются в трех текстовых форматах: JSON, XML, ATOM. В JSON данные могут быть объектом JSON или массивом JSON. XML и ATOM - это xml.

На основе этих 3 форматов мне нужно создавать объекты (скажем, A, B, C, D, E). Я думал о наличии паттерна Builder для генерации этих объектов, поэтому мой конструктор интерфейса:

public interface Builder<T, E, A> { //Where E = Element, A is Element array, this is useful for JSON
   public T create(E element);
   public T[] create(A array);
}

public class ABuilder implements Builder<A, JSON, JSONArray> {
  public A create(JSON json) {...}
  public A[] create(JSONArray array) {...}
}

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

т.е. Я хочу такую ​​функциональность, чтобы я мог сделать

public class Resource {

   public A getA(String formatString) {
      return new Something().createA(formatString); //or something better....
   }
}

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

1 Ответ

2 голосов
/ 16 сентября 2010

Я не уверен на 100%, что понимаю, что вам нужно, но первый шаблон проектирования, который мне пришёл в голову, был Стратегия

с помощью этого простого и элегантного шаблона вы можете реализовать конкретную стратегию для каждой имеющейся у вас реализации (xml, json, atom), а также у вас есть гибкое решение, которое можно легко расширить в будущем для поддержки новых форматов, не нарушая каких-либо существующий код (это принцип Open-Close).

так, у вас будет фабричный метод , который будет обеспечивать метод "Build" / "Get", который будет представлять собой перечисление, представляющее требуемый формат (просто пример, вы можете реализовать любым способом, каким вы хочу), и этот фабричный метод будет использовать стратегию для фактического построения объекта. таким образом, клиент на 100% не знает, как построен объект, и ему даже не нужно знать, в каком он формате.

удачи!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...