Один из вариантов — поместить обратные вызовы делегата XML и/или методы построения данных в объект, который будет создан в результате синтаксического анализа этого конкретного типа xml. Это поместило бы определение объекта вместе со знанием того, как создать его из xml или фрагментов данных в одном месте. Попытка поместить всю логику синтаксического анализа для всех типов в один метод делегата слишком усложняет этот один класс делегата и разделяет знания о каждом из типов, с которыми вы работаете.
Единственная проблема с этим подходом — составные объекты. Например, если у вас есть объект исполнителя, объект альбома, содержащий исполнителя, и вызов, который получает список исполнителей. Один из подходов состоит в том, чтобы составной объект, анализирующий который, откладывался на этот другой класс объектов (возможно, с вашим собственным протоколом). Например, объект альбома анализируется и попадает в элемент «исполнитель». Таким образом, он знает, что нужно выделить исполнителя, и когда он попадет в фрагменты данных из обратных вызовов делегата (пока он не достигнет близкого элемента исполнителя), он будет продолжать вызывать методы вашего протокола, вставляя данные. Это откладывает знание того, что делать с этим фрагментом. данных в класс, который определяет этот объект. Для класса, который обрабатывает список исполнителей, он сделал бы это n раз, создавая список. Вызов, который получает одного исполнителя (делегаты в классе исполнителя), по-прежнему будет вызывать эти методы заполнения блоков данных насыщения для объекта исполнителя.
Наконец, построение объектов по мере анализа XML, если все сделано правильно, может иметь преимущество в виде экономии памяти и повышения производительности. В отличие от буферизации полной строки xml, создание полного XML DOM может использовать больше памяти, что также может быть медленнее для пользователя. Так что подумайте и о производительности.
person
bryanmac
schedule
08.09.2012
