Архитектура: парсинг и выгрузка текстовиков

начало было положено в ветке - Считать текстовые файлы из папки - там и возник вопрос об Архитектуре...

Сообщение от JeyCi так и не собрала эти все объекты этого класса в group class...

вроде уже собрала...
осталось отображение создать (типа I_tbl_Show) и пронаследовать ? в разные классы пункта назначения (или на консоль, или в файл, или в БД, или допустим ещё в форму)... N.B. классы (пункты-назначения) делать не надо - эти View уже реализованы разработчиками того ПО, на котором сейчас идёт работа...
а) пока что можно просто прописать функции-члены класса; и по месту использовать, что надо при разработке - в файл или на консоль;
б) в перспективе для Release - реализовать и откомпилировать и выгрузку и в файл, и выгрузку в БД, и отражение в DataGrid...
===
!! Т.Е. если в Release захочется и выгрузку в текст, и в БД, и допустим ещё в форму (например с разных кнопок сделать) - тут уж лучше и писать, как положено, наследование??... -- к слову из прошлой ветки о:

Сообщение от JeyCi полагаю тут Наследования никакого не пригодится?

... или как раз тут (при выборе направления выгрузки) его (наследование) делать??
===
Обоснование выбора уровня Абстракции (I_tbl_Show со всеми виртуальными функциями):
чтобы не дублировать код-сбора-для-выгрузки -- сделать class Table - и класс-интерфейс I_tbl_Show, в котором обозначить virtual-функции выгрузки... эти функции определить в др. классах - типа Interface (IwriteCSV, IwriteDB, IwriteDataGrid)...
p.s.
классы консоль, файл, бд, DataGrid - не создаём, т.к. эти пункты назначения уже присутствуют...
p.p.s.
вывести конечные интерфейсы с определёнными методами записи на кнопки...
===
ИЛИ то, что подчёркнуто чуть выше, стоит реализовать в одном классе Table, и здесь же задать все virtual функции ??
===
на скрине: синие - классы, зелёные - интерфейсы (в с++ по сути тоже классы)
птицами отмечены уже кое-как реализованные классы (2 птицы)
курсивные стрелки - отсутствие наследования


Добавлено через 7 минут
вобщем вопрос:
class Table и класс I_Tbl_Show - объединить или нет?

Добавлено через 10 минут
p.p.s.
чтобы избежать проблем Ромба и такого:
Неоднозначность при множественном наследовании

Сообщение от DrOffset Тут нужно виртуальное наследование.

0

можно как нибудь так + pimpl'ы

1

Проблемы с множественным наследованием

Добавлено через 4 минуты
zayats80888, спасибо...

Сообщение от zayats80888 struct Table;

, честно говоря, struct не очень хотела, т.к. сюда может (и вероятнее всего так и будет) добавится метод join'a этих input-files (по ключевым полям)... но спасибо за внимание к теме - постараюсь понять... пока ещё только начинаю знакомиться с с++ (как отметила в предыдущей ветке)

0

Сообщение от JeyCi struct не очень хотела

struct - это class с public скоупом по-умолчанию(я просто что бы public не писать использовал struct)

1

Сообщение от zayats80888 struct - это class с public... (я просто что бы public не писать использовал struct)

ну, вобщем-то, да
Язык C++ / Абстрактные типы данных

По умолчанию при объявлении структуры ее данные и функции являются общими, то есть у объектов типа структура нет ни инкапсуляции, ни защиты данных

- беру на заметку...

0

0

значит есть - если указать явно... благодарю
p.s. по моему линку по АТД - там даже функции можно сделать...

0

Сообщение от JeyCi значит есть - если указать явно...

Не "если указать явно", а в принципе есть. Отличие только в модификаторах доступа по умолчанию при объявлении и при наследовании, то есть если наследует структура, то по умолчанию будет public-наследование
Если наследует класс, то по умолчнию будет private-наследование

Сообщение от JeyCi p.s. по моему линку по АТД - там даже функции можно сделать...

Вообще в С++ по сути классом можно назвать все что объявлено с помощью ключевых слов class, struct и даже union - они все могут содержать поля и методы, могут наследовать и быть унаследованы и т.д.

1

Сообщение от Annemesski даже union

Поправочка. union - class type, но в наследовании его использовать нельзя.

1

DrOffset, таки да, разогнался с class/struct, а union имеет более серьёзные отличия от первых

0

в 2-х словах отмечу общие нюансы наследования или ненаследования (что отметила для себя):

Путаница между конструкцией и обобщением

здесь
- 1-е (Конструкция) - это наследование (для передачи свойств и методов потомкам с возможностью реализации в потомках и их собственных свойств и методов - т.е. расширение базового класса);
- 2-е (Обобщение) - это создание абстрактных классов...
Абстрактные классы - как гарантия того, что в наследниках будут реализованы опр. методы...
Абстрактные классы могут иметь, как чистые виртуальные функции, так и виртуальные таблицы, которые могут использоваться, если у вас есть указатель или ссылка на Абстрактный Класс...
Множественное наследование не есть хорошо в принципе (особенно, когда у родителей есть общий базовый класс) - т.к. могут в производном появиться 2 и более (в зависимости от того, сколько родителей) экземпляра одного элемента (при ромбовидной структуре наследования)... или просто, когда в классах одноимённые переменные-члены - будет неопределённость... менять имена, договариваться с разработчиками тех классов-родителей, откуда появляется неопределённое поведение, использовать виртуальное наследование...
Интерфейсные классы - содержащие только методы - могут иметь множественное наследование - быть используемыми различными базовыми классами... содержат только методы, не имеют полей... (т.е. по сути они абстрактные с виртуальными методами, но без полей)...
Дружественные классы, как ещё один способ разрулить ромб, - преобразовать порождение из нескольких классов в порождение из 1-го класса и объявить дружественный(е) класс(ы)
===
вроде весь арсенал возможных структурных единиц в проектировании... имхо... ещё банально одиночное наследование... и Виртуальные Базовые Классы...

Добавлено через 2 минуты
===
#2 уже буду обкатывать в коде - пока без комментариев...
в любом случае спасибо, за новые понятия в моём арсенале

Добавлено через 6 минут
базовый Serializer и его производные DataGridSerializer и CSVSerializer - вижу...

Сообщение от zayats80888 struct Table { //... void write(const Serializer& s) const { s << *this; }; };

- а это уже наверно, без какого-либо наследования, просто передачей параметра-результатаSerializerОтработки, чтобы записать куда хочется?? - буду пробовать...

Добавлено через 1 час 49 минут
да и здесь на форуме - Как правильно реализовать множественное наследование? - примеры и вложения последних постов о том, как обрабатывает множественное наследование сам компилятор ... хотя по скрину начала топика - у нас его пока нет... но мало ли потом появится...

Добавлено через 4 минуты
P.S.
там на скрине верхние классы copy-paste'ом делала - поэтому методы одинаковые от базового кл. ... конечно, же правильнее нарисовать внутри потомков соотв. методы... но исправить уже не смогу - просто для инфо

Добавлено через 18 минут
и Проектирование в общем и целом:
- Определение иерархии классов
- Идентификация членов иерархии
и здесь:

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

0

Сообщение от JeyCi struct Table - а это уже наверно, без какого-либо наследования, просто передачей параметра-результатаSerializerОтработки, чтобы записать куда хочется??

- вопрос снят
- точнее - всё та же наша собранная таблца Class Table (на скрине) с функцией обращения к I_tbl_Show (Абстрактный класс), 'virtual void оператор<<' которого переопределяется далее в соотв. производных интерфейсных классах...
p.s.
Вобщем, что никакого множественного наследования и никаких виртуальных классов (виртуального наследования) для урегулирования ромба (его тем более нет)... только чистая виртуальная функция Абстрактного класса Serializer...
p.p.s.
Урок №168. Чистые виртуальные функции, Интерфейсы и Абстрактные классы
всё-таки ещё виртуальные таблицы стоит иметь ввиду ДЛЯ позднего связывания, т.е. НЕ на этапе компиляции, насколько понимаю... Урок №167. Виртуальные таблицы

-- только ещё понять остаётся, как ими пользоваться и надо ли?... - в чём выгода??... - если всё равно всё компилируется и компилятор сам расставляет всё по своим местам, независимо от того раннее или поздне связывание - связывает как надо и можно забыть об этом, пользуясь Release'ом разработанного приложения...
но всё-таки, мне кажется, в разработке интерфейсных классов в DLL и/или COMdll - эти вирт. таблицы стоит иметь ввиду? -- хотя там, в принципе, сама библиотека ATL всё имеет ввиду -- только птиц где-то проставить надо в начале разработки... - вопрос снят

0

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

0

Сообщение от DrOffset JeyCi, вам не понятно зачем виртуальные таблицы или зачем полиморфизм в целом нужен?

насколько понимаю, полиморфизм в целом - для расширения классов в том или ином направлении, т.е. для порождения иных разных классов (или даже просто сущностей) от одного родителя...
вот когда использовать виртуальные таблицы - вероятно, когда мне нужно позднее связывание... НО я могу понять, что мне может быть нужно реализовать его, например, в dll или COMdll. т.к. ковыряла надстройку в Borland'e (кстати очень понравилась IDE, только старая и не все библы есть, а на RAD Studio ещё не перешла - там регистрация в Community нужна)...
но не могу понять, если application создаётся на чистом С++, мы компилируем и забываем о нами написанном коде (т.к., вероятно, компилятор делает все нужные ему name mangling (also called name decoration), и/или даже вообще переводит код в ассемблер)... вобщем стоит ли мне в коде на чистом С++ использовать позднее связывание -- оно медленнее раннего, но ? отразится ли на конечном Build'e appl'a... и есть ли хоть какая выгода в позднем связывании, кроме его использования в, например, интерфейсе, реализованном в надстройке на С++, но используемом, например, в Excel -- там в принципе, часто подключаем библу поздним связыванием и это просто удобно...
т.е. не-совсем-понимание, наверно, КОГДА стоит заворачиваться в коде на указателях на эти виртуальные таблицы? (если писать appl на чистом C++) - ГДЕ от этого будет Profit?

0

Сообщение от JeyCi КОГДА стоит заворачиваться в коде на указателях на эти виртуальные таблицы?

Я же написал, виртуальные таблицы - это деталь реализации полиморфизма. Если вы используете полиморфизм классов в С++, вы автоматически используете виртуальные таблицы.

1

Сообщение от DrOffset Если вы используете полиморфизм классов в С++, вы автоматически используете виртуальные таблицы.

логично! - когда даём ссылку на метод...
спасибо

0

Сообщение от JeyCi когда даём ссылку на метод...

Когда просто вызываете любую виртуальную функцию.

1

хм, просто подумала, что вызов виртуальной функции класса и вызов простого метода класса - примерно одинаково по синтаксису можно использовать...
Ссылка на метод класса
Как получить указатель на метод объекта?
(и виртуальные вызывать можно также подумала)
+
__vptr сама по себе -

Каждая запись в этой таблице — это указатель на функцию

поэтому так и выразилась
p.s.

Ссылка - это скрытый указатель

- насколько помню *ptr=&objClass

Добавлено через 7 минут
p.p.s.
Указатели на функции-члены и реализация самых быстрых делегатов на С++.

0

Сообщение от JeyCi м, просто подумала, что вызов виртуальной функции класса и вызов простого метода класса - примерно одинаково по синтаксису можно использовать...

А при чем тут синтаксис?
Виртуальные таблицы используются неявно. Компилятор генерирует соответствующий код с их использованием.

Добавлено через 6 минут
JeyCi, вообще мне кажется вы путаете реализацию и собственно язык. Для того, чтобы программировать на С++ в обычных условиях не нужно знать о каких-то там виртуальных таблицах. Их вообще в стандарте языка нет. Т.е., теоретически, в какой-то реализации вообще может не быть этих таблиц нигде, а полиморфизм, RTTI будут реализованы как-то по-другому (хотя на практике я лично с таким не сталкивался).

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

0

Сообщение от DrOffset Виртуальные таблицы используются неявно.

да язык меня интересует... -
* или & ставить или нет, обращаясь к методу?..
что более memory-efficient? (а в этом контексте и реализация не маловажна... имхо)

0