MajorDoMo

lanket писал(а): Сделать Так
Rooms->LivingRoom->PirSensor

Таким образом не надо каждый сенсор одинакого типа копировать методы и св-ва такого же датчика. Создавать копии одного и того же кода да еще и во множественном числе противоречет ООП.

Вы смешиваете разные понятия ООП.
В моем понимании цепочка Rooms->LivingRoom->PirSensor символизирует дерево классов. Т.е. LivingRoom наследует все свойства и методы Rooms, и, возможно, расширяет их своими. Это вполне логичное наследование.
Но затем PirSensor наследует свойства и методы LivingRoom, т.е. датчик является разновидностью комнаты - но это ведь не так.

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

У меня, например, до сих пор ни разу не возникло ситуации, которую я не смог бы уложить в парадигму ООП при текущем функционале.
Единственное, чего мне не хватает "из коробки", чтобы избежать дублирования кода при написании методов наследованных объектов - это возможности вызова методов родительских классов из любого места моего метода.

lanket писал(а):
Я думмаю Михаил_Калуга не смог донести свою мысль.

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

По организации классов нужно придерживаться: датчики к датчикам, окна к окнам, двери к дверям.

Согласен с olehs не совсем правильную реализацию предложил.
К слову зачем в объектах есть свойство местоположение?
Как его использовать?
Может это и есть то о чем говорит Михаил_Калуга?
Или это и есть не до конца реализованная мысль о связях помещений и сенсоров?


Отправлено с моего HM NOTE 1LTEW через Tapatalk

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

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

Недоработочка мелкая.
Комментарии на скрепке.

Чето перемудрил в первый раз. Уж больно спешил изложить мысль.

Попробую по другому сформулировать.

Есть класс Sensors с основным списком св-в и обработки данных.
У которого есть подклассы расширяющие дополнительную обработку или св-ва в случае если так надо (взял у olehs, идея хорошая)
В этих классах есть обекты-шаблоны разных типов датчиков

Где нибудь в настройках "драйвера" (модуля-шлюза для общения с железками-сенсорами) или , даже лучше, отдельно модуль/приложение.
Которое привязывает к объекту, в данный момент объект помещение класса Rooms (в примере это Livingroom) "тень"/"проекцию" объекта из другого класса в данном случае Sensors->StateSensors->OpenDoor. То есть наследует из объекта Sensors->StateSensors->OpenDoor св-ва и методы обработки.
В результате у объекта Класса Rooms (в данном случае Livingroom) появляются после связи дополниьельные св-ва и методы унаследованные из объекта Sensors->StateSensors->OpenDoor

В результате мне кажется получим маштабируемость системы и более наглядность с темеже сенсорами.

Надеюсь сейчас более грамотно описал без глупых, с почки зрения ООП, предложений.
Как думает всемогущий ALL имеет право на жизнь такая идея.
Или меня что-то не в ту степь понесло?

sergejey писал(а):

Михаил_Калуга писал(а):...

Михаил Вы что-то похожее имели ввиду?

lanket писал(а): Недоработочка мелкая.

Пока есть дети - удалить родителя невозможно.

ErmolenkoM писал(а):

lanket писал(а): Недоработочка мелкая.

Пока есть дети - удалить родителя невозможно.

Логично.

Что-то я старею видимо. Очевидное не замечаю.

lanket писал(а): Которое привязывает к объекту, в данный момент объект помещение класса Rooms (в примере это Livingroom) "тень"/"проекцию" объекта из другого класса в данном случае Sensors->StateSensors->OpenDoor. То есть наследует из объекта Sensors->StateSensors->OpenDoor св-ва и методы обработки.
В результате у объекта Класса Rooms (в данном случае Livingroom) появляются после связи дополниьельные св-ва и методы унаследованные из объекта Sensors->StateSensors->OpenDoor

Наверное не стоит все смешивать. Пока не приходит в голову какие Класс Rooms может унаследовать св-ва и методы из объекта Sensors->StateSensors->OpenDoor. Теоретически у двери могут быть свойства (если не брать во внимание отделку) открыта, закрыта и местоположение. У датчика местоположение и сигнал на выходе 1, 0 или аналоговое /цифровое значение.
Свойство местоположение позволяет указать конкретное местоположение, а также масштабировать систему устанавливая связь между объектами.
Пример конкретное местоположение и масштабируемость: датчик на окне №3, окно №3 в зале, зал в помещении дома №1, дом №1 на участке где есть другие постройки. Это может обеспечить поле местоположение.
Теоретически можно добавить в таблицу objects новое поле object_id (поле LOCATION_ID удалить), но поле object_id не может иметь значение 0, поэтому самой верхней структуре в примере "участок" местоположение задать не сможем.

пс. как вариант, если верхнего местоположения нет объект может выбирать сам себя. Те если только одна квартира у объекта зал выбирать местоположение зал. Если появился подвал. Тогда создаем новый класс (например Жилище) где два объекта квартира и подвал. И тд.