Какой шаблон проектирования для сериализации объекта Builder vs Visitor? - PullRequest
0 голосов
/ 01 сентября 2018

Я пытаюсь выучить ООП на примерах. Поэтому я пытаюсь реализовать сериализатор объектов. Объект такой же, но его можно сериализовать в XML, JSON и т. Д. Я вижу два типа предложений.

В этом блоге говорят, что мы можем использовать visitor / double dispatch для сериализации объектов.

http://codebetter.com/jeremymiller/2007/10/31/be-not-afraid-of-the-visitor-the-big-bad-composite-or-their-little-friend-double-dispatch/

Но по определению мы строим сериализованный объект из сложного объекта, поэтому имеет смысл создать XMLBuilder и JSONBuilder.

Теперь, какой правильный способ сделать это?

Ответы [ 3 ]

0 голосов
/ 01 сентября 2018

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

Вам определенно НЕ нужно Builder или Посетитель для создания сериализаторов, таких как XMLBuilder или JSONBuilder. Пример по ссылке на CodeBetter пытается продемонстрировать двойную отправку и ее связь с Шаблон посетителя . На мой взгляд, его пример в лучшем случае сбивает с толку.

Объект C # XMLSerialiser, например, объединяет объект любого типа, для которого он был создан, в документ XML. Нет Посетитель или какой-либо другой шаблон в поле зрения! Существует отдельный процесс до persist сериализованного документа (к любому типу хранилища), если это необходимо, и когда вы объединяете эти операции (сериализация и постоянство) в массиве объектов, это где Посетитель применим.

Вместо того, чтобы учить каждый объект в массиве, как сохранять себя во множестве возможных форматов, Шаблон посетителя позволяет другому объекту "посещать" и выполнять операцию хранения. Это в значительной степени в точности пример Wiki Visitor, который показывает, как можно сохранять объекты различных форм, не зная, как сохранить саму форму.

Таким образом, вы можете изучать сериализацию в отрыве от Посетителя или Строителя, потому что они НЕ связаны ... что, я думаю, вы подозревали! Если вы новичок в шаблонах, Посетитель является одним из самых трудных для понимания .....

0 голосов
/ 01 сентября 2018

Объект (акцептор) знает свою структуру, сериализатор (посетитель) знает, как записывать примитивные / простые типы. Оба вместе они могут сериализовать / десериализовать весь граф объекта. Это бинарная отправка или посетитель.

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

Builder обычно используется с шаблоном Named Arguments, чтобы сделать построение объектов с несколькими похожими параметрами менее подверженными ошибкам (с помощью конструктора можно легко поменять два аргумента одного типа). Он используется сгенерированными оболочками Protobuf, но не связан строго с десериализацией.

0 голосов
/ 01 сентября 2018

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

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

Почему бы не попробовать оба метода и оценить, что вам нравится в подходах?

Запись Википедии для шаблона «Посетитель» предоставляет превосходный обзор причин, по которым вы можете выбрать шаблон Посетитель . В частности, «Пример использования» относится непосредственно к вашему вопросу.

Фундаментальная операция в этой иерархии типов - сохранение чертежа в системном формате файла.

Аналогичным образом можно применять шаблон Builder * . Но обратите внимание, что в центре внимания этого шаблона находится создание сложного вывода из нескольких источников. Builder формализует понятие незавершенной работы, позволяя собирать состояние до тех пор, пока не будет создан выходной объект.

Я бы сказал, что шаблон Visitor подходит вам проще. Но выбор за вами - это красота (и проклятие) разработки программного обеспечения!

...