Правильная структура?

[Kod.Begemot]

Ещё вопрос, как лучше организовать подобное:
Есть объекты класса MyRooms, комнаты.
в классе есть всё для управление освещением (6 методов, 7 свойств),
есть термостат (текущая температура, значение уставки, параметры сопряженного устройства термостатирования)
есть общие данные (активность, влажность, и т.п.)
вот можно как нибудь их по-другому организовать? Чувствую - количество параметров освещения будет только расти, пока только "ГлавныйСвет", а будет ещё и подсветка...
Будут ещё ролл-шторы - со своими свойствами и методами..
Как потом в этом огромном списке не запутаться, как структурировать?
Уйти от концепции комната, и всё что с ней связано? сделать отдельно класс "свет" и делать объекты "HallMainLight", "HallWallLight" и т.п.?
Я попробовал создать класс, для которого MyRooms является родительским - но так и не понял - что это мне даёт.
Я чувствую, что можно как-то сделать, не даром же придумали модель ООП, но сам я программирую совсем недавно, и опыта нет.

[Bagir]

Очень важная тема. Хотелось бы делать все в одном общепринятом стиле. Но описания такого стиля я до сих пор не нашел. И поэтому все делают как сами считают нужным.
Количество объектов постоянно растет. Через годик, я думаю, что их количество у меня умножится как минимум на три, т.к. с системой я уже знаком, фундамент заложен и отлично работает, и дальнейшие силы и время пойдут уже на добавление новых возможностей.
Как определился:
Делаю каждому датчику его отдельный объект, а каждому исполнительному устройству - объект в классе реле. Для сложных составных устройств, таких как Z-Wave, MegaD и т.п. у которых в составе одного корпуса имеется по нескольку датчиков, создаю вспомогательные классы. Задача объектов в этих классах принимать данные со сложного устройства и передавать их объектам в соответствующих классах датчиков и реле. Да, возможно получается увеличение числа объектов. Но зато это очень сильно облегчает настройку и понимание. Без проблем можно заменить датчик или реле одного типа на совершенно другой тип т.к. объекты классов реле и датчиков вообще не изменяются, и вся ранее написанная логика сохраняется.
О логике:
Все условия можно хранить как в объектах классов датчиков так и в реле. Мне больше нравится второе. Если для работы реле есть несколько условий, то я делаю у этого объекта метод, который может быть вызван при изменении статуса разных датчиков или элементов меню. Иногда бывает полезно сообщать в этот метод с логикой информацию кто именно его вызвал.
Создавать отдельные классы для таких задач как свет или роль ставни, я думаю не следует. Просто я не вижу в таких задачах горы одинакового кода, который можно было бы вынести в класс. Все и так есть в классах датчиков и реле. Кстати, я завел отдельные подклассы для каждого вида датчиков, и мне такой подход очень понравился.
Больше внимание уделил классу ROOMS. В этом классе я собираю все текущие показания датчиков для каждой комнаты, и храню историю. По этому классу рисуются графики и в будущем буду делать анализ работы той же системы отопления и вентиляции. Еще в классе ROOMS очень удобно использовать его методы onActivity и onIdle. Вместе с данными об уровне освещения можно принимать решения о включении света. Для включения света я просто вызываю метод с логикой в объекте нужного реле.
Так же не стоит забывать про объекты класса OperationalModes. Весьма удобно смотреть на их статус при принятии решений.
Я уже давно хочу попробовать нарисовать блок схему своего варианта организации объектов системы, чтобы выложить ее и обсудить. Вот пожалуй и ветка подходящая. Ну теперь как только, так сразу ))

[ErmolenkoM]

Пожалуй, и мои 5 копеек.
До выбора МЖД я делал для себя обзор существующих решений. Такой свободы как здесь - нет ни у кого. С одной стороны это и проблемы - сложность в понимании чужого дома, но и плюс - для своего я рисую индивидуальную схему так как мне нужно. ООП - великая вещь
По поводу рекомендаций - их можно давать, и даже возможно, в начале, следовать. Основные примеры в поставке по умолчанию.
Плохо конечно, что нет стандартизации в объектах, и этим ограничиваются возможности в написании модулей в маркет, но о плюсах было выше.
А вдруг кто в теме? Есть программы построения объектных схем, моделей. Графические картинки рисуют. Если для такой программы выгрузить схему МЖД со связями (не БД, а именно объекты, и вызовы методов воспринимать как связи) в спец формате(например XML) - а она нарисует красивую картинку? Было бы красиво! Например в ERwin.

[Bagir]

Да, это было бы даже интересней структуры. По информации их Connecta все равно не получаешь общую образную схему. А лично мне было бы ну очень любопытно посмотреть как делают другие.

[shemnik69]

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

[Ivan]

А для всего что имеет свой протокол нужно писать модули для маркета

А кто в тихую делает себе, и не делится. Ничего тут не поделаешь

[triada13]

Правильно, делиться должны все.