Удаление объектов, созданных addClassObject

[CagoBHuK]

Всем привет. Пытаюсь сделать автоматическое создание объектов для определенного набора данных. При этом если обработчик запускается повторно, то все ранее созданные таким образом объекты мне необходимо сначала удалить.

Код: Выделить всё

addClassObject($class, $objName);

Таким образом я создал объект. А вот каким образом мне объект $object удалить?

[Bagir]

Никогда не задумывался об удалении объектов. создавать, да, например для регистрации нового WiFi устройства. Интересно для какой цели вам понадобилось удаление объектов? Может как то по другому можно решить задачу?

[CagoBHuK]

Никогда не задумывался об удалении объектов. создавать, да, например для регистрации нового WiFi устройства. Интересно для какой цели вам понадобилось удаление объектов? Может как то по другому можно решить задачу?

У меня есть класс Port. Он имеет несколько наследников PortIn, PortOut и так далее. Класс-устройство, которому принадлежат эти Port, имеет механизм автонастройки своих портов. Допустим, на физическом устройстве я изменил тип порта с In на Out. Соответственно, тип наследника должен измениться с одного на другого. Механизма полиморфизма я не нашел, поэтому вижу решение только в удалении уже имеющегося порта и добавлении его заново с другим типом наследника.

[Bagir]

Если я правильно понял, то у меня несколько похожая ситуация с объектами сети Z-Wave. Самый яркий пример это пульт и выключатели. У них есть совершенно другие свойства. Проще говоря, эти железки не такие как все остальные. Я долго думал как сделать всё это безобразие. Были мысли создать подклассы как в случае с классом keySensors, но всё же в случае с Z-Wave я просто объявляю в классе все возможные свойства и методы разнообразного железа.
Вероятно есть какой то предел, где побеждает решение создать подклассы, и вариант с объявлением несуществующих свойств.
Как итог, да, действительно удаление объектов может понадобится, если поставить задачу именно так, и в дальнейшем оперировать объектами классов. Но я бы попробовал решить задачу как то иначе без динамических объектов.
А как вы в дальнейшем работайте с этими созданными объектами портов? Лично я, из того что у меня есть, могу только сравнить с портами МегаД. При замене управляющего модуля можно, например, объявить порт выход как порт вход. И да, у него уже будут совсем другие свойства.
Просто при работе с этим устройством я в коде сильно привязываюсь к имени объекта. И я даже не представляю как бы это всё выглядело, если бы я заранее не знал имя этого объекта. То есть если бы имя было динамическое.
Трудно дальше рассуждать без полного понимания картины.

[CagoBHuK]

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

По поводу того, как же они работают дальше? Вот тут и возникает необходимость делить класс на подклассы, т.к. каждый тип порта ведет себя по-разному в разных ситуациях, например, при изменении своего статуса. Если порт IN должен выполнить все действия, которые при изменении статуса должны происходить (например, изменить статус объектам-портам OUT), то порт OUT должен вместо этого при изменении своего статуса направить команду на саму Мегу. Именно универсализация и заставила меня отойти от общего набора свойств и поделить классы портов на ветки. Программерская лень безгранична, и, описав поведение каждому классу, механизм будет работать сам по себе, один раз считав настройки с Меги. Новая Мега - это добавление объекта и нажатие на кнопку самонастрйки. При этом скрипт megad.php вообще состоит из 10 строчек кода. Если полетит, я выложу отдельными классами для заинтересованных.

[Bagir]

Дело становится интереснее. Просто МегаД это можно сказать основные руки и уши моей системы. Лень, да верно, она безгранична. Готов день писать код, чтобы потом выполнить задачу за пять минут, которая требует пары часов рутинной работы
Просто я пошел по другому пути работы с Мегой. Изначально всё базируется на объектах класса keySensors и Relays. Класс MegaD просто "линкует" эти классы с железом. Я не сильно дружу с паяльником, поэтому использую готовые блоки 7I7O. Поэтому назначение порта для меня заранее предопределено.

[CagoBHuK]

Короче, нашел только код удаления. Отдельной функции нет.

Код: Выделить всё

            $rec=SQLSelectOne("SELECT * FROM objects WHERE TITLE='$id'");
            // some action for related tables
            SQLExec("DELETE FROM history WHERE OBJECT_ID='".$rec['ID']."'");
            SQLExec("DELETE FROM methods WHERE OBJECT_ID='".$rec['ID']."'");
            SQLExec("DELETE FROM pvalues WHERE OBJECT_ID='".$rec['ID']."'");
            SQLExec("DELETE FROM properties WHERE OBJECT_ID='".$rec['ID']."'");
            SQLExec("DELETE FROM objects WHERE ID='".$rec['ID']."'");
 

[directman66]

Сергей, а может все же сделать готовую функцию? Люди просят )) или хотябы массовое удаление из редактора