Разбор файлов для установки данных объекта - вопрос дизайна

Question

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

Итак, у меня был один класс для разбора файлов, CommandFileParser и два класса для каждого типа файла / объекта: один для самого объекта и один для возможных команд, которые могут использоваться для установки данных в объект , например VectorDrawing и VectorDrawingCommands. Методы последнего были бы вызваны CommandFileParser с использованием отражения, поскольку он нашел их во входном файле, и применил данные к первому.

Но мне кажется, это действительно грязный способ сделать это. Я закончил тем, что повторял множество шаблонного кода, делая вещи вроде dataobject.value = value во всех классах -Commands. И мне не нравится иметь вспомогательный класс для каждого основного класса данных только для того, чтобы установить данные.

Может кто-нибудь предложить какие-либо идеи для более чистых и более подходящих способов сделать это?

Answer 1

"Я закончил тем, что повторял множество шаблонных кодов, делая такие вещи, как dataobject.value = value."

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

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

Answer 2

Почему вы не могли просто использовать отражение, чтобы установить значения полей или свойств напрямую и удалить всю концепцию -Команд классов?

Answer 3

Возможно, вы хотите, чтобы каждый класс наследовал CommandFileParser, а не отделял его.

Answer 4

Я не знаю о VB.Net, но на всех языках ОО, с которыми я знаком, нормальный подход состоит в том, чтобы изменяемый объект содержал методы, которые устанавливают значения своих собственных атрибутов, а не помещал эту работу во второй класс.

Есть ли какая-то причина, по которой вы бы не поместили методы в свой текущий класс VectorDrawingCommands непосредственно в VectorDrawing, а полностью исключили VectorDrawingCommands?

Answer 5

Если все ваши команды содержат прямые назначения, возможно, вам не нужны объекты команд. Можете ли вы непосредственно отразить отражение на самих объектах и ​​полностью избавиться от командных объектов?

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

Кстати, мне нравится идея использовать отражение для поиска команд. Это позволяет невероятно легко добавлять новые команды.