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

РМ>>На самом деле да. Мне тоже не очень нравится в итоге. Но вариант введения дополнительного класса, который будет хранить параметры инициализации пока они не понадобятся, мне тоже кажется очень плохим, т.к. при создании нового типа объекта придется делать два класса вместо одного, а это морока.
РМ>>Ну а чтобы избежать проблем недоинициализированные объекты хранятся внутри системы инициализации, которая их не отдает наружу пока они не проинициализируются.
__>я лично вообще не понимаю зачем обязат иметь недоиниц обьекты
Ну например модуль отвечающий за связь с сервером, он инициализируется асинхронно.

Здравствуйте, Рома Мик, Вы писали:
РМ>>>На самом деле да. Мне тоже не очень нравится в итоге. Но вариант введения дополнительного класса, который будет хранить параметры инициализации пока они не понадобятся, мне тоже кажется очень плохим, т.к. при создании нового типа объекта придется делать два класса вместо одного, а это морока.
РМ>>>Ну а чтобы избежать проблем недоинициализированные объекты хранятся внутри системы инициализации, которая их не отдает наружу пока они не проинициализируются.
__>>я лично вообще не понимаю зачем обязат иметь недоиниц обьекты
РМ>Ну например модуль отвечающий за связь с сервером, он инициализируется асинхронно.
на конкретном примере кода могу рассказать как сделать нормально

Здравствуйте, Рома Мик, Вы писали:

РМ>Вопрос конечно не сюда, но куда не знаю

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

как обычно, иначе — когда он уже будет переопределен, имя с указанием "переопредели меня" начнет путать

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

РМ>>Вопрос конечно не сюда, но куда не знаю

РМ>>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

K>как обычно, иначе — когда он уже будет переопределен, имя с указанием "переопредели меня" начнет путать
А кого оно будет путать? Вызывать его должна только библиотека, в которой он изначально определен. В идеале бы вообще запретить его видеть всем кроме библиотеки и того, кто переопределяет, причем тот кто переопределяет видеть должен только для переопределения, а вызывать не должен. Но стандартные варианты private и protected такого не позволяют. А еще есть языки, где условно private нету, точнее то, что называется private, на самом деле protected (это haxe).

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

__>я просто работал на нескольких подобных проектах еще после универа. UI вообще провоцирует на подобный говнокод. это не значит, что нельзя сделать по-другому. просто вроде как "удобнее" иметь сложную запутанную логику заполнений обьектов и изменений их состояний.

Их этого опыта не следует, что это судьба всех подобных решений. У меня вот есть инфраструктура конфигурации, которая использует DataContractSerializer для сохранения/восстановления дерева. Конструктор там использовать не получается от слова "совсем". Но, поскольку все дерево конфигурационных классов со всеми методами инициализации и их вызовами генерируется кодогенератором, то проблем с логикой не наблюдается. Клиенсткий код вообще не видит всей подковерной работы, получая на выходе уже полностью проинициализированное дерево.

__>вы никогда не сможете протестировать это автоматически

Уже смог.

__>и вы убьете кучу своего времени, там, месяцы, на то, чтобы заставить это хоть как-то работать

Первый вариант написан примерно за неделю. Последующие правки были минимальными.

__>и оно все равно толком работать не будет

Прекрасно работает.

Здравствуйте, Lexey, Вы писали:
L>Прекрасно работает.
смообман — мощная вещь
apple тоже наверняка думает, что их их iphone прекрасно работает, но я все жду-недождусь уже больше года когда же они поправят баг с переключением аккаунтов (зарегистрировался в одном и сменил на другой), чтобы у меня наконец itunes заработал на телефоне, а не просто крутился и потом тупо игнорировал пароль

Здравствуйте, Рома Мик, Вы писали:

РМ>Вопрос конечно не сюда, но куда не знаю

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

.ctor

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

S>Но можно начать с стартового примера. Ок, как по-вашему должно инициализироваться дерево UI-компонентов?
S>С учётом того, что его _сначала_ надо построить, и только затем добавить на форму.
Следовать принципе Single Responsibilty и завести 2 обьекта: один рисуется, второй — узел в дереве графов.

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

I>Следовать принципе Single Responsibilty и завести 2 обьекта: один рисуется, второй — узел в дереве графов.

Я ж сказал — конкретику, а не "мыши станьте ёжиками"

Ещё раз — у вас есть дерево компонентов. Свойства дерева, например, используемый лэйаут, биндинги или выбор стиля отображения должны заполняться при размещении дерева в контейнере.
Попытка работать с деревом _до_ размещения в контейнере — очевидный баг и должно отлавливаться сразу, исключением. Иначе баг так и останется незамеченным и приведёт к куда более забавным последствиям.

Ну, т.е. реальное требование, которое обсуждению не подлежит.


Теперь (в третий раз) вопрос: какой магией вы собираетесь реализовать это требование не вводя концепцию "объект поддерживает инициализацию"?

Только плиз, не надо как предыдущий автор рассказывать про самообман или предлагать обернуть всё в view — типа если инициализация происходит под капотом, то это не считается.

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

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

I>>Следовать принципе Single Responsibilty и завести 2 обьекта: один рисуется, второй — узел в дереве графов.

S>Я ж сказал — конкретику, а не "мыши станьте ёжиками"
Какая постановка задачи, такое и решение
Я дальше погадаю на кофейной гуще, постараюсь угадать.


S>Ещё раз — у вас есть дерево компонентов. Свойства дерева, например, используемый лэйаут, биндинги или выбор стиля отображения должны заполняться при размещении дерева в контейнере.
S>Попытка работать с деревом _до_ размещения в контейнере — очевидный баг и должно отлавливаться сразу, исключением. Иначе баг так и останется незамеченным и приведёт к куда более забавным последствиям.
S>Ну, т.е. реальное требование, которое обсуждению не подлежит.

S>Теперь (в третий раз) вопрос: какой магией вы собираетесь реализовать это требование не вводя концепцию "объект поддерживает инициализацию"?

class Container
{

}

class SomeData
{

}

class VisualComponent
{
    public VisualComponent(Container cntr, SomeData relatedData)
    {
    }
}

И вся инициализация происходит в конструкторе компонента. Более того, его невозможно создать, не поместив в контейнер.

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


S>>Теперь (в третий раз) вопрос: какой магией вы собираетесь реализовать это требование не вводя концепцию "объект поддерживает инициализацию"?
I>И вся инициализация происходит в конструкторе компонента. Более того, его невозможно создать, не поместив в контейнер.

Ну что ж у вас за привычка такая — класть болт на ТЗ, потому что реализовать неудобно

По определению _любое_ visual tree сначала строится, затем подсовывается в контейнер. Причин тому множество, самое простое — вам понравится форма, которая отрисовывается по частям?

Только плиз не надо приводить ad hoc решение именно для этой проблемы, потому что есть ещё тонна других нюансов, которые не решаются при вашем подходе никак. Начиная с перемещения контролов и заканчивая виртуализацией visual tree (неотображаемые элементы не отрисовываются и не создают нагрузку на UI-стек).

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

S>Ну что ж у вас за привычка такая — класть болт на ТЗ, потому что реализовать неудобно
Я же в предыдущем посте прямым текстом написал: какое ТЗ, такое и решение. У меня миелофона нет и телепаты в отпуске, поэтому про ваши нюансы я могу только догадываться.

S>Только плиз не надо приводить ad hoc решение именно для этой проблемы, потому что есть ещё тонна других нюансов, которые не решаются при вашем подходе никак. Начиная с перемещения контролов и заканчивая виртуализацией visual tree (неотображаемые элементы не отрисовываются и не создают нагрузку на UI-стек).

В моем примере виртуализация отрисовываемого дерева уже есть
Давайте кусок кода — будем обсуждать предметно.

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

I>Я же в предыдущем посте прямым текстом написал: какое ТЗ, такое и решение. У меня миелофона нет и телепаты в отпуске, поэтому про ваши нюансы я могу только догадываться.
Ну а прочитать

С учётом того, что его (дерево компонентов) _сначала_ надо построить, и только затем добавить на форму.

— не?

Эта фича — стандартная возможность для любого боль-менее сложного UI фрефмворка. Вы с ними не работали, возможно?



I>В моем примере виртуализация отрисовываемого дерева уже есть
I>Давайте кусок кода — будем обсуждать предметно.

Блин, да очевидно же. Вот вам самое простое —

control.Parent = anotherWindow;

Нужно, например, для док-панелей с возможностью вытаскивания в отдельное окно.

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

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

S>Блин, да очевидно же. Вот вам самое простое -
S>

S>control.Parent = anotherWindow;
S>

S>Нужно, например, для док-панелей с возможностью вытаскивания в отдельное окно.
Это решается враперами с инициализацией в конструкторе, как я и показывал выше.

class ComponentToWindowConnector
{
    ComponentToWindowConnector(Component component, Window wnd)
    {
        component.Parent = wnd;
    }
    void Dispose()
    {
        component.Parent = null;
    }
}

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


I>Это решается враперами с инициализацией в конструкторе, как я и показывал выше.

Это не решается врапперами, ты просто прячешь за ними внутреннюю кухню и заявляешь, что вот, инициализации не требуется.

Давай ещё раз, ты походу сложность решаемой задачи недооцениваешь.

Всё поведение контрола зависит от родителя. Допустим, в дочернем окне выставлен другой scale или другая ui-тема.
Это приводит к срабатыванию adaptive-триггера, тот, в свою очередь — к смене шаблонов половины контролов, в том числе полной смене поведения этих контролов и к перегенерации всего visual three. Logical three, т.е. инстансы контролов при этом остаются те же. И да, это бизнес-требование, пользователи не хотят, чтобы ссылка на myButton внезапно протухла посреди времени жизни формы.

Ну и как тут нам помогут врапперы?

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

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


I>>Это решается враперами с инициализацией в конструкторе, как я и показывал выше.

S>Это не решается врапперами, ты просто прячешь за ними внутреннюю кухню и заявляешь, что вот, инициализации не требуется.
Так и есть — внутреннюю кухню инкапсулировал в отдельный класс. И я нигде не говорил что инициализации не требуется — вопрос в том где ее делать.

S>Всё поведение контрола зависит от родителя. Допустим, в дочернем окне выставлен другой scale или другая ui-тема.
S>Это приводит к срабатыванию adaptive-триггера, тот, в свою очередь — к смене шаблонов половины контролов, в том числе полной смене поведения этих контролов и к перегенерации всего visual three. Logical three, т.е. инстансы контролов при этом остаются те же. И да, это бизнес-требование, пользователи не хотят, чтобы ссылка на myButton внезапно протухла посреди времени жизни формы.

S>Ну и как тут нам помогут врапперы?
Ну вот так же само и помогут. Одни враперы уничтожаются, другие создаются. Логическое дерево не меняется.

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


S>>Это не решается врапперами, ты просто прячешь за ними внутреннюю кухню и заявляешь, что вот, инициализации не требуется.
I>Так и есть — внутреннюю кухню инкапсулировал в отдельный класс. И я нигде не говорил что инициализации не требуется — вопрос в том где ее делать.

Тьфу, а о чём мы спорим тогда?

Я ж продолжал обсуждать вот это

Автор: __kot2
Дата: 12.04.16

(весьма спорное) утверждение.

Сорри

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

S>Тьфу, а о чём мы спорим тогда?