Обсуждение архитектуры приложения. Пример с фабричным методом

[nata267]

2nata267:
Просьба, вы когда выкладываете решение, поясняйте, зачем оно нужно и, главное, чем оно лучше известных решений. Например, метаобъектная система Qt позволяет сделать так, а на row C++ вы вынуждены будете делать так и т.п.

Я стараюсь пояснять для чего нужны примеры. К тому же примеры из жизни и следовательно понятно для чего они нужно. Последний например - это всем известные окошки программ-редакторов (окошки свойств, object inspector и т д).  
Чем рассматриваемые мной решения лучше? А какие критерии по которым определяется чем лучше или хуже?? И что вы понимаете под "известные решения". Может быть мне они не известны, выкладывайте свои известные решения. Очень интересно их будет сравнить. Если классы в примерах наследуют от qt-шниых QObject, QWidget... следовательно метаобъектная система Qt позволяет сделать так, а не чистый с++, об этом нетрудно догадаться.

[nata267]

Может быть обсуждать архитектуру следует другим образом. Ставить задачу, а каждый будет предлагать свое решение. У кого самое красивое - тот и победил). Например, как реализовать такую функциональность приложения как Отмена/Возврат действий пользователя. Всем известно что там применяется паттерн команда. Но это в теории. А подробное решение данной задачи - структура и взаимодействие классов. И так чтобы это решение подходило для многократного использования в различных проектах

[Igors]

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

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

Edit:

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

Дело в том что полное/честное решение этой задачи (undo) весьма сложно, во всяком случае Qt его не предоставляет. Не настаиваю но имеет смысл взять что-то попроще

[nata267]

Не настаиваю но имеет смысл взять что-то попроще

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

[Akon]

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

Да, конечно raw (а не row).

[Igors]

Например?

А я Вас предупреждал что найти подходящий пример "архитектуры" совсем непросто, так что ищите сами  

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

Ну можно начать с того же примерв Qt и освоить простую технику undo stack. Некоторые (или многие) находятся в счастливой безмятежной уверенности что undo решается как "и все остальное" - ну прочитал ассыстант, взял класс и "попробывал". Однако в случае undo это не так, там действительно "архитектура" - и это тааак не нравится  

[Igors]

Ну и что, я знаю что такое фабрики классов, для чего они нужны и как реализуются, и для меня это в целом неинтересно. Но! Может быть, вы приводите использование некоторой Qt-фичи, упрощающей реализацию паттерна, и если я не знаю об этой фиче, то мне становится интересно и я читаю топик, в противном случае - пропускаю топик.

Я часто ловил себя на мысли что некоторые вещи вроде казались вполне ясными - но оказывается понимались мною весьма поверхностно. Так что повторить и углУбить - точно не помешает

[nata267]

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

Да, конечно raw (а не row).

Фабрику можно реализовать по разному, это просто одна из версий её реализации. Фабрика + менеджер, регистрирующий каждую конкретную фабрику под определенным id фабрики. По id фабрики менеджер определяет с помощью какой конкретной фабрики создавать конкретный продукт. И кстати называется фабрикой расширений (ExtensionFactory), потому что конкретные продукты являются расширением некоторого объекта, переденного при создании этого продукта. То есть это фабрика оболочек какихто объектов. Если это свойства объекта (PropertySheetExtension), то это оболочка хранящая свойства объекта к примеру. Если это контейнер (ContainerExtension), то это оболочка-контейнер объекта и.т.д.
К тому же у одного и тогоже объекта в системе может быть несколько расширений разного плана. Получить их можно с помощью менеджера расширений.

Вот в этом фитча собственно и объяснение зачем нужен пример.

[alexis031182]

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

[nata267]

почему затычка??

Потому что не пользуемся ToolWindow::CreateStandardToolWindow, который для этого предназначен, а городим еще inline чтобы это же сделать

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

[Авварон]

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

Не понял. "медленно" найти фабрику по айдишнику в мапе?

[alexis031182]

Не понял. "медленно" найти фабрику по айдишнику в мапе?

Создание объекта.

[Авварон]

Не понял. "медленно" найти фабрику по айдишнику в мапе?

Создание объекта.

"Если надо создавать много объектов, то это медленно"? Я правильно экстрагировал мысль?

[alexis031182]

"Если надо создавать много объектов, то это медленно"? Я правильно экстрагировал мысль?

Если необходимо постоянное создание множества объектов в предельно сжатые сроки. Желательно вообще не тратить время на создание. В данном случае, решением может послужить кэширование или пул.

[nata267]

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

оболочка объекта создается только один раз и только по запросу, если она не нужна, то она не создается, затем она регистрируется и при повторном её запросе, мы её не создаем, а используем существующую зарегистрированную. Почему мы проигрываем в быстродействии?? Изза поиска по map??