GUI в качестве менеджера объектов
Сейчас в качестве менеджера всех этих объектов выступает GUI. Т.е. при старте приложения в конструкторе главной формы читаем настройки приложения, создаем объекты для работы с ФС, с сетью и связываем все эти объекты между собой. Ну и в процессе работы приложения, почти все взаимодействия идут в коде главной формы (потому что много от юзера зависит).
Вопрос вот какой: стоит ли выносить все взаимодействие между "дочерними" (или динамически создаваемыми во время работы программы объектами) в отдельный объект "менеджер" или "ядро" а в нем реализовать методы внешнего интерфейса, за который дергать этот "менеджер"? Т.е. главная форма приложения будет тупо вызывать 3-5 методов интерфейса "менеджера" и реагировать на события от него. Или это лишний гемор?
Планируется дальнейшее развитие (пока в неизвестном направлени), и если в GUI-евом коде все подряд лепить, то можно потом запутаться.
С другой стороны, так же просто будет запутаться и не в гуевом объекте-менеджере, но зато появиться "отвязка" от GUI.
В общем весь в сомненьях...
С другой стороны, приложение уже есть и работает. А лично я в последнее время склоняюсь к такой идеологии - если спрогнозировать направление развития приложения невозможно, следует делать максимально просто. Т.е. выделять этот менеджер в процессе рефакторинга только тогда, когда это реально понадобится.
Все вышесказанное - "мнение мое, и не обязательно правильное" (с)
В общем весь в сомненьях...
Чтобы не запутаться, надо тренироваться использовать делегирование в своём ПО. Для этого можно завести некоторые ограничения на класс. Типа, не более 5-7 объектов (объектом является и простая переменная типа int), агрегированных в класс, не более 15 строчек на функцию. Это вынудит применять делегирование чаще.
Этот навык пригодится при отделении объектов с GUI от объектов без GUI.
Этот навык пригодится при отделении объектов с GUI от объектов без GUI.
Имхо, минимизация есть зло.
На примере: допустим есть класс настроек приложения большого, многооконного, пусть 10 окон, в каждом окне по таблице, 5 кнопок 3 чекбокса, итого получается, что класс должен содержать под сотню переменных и пару сотен методов (геттеров и сеттеров), можно в некоторых местах уменьшить кол-во переменных, используя что то типа ассоциативного массива, но всегда такое получится..
На мой взгляд здесь нет универсального решения. Класс с имплементацией на 17000 строк, который я видел, это конечно жесткое извращение. С другой стороны, искусственно огрничивать какой-либо класс определенным количеством строк - не есть хорошо.
Я так не понимаю. Можешь объяснить на примере известного приложения?
Можно взять браузер или текстовй редактор или ещё что-то. Только вот у этих получается что-то типа MDI - как раз массив. Ну и диалоги. Но диалог можно создавать прямо в функции и в ней же убивать.
И это. Я тебе говорю - "не более 5-7 объектов", а ты мне про "сотню переменных". Вот в браузере может быть всего 2 объекта:
1. менеджер документов (вкладок)
2. менеджер ядра (который содержит менеджера настроек и менеджера обмена по сети, например).
Как-то так. А эти 2 объекта можно дальше делить.
Я говорил про треннинг. В боевых условиях всякое бывает. Особенно, когда "надо уже вчера". Но нужен навык, определённая культура, для того, чтобы не запутаться. Она сама по себе не возникнет.
1С знаешь?
Так вот, там очень дохрена окон, когда работаешь в 1С как пользователь, можешь растягивать эти окна, в таблицах размеры ячеек менять, сами ячейки местами менять, отчеты различные сохранять, и все эти настройки сохраняются куда то в локальную папку юзера. В самой 1С из за того что она на сплошных СОМах сделана, думаю класс настроек выглядит очень хитро (к тому же объекты там динамические), но с другой стороны он просто обязан содержать по нескольку предопределенных параметров для каждого типа метаобъекта (Справочнки, Документы, регистры и т.д.) и этих параметров там с полсотни наберется.
Не знаю. Как-то устанавливал одной даме, но сам не работал.
Ты же сам сказал про ассоциативные массивы. Вначале передаёшь словарь с настройками менеджеру метаобъектов, менеджер создает на основе словаря метаобъекты, которые получают по части словаря. На основе частей словаря они строят свои части. Все метаобъекты хранятся в едином контейнере.
При сохранении проходим по контейнеру и методом get_dict собираем нужные данные, объединяем их в единый словарь и сохраняем как json или xml.
При сохранении проходим по контейнеру и методом get_dict собираем нужные данные, объединяем их в единый словарь и сохраняем как json или xml.
Я ж говорю, что как минимум для каждого типа метаданных там должна быть своя переменная, которая в конечном итоге будет являться массивом, но объединить в один массив все типы метаданных нельзя, т.к. они совершенно разные (хотя хрен его знает как в одинэс это реализовано, возможно есть какой либо базовый объект IBaseMetadata)
Ты сам на свои вопросы отвечаешь. Главное, чтобы у IBaseMetadata был метод типа get_dict().
Ну и уточню, что словарь (он же ассоциативный словарь) для простоты может содержать только строки. На основе строк фабрика может построить что угодно.
Ну и уточню, что словарь (он же ассоциативный словарь) для простоты может содержать только строки. На основе строк фабрика может построить что угодно.
Словари, фабрики и т.д. это уже относится к некоторой степени исскуства в программинге.
Меня интересует более приземленная задача, а именно определить тот момент, при котором GUI становится "невыгодно" использовать в качестве менеджера дочерних объектов.
ЗЫ: напоминает тему про шаблоны, там к стати дали годное определение когда их надо юзать.
Меня интересует более приземленная задача, а именно определить тот момент, при котором GUI становится "невыгодно" использовать в качестве менеджера дочерних объектов.
"Определить момент" - это тоже относится к некоторой степени искусства. И он намного сложнее, чем словари, и даже чем фабрика.
Поэтому, учитывая условие о приземлённости, присоединяюсь к совету от Нездешнего на счёт того, что ничего не надо менять.