Прошу совета в проектировании классов

[Sergey82]

Добрый день.

У меня вопрос по проектированию. Пусть имеется некоторая иерархия классов, например, базовый класс - Data, от него унаследованы классы FragmentData, TaskData и ParamData. Каждый из классов содержит некоторые данные. Также имеется класс Program, у которого есть три поля (аттрибута) типа FragmentData, TaskData и ParamData. Имеется необходимость для класса Program осуществлять генерацию в файл.

Я вижу два варианта организации:

1. В классе Data создать абстрактный метод generate, а в каждом наследнике его реализовать. Тогда Program.generate() будет просто вызывать generate() для каждого своего аттрибута.

2. Создать отдельный класс Generator, который получает на вход Program и на его основе осуществляет генерацию.

Плюс первого подхода: выглядит более объектно-ориентированным, функция обработки инкапсулирована вместе с данными.

Плюсы второго подхода: если необходимо добавить новый способ генерации, то достаточно создать новый класс, тогда как в первом подходе необходимо доработать каждого наследника от Data (в этом смысле второй подход примерно походит на MVC).

Кроме того, если мы выбираем второй подход, то классы FragmentData, TaskData и ParamData фактически вырождаются в обычные структуры, т.к. кроме хранения данных других функций не выполняют. Имеет ли вообще тогда смысл их оформлять как классы?

Заранее спасибо.

Сергей

[pu4koff]

Сообщение от Sergey82

Плюс первого подхода: выглядит более объектно-ориентированным, функция обработки инкапсулирована вместе с данными.

Плюсы второго подхода: если необходимо добавить новый способ генерации, то достаточно создать новый класс, тогда как в первом подходе необходимо доработать каждого наследника от Data (в этом смысле второй подход примерно походит на MVC).

Нынче как раз модно правило: "мухи отдельно, котлеты отдельно". Работает с хранилищем (файлами, БД,...) один класс, данные хранит - другой класс, обрабатывает данные - третий класс.
Второй подход выглядит гибче. Только нужна ли Вам эта гибкость?

Сообщение от Sergey82

Имеет ли вообще тогда смысл их оформлять как классы?

У Вас же наследование используется, так что классы это, а не структуры

В общем тут сами выбирайте метод. Оба имеют право на жизнь со своими оговорками. Если знать что за классы эти и какие функции они выполняют, то уже можно выбрать наиболее подходящий из этих подходов.
Если генерация в файл занимает мало места, сами классы мелкие и простенькие, то можно и первый использовать. Если эти классы подразумевают работу с файлами и это является одной из их функций, то генерацию в файл опять же можно по первому методу делать. Согласитесь, глупо для класса файлового потока выносить работу с файлом в другой какой-то класс. Если эти данные могут быть получены не только из файла и вообще к способу хранения мало относятся, то предпочтительнее будет вероятно второй способ. Например, зачем в класс string добавлять методы сохранения в файл? Пусть этим занимается специальный класс.
Ну и смотря какие библиотеки используются. Для MFC, например, есть вариант использования сериализации для этой цели.

[Sergey82]

Сообщение от pu4koff

В общем тут сами выбирайте метод. Оба имеют право на жизнь со своими оговорками. Если знать что за классы эти и какие функции они выполняют, то уже можно выбрать наиболее подходящий из этих подходов.

Задача такая: я пишу транслятор с одного языка программирования на другой. Классы, описанные выше - это часть классов, отвечающих за внутреннее представление программы, а генерация в файл - это генерация программы на целевом языке на основе внутреннего представления.

Сообщение от pu4koff

У Вас же наследование используется, так что классы это, а не структуры

Да, но если в классе нет ни одного метода, а только аттрибуты, то наследование какое-то искусственное получается...

Первая версия транслятора была написана на С++ в процедурном стиле. Там всё было просто: вот дерево программы (множество структур), вот процедуры, их обрабатывающие. Новую версию хочу написать в объектном стиле, вот и встала проблема с декомпозицией.

Сообщение от pu4koff

Если эти классы подразумевают работу с файлами и это является одной из их функций, то генерацию в файл опять же можно по первому методу делать. Согласитесь, глупо для класса файлового потока выносить работу с файлом в другой какой-то класс.

Да в общем-то не подразумевают, это как модель в MVC. Внутренее представление программы - оно само по себе, просто способ хранения данных.

Сообщение от pu4koff

Для MFC, например, есть вариант использования сериализации для этой цели.

Никаких посторонних библиотек. Только С++ и STL.

[pu4koff]

Сообщение от Sergey82

Задача такая: я пишу транслятор с одного языка программирования на другой. Классы, описанные выше - это часть классов, отвечающих за внутреннее представление программы, а генерация в файл - это генерация программы на целевом языке на основе внутреннего представления.

В таком случае, предлагаю представить, что захотите реализовать преобразование не между 2-мя языками, а между 5, 10,... В идеале - чтобы между каждыми 2-мя языками можно было код преобразовывать.

Сообщение от Sergey82

Да, но если в классе нет ни одного метода, а только аттрибуты, то наследование какое-то искусственное получается...

Необходимость в наследовании больше зависит от классов. Вероятно, не стоит наследовать автомобиль, зачетную книжку и договор от одного класса, имеющего только аттрибут "номер", ведь у этих всех классов разная природа (ну тут конечно могут быть свои поправки для конкретной задачи, но, надеюсь, Вы поняли что я хотел сказать ). В то же время логично наследовать собаку и кошку от класса животное, пусть даже в последнем не будет ни одного аттрибута и ни одного метода.
Плюс наследования - это можно утверждать, что Собака - это есть животное и кошка - это есть животное. Можно унаследовать квартиру от гаража (у него же есть адрес и площадь, а для квартиры всё нужное добавим), но получится истинным выражение: квартира - это есть гараж. Глупо как-то получается
Так что с наследованием с этого конца посмотрите: что эти хххData представляют из себя и что реализуют.
Моё видение возможной реализации в целом:
Набор классов типа: функция, метод, класс, переменная, цикл, комментарий,... в общем на основные блоки программы по классу (никаких зависимых от языка программирования вещей тут храниться не должно). Наследуем их от базового класса: блок программы.
Некий абстрактный класс реализующий чтение и запись программы на конкретном языке программирования:

класс ТруЛяЛя
{
  void Открыть(путь_к_программе);
  void Создать(путь_к_программе);
  void ДобавитьБлок(блок а);
  блок* ПрочитатьБлок();
  ...
};

Тогда преобразование между языками мне видится примерно таким:

Cpp.ОткрытьПрограмму("C:\123.cpp");
Delphi.СоздатьПрограмму("C:\123.dpr");
пока (!Cpp.КонецПрограммы())
{
  Delphi.ДобавитьБлок(Cpp.ПрочитатьБлок());
}

Тут конечно много граблей всплывет, т.к. языки разные и разные возможности. Как преобразовать вот такой цикл с С++ на Делфи?

for (int i = 0, int j =0; i < 5 && j < 10; i++, j += 2)
{
...
}

Через while решается, но мой вариант получается "зашит" на то, что for на for меняется. Так что есть над чем подумать в плане иерархий классовых. Кроме того, в делфях есть файл проекта, а в С++ - нет. В С++ есть заголовочные файлы (*.h) и файлы реализации (*.cpp), а в делфях модули тока в виде (*.pas)

[Sergey82]

Сообщение от pu4koff

Набор классов типа: функция, метод, класс, переменная, цикл, комментарий,... в общем на основные блоки программы по классу (никаких зависимых от языка программирования вещей тут храниться не должно).

То, что вы перечислили - это уже очень сильно зависит от языка, точнее - от класса языков. Переменные, циклы, функции - всё это есть только в императивных языках. Например, в функциональных языках циклов нет, а переменные имеют другой смысл. Так что перевод "конструкция в конструкцию" не сработает. Надо делать полноценный анализ исходной программы, на основе которого с нуля писать новую программу.

[pu4koff]

Сообщение от Sergey82

Так что перевод "конструкция в конструкцию" не сработает. Надо делать полноценный анализ исходной программы, на основе которого с нуля писать новую программу.

Согласен. Я это понял уже в процессе написания сообщения, но уж не стал удалять, вдруг ход мыслИ полезным будет