как организовать граф(очень специфический)

[Kurk_SS]

Сразу прошу прощения за большой объём текста


Расказываю по порядку относительно графа:

1)Граф будет точно деревом-размеры неизвестны

2)Каждый узел графа - это данные,ветки(ссылки) на другие узлы, количество переменно

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

Интерпритация Директор-в подчинении начальники филиалов, у тех в свою очередь свои подчинённые роботники и начальники и так структура разная.

Директор подаёт команду - сколько карандашей(канц товар)надо и пошло поехало в низ а потом вверх общая сумма.(щитаеться что даные про карандаш это количество и всё)

Сколько стульев надо(внимание стулья уже разных типов поэтому ответ будет ввиде таблички, каждый работник(начальник) знает какой тип ему надо и сколько)

И т д

данные узлов графа:

Тип1- данные1 -параметры1- параметры 2...- количесто
Тип1- данные2 -параметры1- параметры 2..- количесто
......
Тип2 данные1 - параметры1- параметры 2- количесто
.....
запросы всегда на Объём или количество

1-сумировать количество можно только если тип одинаков(ну например хлеб и молоко не сумировать)

2-есть типы данных разные(с точки зрения компа - идентификатор типа) но на самом деле в жизни одно и тоже - отличаються параметрами данных,то их можно просумировать по объёму
Например молоко1 =бутылка1л. - параметры=обьём(1л.) и количество,молоко2=бутылка2л.-параметры аналогично
тоесть если поступила команда про сумму бутылок то сумирование отдельное, но если на литраж то вместе)

Что касаеться однотипных данных в одном узле:
каждый узел отображает графически все свои потомки и данные- вот для того не обьеденено в один потомучто отображение должно быть раздельно(например булки хлеба одного и тогоже- 6+8+9 булок но отобразить надо что это три разные кучки.

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



(например из таких файлов)

--файл перечисления всех типов данных-
[тип даных1]
кол.парам.=число
типПарам.1=тип
типПарам.2=тип
........
[тип даных2]
....

-файл перечисления всех узлов-
[узел1]
{дочерние узлы}
кол.даных=число
данные1=значение
данные2=значение
......
[узел2]
....
[узел5=узел6=узел7]-это значит что данные этих узлов идентичны, но это разные узлы(такое возможно только с тупиковыми узлами---чисто для того что если есть такого рода дубликаты то при вводе данных по узлам не вводить дважды а просто указать ссылку, а в ини файл запишеться такая строка, и один родитель будет ссылаться на узел5, другой на узел6 итд, но в дереве это будет три разных обьекта-узла и впроцесе запросов на выборку узел6 скажем учавствует в сумме а узел7 нет(просто на кождый объект будет маркер участия/неучастия в суммировании)

[Kurk_SS]

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

Да ёма ё- уже дубликат пропал. а как удалить сообщение найти не могу

[alexBlack]

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

Потребности - это список записей/объектов вида
ID - идентификатор
марка/вид/тип
количество/объем

Узел содержит только ссылку на свои потребности, т.к. потребности могут быть одинаковы для нескольких узлов. При сохранении узла сохраняется ID потребности. Сами потребности хранятся отдельно.

узел при получении запроса просматривает свои потребности и возвращает ответ.

запрос может быть:

по ID объекта с указанием марки - получение количества по конкретной марке

по ID объекта без указания марки развернутый - возвращается список всех марок и количество для каждой

по ID объекта без указания марки свернутый - возвращается количество для любой марки объекта ID.

[Kurk_SS]

Спасибо за ответ, только видимо я не настолько спец как ты думал... можно поподоробней(например набросок на описание класа потребностей и узла.... я всё не понимаю-
потребность-количество параметров и тип каждого параметра не известны заранее, соответственно и неизвестно как обработать запрос, вернуть количество или преборазовать количество с учетом параметров
(Например 2л*6шт.*3 ящика=36л)

[alexBlack]

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

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

С узлом, думаю, понятно
list : TList; - список ветвей (как я понял их будет больше 2-х)
P : ПОТРЕБНОСТЬ - ссылка на класс потребностей

КЛАСС потребностей
list : TList - список или указателей на record или на класс

каждая запись - потребность в одном товаре и хранит:
ID - идентификатор
count - количество (о единицах измерения см. ниже)

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

я всё не понимаю-
потребность-количество параметров и тип каждого параметра не известны заранее, соответственно и неизвестно как обработать запрос, вернуть количество или преборазовать количество с учетом параметров
(Например 2л*6шт.*3 ящика=36л)

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

2л в пакете
6 пакетов в ящике
3 ящика

Запрос может быть:
- потребность в литрах
- потребность в ящиках ?
- потребность в пакетах ?

первый вариант - только в литрах - остается один параметр. А как расфасовано не имеет значения. Остальные параметры (ящики, пакеты) получаются уже из литров и из имеющегося в наличии ассортимента тары.

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

Например, храним в л - 36
Запрос - (указывается коэффициент) - 12 - получаем в ящиках (3)
Запрос - (указывается коэффициент) - 2 - получаем в пакетах (18)

[Kurk_SS]

да я так и подумал нащот ТЛист, только решил что вместо указателей на клас ресурсов брать тоже список, а каждый ресурс - это свой клас...
========
Остаёться проблематичным вопрос с перещётом. коефициент перещота не катит т.к. в общем случае это даже не сведеться к просто коэфициенту. тоесть получаеться, как я думаю - есть пораметры ресурса качественнные(жирность молока, производитель итд-те что точно не влияют на переращоты едениц измерения)
а естя количественные параметры(например кол. ящиков, кол бут в ящике, литраж бутылки; или халва - тогда вес 1л(плотность) размеры кусков х1*х2*х3 кол кусков в убаковке) и вот получаеться каждый ресурс должен уметь выдавать правильные перерасчоты

я Думаю сделать базовый клас ТРесурс, А реальные ресурсы это потомки которые умеют уже на запрос типа Выдать(ИД ед.изм.):результат

Слушай а такой вопрос-
Туре
Тклас1 Базовый ресурс
процедура Прок1
енд;
Тклас2=класс(Тклас1) Реальный ресурс
процедура Прок1
енд;

а в программе
А:Тклас2;
......
(А как Тклас1).Прок1 -какая процедура сработает?

А вообще как сделать что вот есть у меня 10 потомков базового ресурса.

в коде создания дерева, яж не знаю на перёд что за ресурс, вот бы можна было чтоб одной переменной типа Тобъект в цикле чтомповать дерево учитывая что все потомки точно имеют один вызов конструктора, одинаковые поля для связей дерева, одинаковые команды чтоб заполнить себя параметрами из файла(указываеться раздел ини файла, а дальше перекрытый метод чтения из файла каждого потомка сам разберёться)

[alexBlack]

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

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

Да, хороший подход.

(А как Тклас1).Прок1 -какая процедура сработает?

Как показано вызовется Тклас2.Прок1
Правильней будет сделать метод виртуальным.

А вообще как сделать что вот есть у меня 10 потомков базового ресурса.
в коде создания дерева, яж не знаю на перёд что за ресурс, вот бы можна было
чтоб одной переменной типа Тобъект в цикле чтомповать дерево учитывая что
все потомки точно имеют один вызов конструктора, одинаковые поля для связей
дерева, одинаковые команды чтоб заполнить себя параметрами из файла
(указываеться раздел ини файла, а дальше перекрытый метод чтения из
файла каждого потомка сам разберёться)

Не совсем понял вопрос.
Переменеую делаем базового класса

FРесурс : TБазовый_класс

А создаем используя конкретный объект

FРесурс := TКонкретныйРесур.Create;

Используем только виртуальные методы FРесурс. Будет вызыватся их реализация в перекрытых методах

[Kurk_SS]

цит. (А как Тклас1).Прок1 -какая процедура сработает?

я так понял это"как" тупо указание компилятору, что б он мог оценить правильность кода-ну и самому потом легче раздуплится - чего это обьект одного типа вдруг использует метод другого типа????

-----------------цит.
Переменеую делаем базового класса

FРесурс : TБазовый_класс

А создаем используя конкретный объект

FРесурс := TКонкретныйРесур.Create;

Используем только виртуальные методы FРесурс. Будет вызыватся их реализация в перекрытых методах

Тоесть мне только один оператор выбора на несколько станиц прийдёться делать

case IdResurs of
1:Fresurs:=TKonkretniiResurs1.Creat e;
2:Fresurs:=TKonkretniiResurs2.Creat e;
......
end;
а потом в програме когда работает переменная ФРесурс:ТБазовыйРесурс(если все методы виртуальные) то автоматически будут работать методы нужного потомка(в зависимости от сработавшей строчки в операторе выбора?

Если да то это очень круто.

Книга где я читал про эти директивы для описания класов очень хреновая в том что касаеться таких тонкостей, хотя свои плюсы есть.(Фаронов)

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

ЗЫ: У меня на компе книга валяеться - "Структура данных + алгоритм= программа" вот теперь я кажись понимаю зачем нужно и первое слагаемое ешо не читал-думал шо фигня; взял масив, запись,список или шо там по смыслу подходит и вперёд писать прожку возможно реализовав алгоритм из книги(например симплекс метод-последнее моё дело) а тут оказываеться Стр.Данных тоже важна. Ты кстать не читал эту книгу?? иль мож чтото из этой серии порекомендуешь(примеры проектирования програм с сложной структурой типа моего графа)

Спасибо шо отвечаешь... редко на форумах доводилось находить на сложные вопросы советчика Спасибо!

[alexBlack]

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

Тоесть мне только один оператор выбора на несколько станиц прийдёться делать

case IdResurs of
1:Fresurs:=TKonkretniiResurs1.Creat e;
2:Fresurs:=TKonkretniiResurs2.Creat e;
......
end;
а потом в програме когда работает переменная ФРесурс:ТБазовыйРесурс(если все методы виртуальные) то автоматически будут работать методы нужного потомка(в зависимости от сработавшей строчки в операторе выбора?

Если да то это очень круто.

Да. Более того, в правильно спроектированной программе не бывает case на несколько страниц. Хотя на первых порах и такой вариант можно рассмотреть.

а где можно так чтоб не на 300стр...

300 стр это мало для такой темы и книг нужно прочитать не одну.

По поводу object of, virtual, class of и т.д.
- во-первых для того, чтобы понять КАК это работает нужно изучать язык, а чтобы понять ГДЕ и ДЛЯ-ЧЕГО это применять - объектно ориентированное проектирование, паттерны проектирования...

Конкретно "Структура данных + алгоритм= программа" уже не помню, название знакомое.

Могу посоветовать:
Borland Pascal 7.0 - описание - хорошее введение в ООП.
Т.Бадд "ООП"
Гамма, Хелм "Приемы ООП"
Макконелл "Совершенный код"
"Веревка достаточной длины...."
Страупступ "Язык С++"

-------------------------
По поводу самой задачи. Сколько бы мы не размышляли о структуре узла, дерево останется деревом. Можно уже начинать писать. Пусть узел пока будет хотя и объектом, но пустым и отвечает только на простой запрос. Например, вернуть, какое-то число. Так мы разобьем задачу на две части. Сначала реализуем дерево. Потом можно будет думать об узлах. На готовом дереве уже будет возможность проверить идеи.

[Kurk_SS]

Более того, в правильно спроектированной программе не бывает case на несколько страниц.

кроме случая?

Командная строка которая поддерживает около 300 команд- какой первый оператор обработчика ввода? (у меня в полноэкраном режиме редактора кода в окне 43 строчки 300/43=6.9767441860465