Здравствуйте, SergeyOsipov, Вы писали:

SVZ>>Я бы пропихивал указатель не на граф, а на "возвращателя типа ноды" (коим по совместительству может являться граф).
SO>Хмм, а зачем выделать это в отдельный интерфейс? Вроде у него больше не будет наследников, только граф знает такие вещи.

Зависимости уменьшить. Да и всякое бывает, вдруг потребуется брать типы нодов (и, возможно, не только их) из другого источника.
Но это так, перестраховка.
Лично мне этот вариант больше всех нравится.

Здравствуйте, SergeyOsipov, Вы писали:

Visiter

Здравствуйте, Sinix, Вы писали:

SO>>...Так вот input нода или output — хранится только в классе графа. И это правильно. А класс рисователь ноды не знает про класс графа, он знает только про класс ноды.

S>Тогда ещё варианты: или завести разные типы узлов для входных / выходных переменных, или добавить в отрисовщик знание о входах / выходах узла.

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

Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная. И сама переменная не знает и не должна знать про себя — входной она параметр или выходной. Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.

Код отрисовки отдельно, сам алгоритм — отдельно. По графу алгоритма строить граф визуальных компонентов, при построении подсовывать нужные параметры отрисовки.

Здравствуйте, Sinix, Вы писали:

S>Код отрисовки отдельно, сам алгоритм — отдельно. По графу алгоритма строить граф визуальных компонентов, при построении подсовывать нужные параметры отрисовки.

Завести в переменных флаги отрисовки? Так этого и хотелось избежать. Навешивать отдельный класс-отрисовыватель? Некрасиво как-то.

Здравствуйте, SergeyOsipov, Вы писали:

S>>Код отрисовки отдельно, сам алгоритм — отдельно. По графу алгоритма строить граф визуальных компонентов, при построении подсовывать нужные параметры отрисовки.

SO>Завести в переменных флаги отрисовки? Так этого и хотелось избежать. Навешивать отдельный класс-отрисовыватель? Некрасиво как-то.

Как раз тут всё красиво, хотя реализация будет посложнее.
Представь, если рисовать надо в разных случаях по разному? Будешь запихивать кучу функций рисования в класс с данными?

Я бы посмотрел в сторону нелюбимого Визитёра.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Как раз тут всё красиво, хотя реализация будет посложнее.
SVZ>Представь, если рисовать надо в разных случаях по разному? Будешь запихивать кучу функций рисования в класс с данными?

У меня сейчас и есть разделение — данные и визуализаторы. Точнее даже 4 класса у меня. Класс ноды(чисто данные), класс графа (чисто данные)-работает с классами нод и линами между ними, класс рисователь ноды и класс рисователь графа. Так вот input нода или output — хранится только в классе графа. И это правильно. А класс рисователь ноды не знает про класс графа, он знает только про класс ноды.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Навешивать отдельный класс-отрисовыватель? Некрасиво как-то.
Именно. Из графа данных, которые ничего не знают об отрисовке получить граф, размеченный доп. информацией для отрисовки

SO>Некрасиво как-то.
Ну а какие ещё варианты?

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

Здравствуйте, SergeyOsipov, Вы писали:

SO>У меня сейчас и есть разделение — данные и визуализаторы. Точнее даже 4 класса у меня. Класс ноды(чисто данные), класс графа (чисто данные)-работает с классами нод и линами между ними, класс рисователь ноды и класс рисователь графа. Так вот input нода или output — хранится только в классе графа. И это правильно. А класс рисователь ноды не знает про класс графа, он знает только про класс ноды.

Тогда ещё варианты: или завести разные типы узлов для входных / выходных переменных, или добавить в отрисовщик знание о входах / выходах узла.

Здравствуйте, Sinix, Вы писали:

S>Тогда ещё варианты: или завести разные типы узлов для входных / выходных переменных, или добавить в отрисовщик знание о входах / выходах узла.

Вопрос, собственно, был не как сделать, чтоб работало, потому что это не проблема. А как сделать чтоб уоасиво
Что-то не нравится мне вариант с флагом для рисовальщика, но видать нет вариантов.

А если во всех рисовальщиков пропихивать указатель на граф, а в графе слелать метод, который говорит о типе ноды — это красивее?

Здравствуйте, SergeyOsipov, Вы писали:

S>>Тогда ещё варианты: или завести разные типы узлов для входных / выходных переменных, или добавить в отрисовщик знание о входах / выходах узла.

SO>А если во всех рисовальщиков пропихивать указатель на граф, а в графе слелать метод, который говорит о типе ноды — это красивее?

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Я бы пропихивал указатель не на граф, а на "возвращателя типа ноды" (коим по совместительству может являться граф).

Хмм, а зачем выделать это в отдельный интерфейс? Вроде у него больше не будет наследников, только граф знает такие вещи.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Лично мне этот вариант больше всех нравится.

Да, пожалуй, мне тоже нравится. По крайней мере позволяет избежать флагов в отрисовщике, не люблю я такие флаги-заплатки.

SO>Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная. И сама переменная не знает и не должна знать про себя — входной она параметр или выходной. Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.

Отрисовываете вы (отрисовывает сам себя) параметр, а не переменная. А параметр уже знает, входной он, или выходной.
Кстати, очень вероятно, что на каком-нибудь этапе захочется отделить модель (Parameter) от его графического представления (ParameterImage). Этакий MVVM, но не ради байнинга, а по-делу

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная. И сама переменная не знает и не должна знать про себя — входной она параметр или выходной. Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.

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

Здравствуйте, Ikemefula, Вы писали:

I> Непонятно, зачем переменной самой себя рендерить.

Предлагаешь графу знать какая нода как себе отрисовывает?

Здравствуйте, SergeyOsipov, Вы писали:

SO>Здравствуйте, Ikemefula, Вы писали:

I>> Непонятно, зачем переменной самой себя рендерить.

SO>Предлагаешь графу знать какая нода как себе отрисовывает?

SO>

	Скрытый текст

Жуть какая. А для чего всё это? Ещё один simulink

Сделайте у переменной вход и выход. А лучше ящик с N входами и M выходами.

Здравствуйте, kov_serg, Вы писали:

_>Сделайте у переменной вход и выход. А лучше ящик с N входами и M выходами.

Забавно, на моей визуализации думаю все поймут сразу, где входные, где выходные. Чтоб понять вашу схему, надо долго думать.
Вообще, думаю разработчики UnrealEngine подумали об удобстве и юзабилити . Я повторяю их Blueprint для собственных нужд

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная. И сама переменная не знает и не должна знать про себя — входной она параметр или выходной. Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.

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

Вашу задачу я бы решал иначе. Никаких классов-рисовальщиков, которые на вход получают ноду/дугу с данными. Можно разработать/найти компонент VectorDraw, который рисует группу примитивов на поверхности. Браузер с svg графикой хороший кандидат. Т.е. вью пусть будет декларативное (набор примитивов, закрепленных за нодой), а не императивное (процедура, которая получила ноду и нарисовала ее с помощью gdi). При создании ваших переменных тот кто их создает, он же создает набор примитивов для визуализации переменной и закрепляет их за этой переменной. Этот создатель располагает графом и вообще всем. Будут у вас классы переменные/алгоритмы, которые ничего не знают о визуализации, даже своих координат на плоскости (если конечно эти координаты не нужны для основного алгоритма). И буду в сторонке группы графических примитивов со ссылками на ваши переменные/алгоритмы по id. Рисовать примитивы будет VectorDraw.

Здравствуйте, sr_dev, Вы писали:

_>При создании ваших переменных тот кто их создает, он же создает набор примитивов для визуализации переменной и закрепляет их за этой переменной. Этот создатель располагает графом и вообще всем.

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

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная.
Вот тут ты теряешь информацию о типе аргумента рассматривая его как просто переменную.
SO>И сама переменная не знает и не должна знать про себя — входной она параметр или выходной.
Действительно, у переменной нет направления, а у аргумента есть.
SO>Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить? Добавить флаг в функицю отрисовки — не вариант.
Отнаследуй от класса переменной класс аргумента, у которого будет направление и рисуй аргументы, имея полную информацию. Код функции отрисовки вроде бы не должен поменяться.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Здравствуйте, kov_serg, Вы писали:

_>>Сделайте у переменной вход и выход. А лучше ящик с N входами и M выходами.

SO>Забавно, на моей визуализации думаю все поймут сразу, где входные, где выходные. Чтоб понять вашу схему, надо долго думать.
SO>Вообще, думаю разработчики UnrealEngine подумали об удобстве и юзабилити . Я повторяю их Blueprint для собственных нужд

Я понял, вы сремитель к этому

Здравствуйте, SergeyOsipov, Вы писали:

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

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

Я лет 5 графы рисовал, спрашивай

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть некая визуализация алгоритма в виде графа. Этот алгоритм — это функция с входными и выходными параметрами. Любой параметр — это просто переменная. И сама переменная не знает и не должна знать про себя — входной она параметр или выходной. Но. Любая переменная сама себя отрисовывает в виде ноды графа. Так вот входные и выходные параметры по-разному себя отрисовывать должны, но они сами внутри себя не знают входные они или выходные. Как разрулить?
Есть такой баззворд как SOLID. В частности Single Responsiblility Principle. Твои сложности как раз из за того, что ты делаешь God Object — смешиваешь логику самого алгоритма и отрисовки.

Соответственно у тебя должна быть функция. Которая вообще ни о каком рисовании не знает, ей важна логика. Есть сущность — рисователь. Которой ты говоришь что за переменные, что за параметры, но которой пофиг на алгоритм. Рисователь графа — будет частным случаем, возможно наследником от какого либо абстрактного класса. И тогда у тебя будет алгоритм отдельно, рисование переменных, параметров, графа — тоже отдельно.

Здравствуйте, kov_serg, Вы писали:

_>Я понял, вы сремитель к этому

Любой граф можно довести до абсурда. И ваш пример тоже можно превратить в месиво линий и квадратиков. Как и в программировании можно всю программу запихнуть в функцию main. Но никто так не делает, а пишут небольшие функции. Так же и в блюпринте пишут подфункции — свои графы. Я досиаточно плотно поработал с блюпринт, и говорю, что это очень удобно. Спросите у сотни разработчиков игр, которые пишут только на блюпринте.

Здравствуйте, SergeyOsipov, Вы писали:

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