Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

GUI в качестве менеджера объектов

11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Есть не особо большой проект, который включает в себя несколько классов по работе с различными сущностями: работа с файловой структурой, сетью, настройки приложения и т.п.
Сейчас в качестве менеджера всех этих объектов выступает GUI. Т.е. при старте приложения в конструкторе главной формы читаем настройки приложения, создаем объекты для работы с ФС, с сетью и связываем все эти объекты между собой. Ну и в процессе работы приложения, почти все взаимодействия идут в коде главной формы (потому что много от юзера зависит).
Вопрос вот какой: стоит ли выносить все взаимодействие между "дочерними" (или динамически создаваемыми во время работы программы объектами) в отдельный объект "менеджер" или "ядро" а в нем реализовать методы внешнего интерфейса, за который дергать этот "менеджер"? Т.е. главная форма приложения будет тупо вызывать 3-5 методов интерфейса "менеджера" и реагировать на события от него. Или это лишний гемор?
535
29 июня 2011 года
Нездешний
537 / / 17.01.2008
Так было бы, наверное, кошернее, но если все уже есть в нынешнем виде и работает - может, и не стоит трогать. Так что главный вопрос - зачем?
11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Нездешний
Так что главный вопрос - зачем?


Планируется дальнейшее развитие (пока в неизвестном направлени), и если в GUI-евом коде все подряд лепить, то можно потом запутаться.
С другой стороны, так же просто будет запутаться и не в гуевом объекте-менеджере, но зато появиться "отвязка" от GUI.
В общем весь в сомненьях...

535
29 июня 2011 года
Нездешний
537 / / 17.01.2008
В общем, пытаешься использовать MVC-паттерн. Раз есть конструктор формы, значит, используешь какой-то фреймворк. А фреймворк уже вносит сумятицу в классический паттерн, объединяя в своих обработчиках GUI сообщений View и Controller. Так что, если сможешь выделить из кода именно Model - тогда это стоит сделать. Но это в теории.

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

Все вышесказанное - "мнение мое, и не обязательно правильное" (с)
87
29 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
С другой стороны, так же просто будет запутаться и не в гуевом объекте-менеджере, но зато появиться "отвязка" от GUI.
В общем весь в сомненьях...



Чтобы не запутаться, надо тренироваться использовать делегирование в своём ПО. Для этого можно завести некоторые ограничения на класс. Типа, не более 5-7 объектов (объектом является и простая переменная типа int), агрегированных в класс, не более 15 строчек на функцию. Это вынудит применять делегирование чаще.

Этот навык пригодится при отделении объектов с GUI от объектов без GUI.

11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Чтобы не запутаться, надо тренироваться использовать делегирование в своём ПО. Для этого можно завести некоторые ограничения на класс. Типа, не более 5-7 объектов (объектом является и простая переменная типа int), агрегированных в класс, не более 15 строчек на функцию. Это вынудит применять делегирование чаще.

Этот навык пригодится при отделении объектов с GUI от объектов без GUI.


Имхо, минимизация есть зло.
На примере: допустим есть класс настроек приложения большого, многооконного, пусть 10 окон, в каждом окне по таблице, 5 кнопок 3 чекбокса, итого получается, что класс должен содержать под сотню переменных и пару сотен методов (геттеров и сеттеров), можно в некоторых местах уменьшить кол-во переменных, используя что то типа ассоциативного массива, но всегда такое получится..

288
29 июня 2011 года
nikitozz
1.2K / / 09.03.2007
Цитата: Kogrom
Чтобы не запутаться, надо тренироваться использовать делегирование в своём ПО. Для этого можно завести некоторые ограничения на класс. Типа, не более 5-7 объектов (объектом является и простая переменная типа int), агрегированных в класс, не более 15 строчек на функцию. Это вынудит применять делегирование чаще.



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

87
29 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
На примере: допустим есть класс настроек приложения большого, многооконного, пусть 10 окон, в каждом окне по таблице, 5 кнопок 3 чекбокса, итого получается, что класс должен содержать под сотню переменных и пару сотен методов (геттеров и сеттеров), можно в некоторых местах уменьшить кол-во переменных, используя что то типа ассоциативного массива, но всегда такое получится..



Я так не понимаю. Можешь объяснить на примере известного приложения?

Можно взять браузер или текстовй редактор или ещё что-то. Только вот у этих получается что-то типа MDI - как раз массив. Ну и диалоги. Но диалог можно создавать прямо в функции и в ней же убивать.

И это. Я тебе говорю - "не более 5-7 объектов", а ты мне про "сотню переменных". Вот в браузере может быть всего 2 объекта:

1. менеджер документов (вкладок)
2. менеджер ядра (который содержит менеджера настроек и менеджера обмена по сети, например).

Как-то так. А эти 2 объекта можно дальше делить.

87
29 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: nikitozz
На мой взгляд здесь нет универсального решения. Класс с имплементацией на 17000 строк, который я видел, это конечно жесткое извращение. С другой стороны, искусственно огрничивать какой-либо класс определенным количеством строк - не есть хорошо.



Я говорил про треннинг. В боевых условиях всякое бывает. Особенно, когда "надо уже вчера". Но нужен навык, определённая культура, для того, чтобы не запутаться. Она сама по себе не возникнет.

11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Я так не понимаю. Можешь объяснить на примере известного приложения?



1С знаешь?
Так вот, там очень дохрена окон, когда работаешь в 1С как пользователь, можешь растягивать эти окна, в таблицах размеры ячеек менять, сами ячейки местами менять, отчеты различные сохранять, и все эти настройки сохраняются куда то в локальную папку юзера. В самой 1С из за того что она на сплошных СОМах сделана, думаю класс настроек выглядит очень хитро (к тому же объекты там динамические), но с другой стороны он просто обязан содержать по нескольку предопределенных параметров для каждого типа метаобъекта (Справочнки, Документы, регистры и т.д.) и этих параметров там с полсотни наберется.

87
29 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
1С знаешь?



Не знаю. Как-то устанавливал одной даме, но сам не работал.

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



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

При сохранении проходим по контейнеру и методом get_dict собираем нужные данные, объединяем их в единый словарь и сохраняем как json или xml.

11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Ты же сам сказал про ассоциативные массивы. Вначале передаёшь словарь с настройками менеджеру метаобъектов, менеджер создает на основе словаря метаобъекты, которые получают по части словаря. На основе частей словаря они строят свои части. Все метаобъекты хранятся в едином контейнере.

При сохранении проходим по контейнеру и методом get_dict собираем нужные данные, объединяем их в единый словарь и сохраняем как json или xml.



Я ж говорю, что как минимум для каждого типа метаданных там должна быть своя переменная, которая в конечном итоге будет являться массивом, но объединить в один массив все типы метаданных нельзя, т.к. они совершенно разные (хотя хрен его знает как в одинэс это реализовано, возможно есть какой либо базовый объект IBaseMetadata)

87
29 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
Я ж говорю, что как минимум для каждого типа метаданных там должна быть своя переменная, которая в конечном итоге будет являться массивом, но объединить в один массив все типы метаданных нельзя, т.к. они совершенно разные (хотя хрен его знает как в одинэс это реализовано, возможно есть какой либо базовый объект IBaseMetadata)



Ты сам на свои вопросы отвечаешь. Главное, чтобы у IBaseMetadata был метод типа get_dict().

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

11
29 июня 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Ты сам на свои вопросы отвечаешь. Главное, чтобы у IBaseMetadata был метод типа get_dict().

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



Словари, фабрики и т.д. это уже относится к некоторой степени исскуства в программинге.
Меня интересует более приземленная задача, а именно определить тот момент, при котором GUI становится "невыгодно" использовать в качестве менеджера дочерних объектов.
ЗЫ: напоминает тему про шаблоны, там к стати дали годное определение когда их надо юзать.

87
30 июня 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
Словари, фабрики и т.д. это уже относится к некоторой степени исскуства в программинге.
Меня интересует более приземленная задача, а именно определить тот момент, при котором GUI становится "невыгодно" использовать в качестве менеджера дочерних объектов.



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

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог