forum.opennet.ru - "Какой верный путь для получения экземпляро объектов по их типу?" (29)

"Какой верный путь для получения экземпляро объектов по их типу?"

Форум WEB технологии (PHP)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Какой верный путь для получения экземпляро объектов по их типу?"	+9 +/–
Сообщение от Вервер (?), 11-Фев-23, 12:05
Доброго дня Товарищи! Я тут пишу свои всякие поделки, и вот заинтересовался вопросом, а правильный ли я выбрал подход к созданию экземпляра объекта по его ТИПУ? Поясню это на примере: Допустим, есть у меня к несколько разных вариаций от общего предка, к примеру виды Документов: //Общий предок Class Document { const DOC_DOGOVOR = 1; const DOC_PISMO = 2; static public getDocByType(int $docType){ switch($docType){ case self::DOC_DOGOVOR: return new Doc_Dogovor(); break; case self::DOC_PISMO: return new Doc_Pismo(); break; } return false; } } Class Doc_Dogovor extends Document { protected static $docType = Document::DOC_DOGOVOR; //Своя какая-то кухня с свойствами и методами такого //типа документов ... } Class Doc_Pismo extends Document { protected static $docType = Document::DOC_PISMO; //Своя какая-то кухня с свойствами и методами такого //типа документов ... } //Получить объект нужного типа (из БД к примеру тип приходит) $docObj = Document::getDocByType($neededTypeFromDB); Так вот вопрос собственно в том, насколько оправданно или наоборот плохо и как лучше всего такой тип задачи реализовывать? А задача значит получение экземпляра объекта указанного типа. Видел, что во всяких автозагрузчиках классов сейчас используется динамическое их получение условно такой схемой что если запрошенного класса нет, он подгружается по имени и дальше также создаётся объект класса, название которого в переменной $docObj = new $objClassName();
Ответить \| Правка \| Cообщить модератору

Оглавление

Ещё дополню, что почему не стал использовать вариант с получением условно по име, Вервер (?), 12:10 , 11-Фев-23, (1) +8

eval и иже с ним плохи в первую очередь из-за того, что в них поступает непровер, Аноним (3), 16:07 , 11-Фев-23, (3) +6

Да, точно спутал я exec с eval ом Предубеждение у меня к eval у Совсем противо, Вервер (?), 20:45 , 11-Фев-23, (8) +5

Вот этот вариант подойдёт как решение наполовину если вы это будете делать не в, Аноним (10), 05:00 , 12-Фев-23, (10) +4

Потому что условно в БД хранится тип объекта к примеру число objType , и мне чт, Вервер (?), 08:59 , 12-Фев-23, (12) +6

А оно надо Кто пользователь ORM - программист или внешний пользователь, который, Аноним (18), 13:56 , 15-Фев-23, (18) +3

Пользователь ORM - получается программист, т е Я Она типа ORM, хотя конечно н, Вервер (?), 19:25 , 15-Фев-23, (21) +2

gt оверквотинг удален Дяденька, а зачем вы диспатчите типы через enum, как буд, Аноним (3), 16:03 , 11-Фев-23, (2) +4

Я вообще не понял вашего словосочетания Что значит, что я диспатчу enum - это , Вервер (?), 20:42 , 11-Фев-23, (5) +4

А это вам как зайдёт, вот вы изобрели в пхп типы данных из хаскеля - осваивайте,, Аноним (3), 16:13 , 11-Фев-23, (4) +5

С хаскелем не знаком кроме как слышал название этого языка Можете пожалуйста по, Вервер (?), 20:43 , 11-Фев-23, (6) +4

Ознакомьтесь на досуге, такая штука есть во всех ML-подобных языках, Haskell, Oc, Аноним (10), 04:50 , 12-Фев-23, (9) +3

С хаскелем не знаком кроме как слышал название этого языка Можете пожалуйста по, Вервер (?), 20:44 , 11-Фев-23, (7) +5

сделай обычный class Document От него наследуются class Dogovor и class Pismo , Аноним (11), 07:01 , 12-Фев-23, (11) +5

Если что, на самом деле эти Документы, Договора и Письма - чистая выдумка для ил, Вервер (?), 09:04 , 12-Фев-23, (13) +6

Класс Document не должен знать о существовании своих подклассов, т к это откры, Аноним (11), 15:11 , 12-Фев-23, (14) +5
Коллеги, я в растерянности Такое впечатление, что вы вернулись к бредовым идеям, ACCA (ok), 03:54 , 13-Фев-23, (16) +3

Уважаемый b АССА b , уточните пожалуйста, что вы имеет в виду Самомодифицирую, Вервер (?), 17:18 , 13-Фев-23, (17) +3

Самомодифицирующийся код - это когда ты на асме берёшь и меняешь инструкции свое, Аноним (18), 13:59 , 15-Фев-23, (19) +2

Ну уж читать и википедию листать я и сам умею, и всё это конечно сразу после b , Вервер (?), 19:27 , 15-Фев-23, (22) +3

Фабричный метод с маппингом - подход имеющий право на жизнь Вопрос в том, для ч, Аноним (15), 18:55 , 12-Фев-23, (15) +8

Не хотел в нудные подробности углубляться, но если это поможет пониманию и оконк, Вервер (?), 19:57 , 15-Фев-23, (24) +3

Вроде понятно У вас контроллер компонует результаты дочерних контроллерчиков М, Аноним (25), 13:26 , 16-Фев-23, (25)

Блин Ну вот сама принципиально идея сохранять имена классов в БД Ну т е у, Вервер (?), 21:17 , 16-Фев-23, (26) +1

Вы можете туда интерфейс сохранять, а не конкретный класс И через DI контейнер , Аноним (25), 13:42 , 17-Фев-23, (27) +1

Пожалуйста объясните, что такое DI контейнер Просто пример в несколько строчек , Вервер (?), 21:15 , 17-Фев-23, (28) +1

На пальцах - это штука, которая знает, как инстанцировать объект указанного вами, Аноним (29), 14:59 , 20-Фев-23, (29)

Надо не играть в бабу Вангу и чётко спросить В чём смысол поделки, самопальная O, Аноним (18), 14:01 , 15-Фев-23, (20) +6

Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM,, Вервер (?), 19:30 , 15-Фев-23, (23) +6

Сообщения [Сортировка по времени | RSS]

1. "Какой верный путь для получения экземпляро объектов по их типу?" +8 +/–

Сообщение от Вервер (?), 11-Фев-23, 12:10

Ещё дополню, что почему не стал использовать вариант с получением условно по имени класса в переменной, у меня ощущение, что такое динамическое получение объекта чем то сродни exec(), а такого рода финты вроде не совсем правильно использовать. А варианты типов объектов класса свё равно же создаются и их можно сразу в перечисление switch case добавлять.

Ответить | Правка | Наверх | Cообщить модератору

3. "Какой верный путь для получения экземпляро объектов по их типу?" +6 +/–

Сообщение от Аноним (3), 11-Фев-23, 16:07

> Ещё дополню, что почему не стал использовать вариант с получением условно по
> имени класса в переменной, у меня ощущение, что такое динамическое получение
> объекта чем то сродни exec(), а такого рода финты вроде не
> совсем правильно использовать. А варианты типов объектов класса свё равно же
> создаются и их можно сразу в перечисление switch case добавлять.
>чем то сродни exec(), а такого рода финты вроде не совсем правильно использовать
eval и иже с ним плохи в первую очередь из-за того, что в них поступает непроверенный пользовательский код. Если оный в него не поступает, жить можно, вон, один язык на eval опирается как на основной способ расширения синтаксиса и ничего.

Ответить | Правка | Наверх | Cообщить модератору

8. "Какой верный путь для получения экземпляро объектов по их типу?" +5 +/–

Сообщение от Вервер (?), 11-Фев-23, 20:45

> eval и иже с ним плохи в первую очередь из-за того, что
> в них поступает непроверенный пользовательский код. Если оный в него не
> поступает, жить можно, вон, один язык на eval опирается как на
> основной способ расширения синтаксиса и ничего.
Да, точно спутал я exec с eval'ом. Предубеждение у меня к eval'у. Совсем противоестественно использовать эту конструкцию и никогда её не использую.

Ответить | Правка | Наверх | Cообщить модератору

10. "Какой верный путь для получения экземпляро объектов по их типу?" +4 +/–

Сообщение от Аноним (10), 12-Фев-23, 05:00

>А варианты типов объектов класса свё равно же создаются и их можно сразу в перечисление switch case добавлять.
Вот этот вариант подойдёт как решение наполовину (если вы это будете делать не в основном классе, а в подклассах на этапе инициализации класса или опосредованно через базовый класс, но динамически и опять же через инициализацию подкласса, базовый класс не должен знать все подклассы - не в курсе, как там оно именно делается в PHP, но механизм должен быть), но проще было бы динамически получать имя класса - если каких-то дополнительных трудностей нет.
А вообще, зачем вам получать потомков класса через базовый класс, а не через конструктор собственно потомка?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

12. "Какой верный путь для получения экземпляро объектов по их типу?" +6 +/–

Сообщение от Вервер (?), 12-Фев-23, 08:59

> А вообще, зачем вам получать потомков класса через базовый класс, а не
> через конструктор собственно потомка?
Потому что условно в БД хранится тип объекта (к примеру число objType), и мне чтобы через конструктор потомка получать экземпляр объекта - мне надо имя класса этого потомка знать по его objType? И потом делать этот озвученный "динамический трюк" $objItem=new $objClassName();
А как я узнаю, что в переменной $objClassName - корректное название класса?
Эта вот неоднозначность меня смущает. Я не могу понять - как получается в случае динамического варианта, что имя класса - экземпляр объекта которого я хочу получить - верное?

Ответить | Правка | Наверх | Cообщить модератору

18. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от Аноним (18), 15-Фев-23, 13:56

>А как я узнаю, что в переменной $objClassName - корректное название класса?
А оно надо? Кто пользователь ORM - программист или внешний пользователь, который про эти имена классов вообще знать ничего не должен?

Ответить | Правка | Наверх | Cообщить модератору

21. "Какой верный путь для получения экземпляро объектов по их типу?" +2 +/–

Сообщение от Вервер (?), 15-Фев-23, 19:25

> А оно надо? Кто пользователь ORM - программист или внешний пользователь, который
> про эти имена классов вообще знать ничего не должен?
Пользователь ORM - получается программист, т.е. Я. Она (типа ORM, хотя конечно нет) для построения логики с сущностями которые реализуют объекты в приложении. Но в любом случае неважно должен внешний пользователь знать про имена классов или нет, как для "динамического" варианта я должен соотнести objTypeID из базы с именем класса, чтобы выполнить итоговою строку
$objItem = new $objClassName();
? Варианта вижу 2:
Или в коде формировать связь objTypeID => objClassName, т.е.
$objTypeData = [
   Doc_Dogovor::OBJ_TYPE => 'Doc_Dogovor',
   Doc_Pismo::OBJ_TYPE => 'Doc_Pismo',
];
......
$objItem = new $objTypeData[$objTypeID]();

Либо в самой БД хранить не objTypeID - а сразу имя класса, но вроде это совсем грязь, хранить куски кода в БД.
Или я чего-то не понимаю?

Ответить | Правка | Наверх | Cообщить модератору

2. "Какой верный путь для получения экземпляро объектов по их типу?" +4 +/–

Сообщение от Аноним (3), 11-Фев-23, 16:03

>[оверквотинг удален]
> //Получить объект нужного типа (из БД к примеру тип приходит)
> $docObj = Document::getDocByType($neededTypeFromDB);
>
> Так вот вопрос собственно в том, насколько оправданно или наоборот плохо и
> как лучше всего такой тип задачи реализовывать?
> А задача значит получение экземпляра объекта указанного типа. Видел, что во всяких
> автозагрузчиках классов сейчас используется динамическое их получение условно такой схемой
> что если запрошенного класса нет, он подгружается по имени и дальше
> также создаётся объект класса, название которого в переменной
>
$docObj = new $objClassName();

Дяденька, а зачем вы диспатчите типы через enum, как будто у вас algebraic data types вместо классов?

Ответить | Правка | Наверх | Cообщить модератору

5. "Какой верный путь для получения экземпляро объектов по их типу?" +4 +/–

Сообщение от Вервер (?), 11-Фев-23, 20:42

> Дяденька, а зачем вы диспатчите типы через enum, как будто у вас
> algebraic data types вместо классов?
Я вообще не понял вашего словосочетания. Что значит, что я диспатчу? enum - это как раз реализация через их перечисление в switch {case..}?
А как правильней?

Ответить | Правка | Наверх | Cообщить модератору

4. "Какой верный путь для получения экземпляро объектов по их типу?" +5 +/–

Сообщение от Аноним (3), 11-Фев-23, 16:13

>Так вот вопрос собственно в том, насколько оправданно или наоборот плохо и как лучше всего такой тип задачи реализовывать?
А это вам как зайдёт, вот вы изобрели в пхп типы данных из хаскеля - осваивайте, укладывая мысль в них.

Ответить | Правка | Наверх | Cообщить модератору

6. "Какой верный путь для получения экземпляро объектов по их типу?" +4 +/–

Сообщение от Вервер (?), 11-Фев-23, 20:43

> А это вам как зайдёт, вот вы изобрели в пхп типы данных
> из хаскеля - осваивайте, укладывая мысль в них.
С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?

Ответить | Правка | Наверх | Cообщить модератору

9. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от Аноним (10), 12-Фев-23, 04:50

>С хаскелем не знаком кроме как слышал название этого языка.
Ознакомьтесь на досуге, такая штука есть во всех ML-подобных языках, Haskell, Ocaml, Standard ML и так далее. Заодно расширите кругозор и сможете писать на своём языке так, как раньше не писали, если в функциональном стиле не пишете (но тут было бы проще ознакомиться с Scheme, я учил ФП с него, правда вот алгебраических типов в нём нет).
Вы изобрели, грубо говоря, вот это:
data Point = Point2D Double Double | Point3D Double Double Double
В хаскеле это объявление записи по имени Point, у которой есть два варианта: Point2D из двух координат типа Double и Point3D из трёх координат. Тип Point закрытый - его нельзя расширить, при этом вся работа с данными в основном заворачивается на тип Point, а не на подтипы. В языках же с классами и их наследованием класс, как правило, открытый - на основе одного класса вы можете сделать очень много потомков и подпотомков, при этом основные методы родительского класса должны работать при этом без особых изменений. И вот своим case по тегам подтипов в родительском классе вы нарушаете наследование без проволочек, превращая тип в закрытый, как в хаскеле. Разумеется, после этого вам и придётся со временем всё больше работать со своим типом так, как будто он нерасширяемый.

Ответить | Правка | Наверх | Cообщить модератору

7. "Какой верный путь для получения экземпляро объектов по их типу?" +5 +/–

Сообщение от Вервер (?), 11-Фев-23, 20:44

> А это вам как зайдёт, вот вы изобрели в пхп типы данных
> из хаскеля - осваивайте, укладывая мысль в них.
С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

11. "Какой верный путь для получения экземпляро объектов по их типу?" +5 +/–

Сообщение от Аноним (11), 12-Фев-23, 07:01

сделай обычный class Document. От него наследуются class Dogovor и class Pismo (еще обзови их class DoroBop и class nuCbMo, раз так фанатеешь от русских названий - сарказм на всякий случай). Класс Document при этом не должен знать о существовании своих подклассов и никак их не упоминать. Далее создай в совершенно отдельном месте функцию, которая принимает $typeFromDb и делает по нему return new КонкретныйКласс, можно через switch.

Ответить | Правка | Наверх | Cообщить модератору

13. "Какой верный путь для получения экземпляро объектов по их типу?" +6 +/–

Сообщение от Вервер (?), 12-Фев-23, 09:04

> сделай обычный class Document. От него наследуются class Dogovor и class Pismo
> (еще обзови их class DoroBop и class nuCbMo, раз так фанатеешь
> от русских названий - сарказм на всякий случай). Класс Document при
> этом не должен знать о существовании своих подклассов и никак их
> не упоминать. Далее создай в совершенно отдельном месте функцию, которая принимает
> $typeFromDb и делает по нему return new КонкретныйКласс, можно через switch.
Если что, на самом деле эти Документы, Договора и Письма - чистая выдумка для иллюстрации. С моей текущей задачей конкретно такие сущности никак не связаны.
По поводу организации функцией, а не в родительском классе - в чём у такого подхода принципиальная выгода или "правильность"?

Ответить | Правка | Наверх | Cообщить модератору

14. "Какой верный путь для получения экземпляро объектов по их типу?" +5 +/–

Сообщение от Аноним (11), 12-Фев-23, 15:11

> По поводу организации функцией, а не в родительском классе - в чём
> у такого подхода принципиальная выгода или "правильность"?
Класс Document не должен знать о существовании своих подклассов, т. к. это открытый класс. Я могу написать по месту ад-хок class Issue1488_Document extends Document специально для юнит-теста, и мне не придется вводить фуфловый $docType = 1488, которого в базе естессно не будет. Функция -- это пример для простейших систем без подгрузки кода по требованию. Я могу представить себе систему, в которой class LetterDocument подгружается только тогда, когда он реально нужен. В этой системе модуль "поддержки писем" зарегистрировал бы docType под номером 420 и указал бы, что "если встретишь docType = 420, то загрузи такой-то класс из такого-то файла, а я гарантирую, что это будет подкласс от Document". Похожим образом делает линукс с драйверами: встретив PCI-устройство, линукс смотрит в свой modalias на предмет того, нет ли модуля, предоставляющего драйвер для PCI-устройства с таким-то идентификатором, и если есть - загружает его.

Ответить | Правка | Наверх | Cообщить модератору

16. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от ACCA (ok), 13-Фев-23, 03:54

Коллеги, я в растерянности. Такое впечатление, что вы вернулись к бредовым идеям самомодифицирующегося кода.
А ничё, что вас там ждёт cyclomatic complexity?

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

17. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от Вервер (?), 13-Фев-23, 17:18

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

Ответить | Правка | Наверх | Cообщить модератору

19. "Какой верный путь для получения экземпляро объектов по их типу?" +2 +/–

Сообщение от Аноним (18), 15-Фев-23, 13:59

Самомодифицирующийся код - это когда ты на асме берёшь и меняешь инструкции своей собственной программы.

Ответить | Правка | Наверх | Cообщить модератору

22. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от Вервер (?), 15-Фев-23, 19:27

> Самомодифицирующийся код - это когда ты на асме берёшь и меняешь инструкции
> своей собственной программы.
Ну уж читать и википедию листать я и сам умею, и всё это конечно сразу после АССА'вого коммента прочитал. Я не понял как это к обсуждению относится. Про это и спросил.

Ответить | Правка | Наверх | Cообщить модератору

15. "Какой верный путь для получения экземпляро объектов по их типу?" +8 +/–

Сообщение от Аноним (15), 12-Фев-23, 18:55

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

Ответить | Правка | Наверх | Cообщить модератору

24. "Какой верный путь для получения экземпляро объектов по их типу?" +3 +/–

Сообщение от Вервер (?), 15-Фев-23, 19:57

> Фабричный метод с маппингом - подход имеющий право на жизнь. Вопрос в
> том, для чего это применять.
> Очевидно, что у вас есть некая универсальная форма, которая посылает ид типа
> создаваемого документа. И дальше вы создаете документ исходя из его ид.
> И в базу потом пишете с тем же самым ид.
> Вместо этого можно для каждого типа документа сделать свои формы, тип создаваемого
> документа разруливать по маршруту обработчика, ид для базы держать в константе
> класса и работать с ним только при записи в базу -
> то есть, в контроллере вообще никогда.
Не хотел в нудные подробности углубляться, но если это поможет пониманию и оконкретит что главное как лучше это реализовать, то вот, опишу более полно и близко к оригиналу:
Есть такая сущность, как Статья. Это сущность из которой будет формироваться условно страница с самой этой Статьёй:

//Отображение её в БД
TABLE Article (
    id     SERIAL PRIMARY KEY,
    title  CHAR(20) NOT NULL
)

Статья состоит из кусков разных типов объектов - Частей Статьи.

//Отображение Частей Статьи в БД
TABLE ArticleParts (
    id     SERIAL PRIMARY KEY,
artID     BIGINT UNSIGNED NOT NULL,
partType   TINYINT UNSIGNED NOT NULL,
partOrder  TINYINT UNSIGNED NOT NULL,
    FK(artID) => Article(id)
)

Так вот поле partType - это как раз тот самый objTypeID по которому мы понимаем Часть Статьи какого типа это:

//Общий предок Частей Статьи
Class ArticlePart {
    const PART_TEXT;        //Чисто текстовый блок
    const PART_IMG_GALLERY; //Набор картинок в блоке
    const PAT_POLL;         //Блок с голосованием
    .......
    //Получить объект нужного типа
    static public & getPartObjByType($objType){
        $objItem = false;
        switch($objType){
             case ...:
                 $objItem = ....;
                 break;
             .... ......
        }
    }
}
//Классы самих Частей Статьи
Class ArticlePart_TEXT extends ArticlePart {
    static const OBJ_TYPE = ArticlePart::PART_TEXT;
    //У каждого вида Части Статьи свой способ оформления в БД,
    //со своими таблицами и связями и пр.
    public function DB_Save(){
        .....
    }
    //Тут к примеру у каждого вида Части Статьи своя генерация HTML под него
    public function getHTML(){
        .....
    }
}
И условно статью предполагается создавать из таких вот блоков разных типов. Они могут быть интерактивными, каждый из блоков, со своей связанной с пользователем информацией и пр.
А уже как у статьи в общем может быть там пагинация и прочая херня. Короче велосипед, но мой и хочу чтобы колёса сразу квадратными не выбирались :)

Ответить | Правка | Наверх | Cообщить модератору

25. "Какой верный путь для получения экземпляро объектов по их типу?" +/–

Сообщение от Аноним (25), 16-Фев-23, 13:26

Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена классов просто в базу сохранять, без искусственных partType. Выборок по этим ид нет же?

Ответить | Правка | Наверх | Cообщить модератору

26. "Какой верный путь для получения экземпляро объектов по их типу?" +1 +/–

Сообщение от Вервер (?), 16-Фев-23, 21:17

> Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена
> классов просто в базу сохранять, без искусственных partType. Выборок по этим
> ид нет же?
Блин... Ну вот сама принципиально идея сохранять имена классов в БД...
Ну т.е. условно есть скептическое отношение к языку basic, оператору goto, к использованию непроверенного пользовательского ввода во всякого рода SQL-инъекциях, к использованию конструкции eval, не является ли использование данных из БД в качестве исполняемого кода - плохой практикой?
Ведь если в БД хранится имя класса, то мы должны использовать что-то типа:
$objItem = $stringFromDB();
. Т.е. как я вижу это - есть концепция "динамического кода", когда сам код программы - неясен на момент исполнения, и во время него более того тоже меняется.
Т.к. в процессе исполнения получается сам код программы становится результатом его работы.
А есть условно "статический код", т.е. в ближайшем приближении - код который можно скомпилировать в исполняемый файл и запустить сам по себе. Всякие eval() и $objFromString() вроде бы представляют собой часть динамической составляющей.
Вот я и хочу разобраться, насколько это имеет смысл. Я так понял, что среди плюсов динамического подхода: Проще реализация - исключаем часть "конечного автомата по выбору класса для Объекта"
Минусы у динамики - Смешение кода и данных, т.к. код для создания объекта берётся в любом случае из внешнего источника (БД или Роутинг из URL), также я думаю к минусам можно отнести скорость исполнения (если динамически инклудить файлы с описанием класса для Объекта)
Плюсы и минусы у Статики - соответственно противоположные.
Так ли это? Какие ещё есть варианты реализации таких вот как Товарищ выше описал "Контроллеров" и их "Контроллерчиков"?

Ответить | Правка | Наверх | Cообщить модератору

27. "Какой верный путь для получения экземпляро объектов по их типу?" +1 +/–

Сообщение от Аноним (25), 17-Фев-23, 13:42

> Блин... Ну вот сама принципиально идея сохранять имена классов в БД...
Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI контейнер получать конкретную реализацию. Это вот именно то, что вы хотите в плане поведения, на самом деле.
Айдишки искусственны, удобства от них имеют косвенный характер. Будь у вас документо-ориентированная БД и вам бы в голову не пришло их использовать.
Хранить в базе код и эвалом исполнять - это фактически serverless концепция, вроде AWS Lambda. Так тоже можно! Любые извращения возможны. Если вам доставляет разбираться в этих концепциях, писать свои реализации - это одна история. Если нужно сделать, чтобы работало (и забыть) - другая. Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет.

Ответить | Правка | Наверх | Cообщить модератору

28. "Какой верный путь для получения экземпляро объектов по их типу?" +1 +/–

Сообщение от Вервер (?), 17-Фев-23, 21:15

> Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI
> контейнер получать конкретную реализацию. Это вот именно то, что вы хотите
> в плане поведения, на самом деле.
Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для иллюстрации. Я абсолютно не понимаю, о чём речь.

> Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет.
Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики объектов". Это, если я правильно понял суть реплики, не просто код для изучения концепции с теоретической целью. Цель вполне себе ясная, а этот вопрос встал на этапе реализации некоторых сущностей.

Ответить | Правка | Наверх | Cообщить модератору

29. "Какой верный путь для получения экземпляро объектов по их типу?" +/–

Сообщение от Аноним (29), 20-Фев-23, 14:59

> Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для
> иллюстрации. Я абсолютно не понимаю, о чём речь.
На пальцах - это штука, которая знает, как инстанцировать объект указанного вами класса, чтобы вы могли не заниматься этим в своем коде. Дергаете ее либо вручную, либо она автомагически создает для вас объекты в аргументы методов ваших классов.
https://laravel.com/docs/10.x/container
https://symfony.com/doc/current/components/dependency_inject...
> Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики
> объектов". Это, если я правильно понял суть реплики, не просто код
> для изучения концепции с теоретической целью. Цель вполне себе ясная, а
> этот вопрос встал на этапе реализации некоторых сущностей.
Вы могли бы взять любой из фреймворков, где уже все есть, и не создавать собственные реализации, эволюционируя от более примитивных концепций к более продвинутым. Процесс увлекательный, не спорю.

Ответить | Правка | Наверх | Cообщить модератору

20. "Какой верный путь для получения экземпляро объектов по их типу?" +6 +/–

Сообщение от Аноним (18), 15-Фев-23, 14:01

Надо не играть в бабу Вангу и чётко спросить:
>Я тут пишу свои всякие поделки
В чём смысол поделки, самопальная ORM?

Ответить | Правка | Наверх | Cообщить модератору

23. "Какой верный путь для получения экземпляро объектов по их типу?" +6 +/–

Сообщение от Вервер (?), 15-Фев-23, 19:30

> Надо не играть в бабу Вангу и чётко спросить:
>>Я тут пишу свои всякие поделки
> В чём смысол поделки, самопальная ORM?
Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM, но оно не самоцель, а лишь часть в моей общей замути. Спрашиваю, чтобы на этапе пока не накодил много объектов выбранным (и опробованным) способом который в вопросе и описал, и не пришлось потом всё перелопачивать из-за того, что выбранный способ унылый.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Какой верный путь для получения экземпляро объектов по их типу?"	+8 +/–
Сообщение от Вервер (?), 11-Фев-23, 12:10
Ещё дополню, что почему не стал использовать вариант с получением условно по имени класса в переменной, у меня ощущение, что такое динамическое получение объекта чем то сродни exec(), а такого рода финты вроде не совсем правильно использовать. А варианты типов объектов класса свё равно же создаются и их можно сразу в перечисление switch case добавлять.
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Какой верный путь для получения экземпляро объектов по их типу?"	+6 +/–
	Сообщение от Аноним (3), 11-Фев-23, 16:07
	> Ещё дополню, что почему не стал использовать вариант с получением условно по > имени класса в переменной, у меня ощущение, что такое динамическое получение > объекта чем то сродни exec(), а такого рода финты вроде не > совсем правильно использовать. А варианты типов объектов класса свё равно же > создаются и их можно сразу в перечисление switch case добавлять. >чем то сродни exec(), а такого рода финты вроде не совсем правильно использовать eval и иже с ним плохи в первую очередь из-за того, что в них поступает непроверенный пользовательский код. Если оный в него не поступает, жить можно, вон, один язык на eval опирается как на основной способ расширения синтаксиса и ничего.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Какой верный путь для получения экземпляро объектов по их типу?"	+5 +/–
	Сообщение от Вервер (?), 11-Фев-23, 20:45
	> eval и иже с ним плохи в первую очередь из-за того, что > в них поступает непроверенный пользовательский код. Если оный в него не > поступает, жить можно, вон, один язык на eval опирается как на > основной способ расширения синтаксиса и ничего. Да, точно спутал я exec с eval'ом. Предубеждение у меня к eval'у. Совсем противоестественно использовать эту конструкцию и никогда её не использую.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Какой верный путь для получения экземпляро объектов по их типу?"	+4 +/–
	Сообщение от Аноним (10), 12-Фев-23, 05:00
	>А варианты типов объектов класса свё равно же создаются и их можно сразу в перечисление switch case добавлять. Вот этот вариант подойдёт как решение наполовину (если вы это будете делать не в основном классе, а в подклассах на этапе инициализации класса или опосредованно через базовый класс, но динамически и опять же через инициализацию подкласса, базовый класс не должен знать все подклассы - не в курсе, как там оно именно делается в PHP, но механизм должен быть), но проще было бы динамически получать имя класса - если каких-то дополнительных трудностей нет. А вообще, зачем вам получать потомков класса через базовый класс, а не через конструктор собственно потомка?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	12. "Какой верный путь для получения экземпляро объектов по их типу?"	+6 +/–
	Сообщение от Вервер (?), 12-Фев-23, 08:59
	> А вообще, зачем вам получать потомков класса через базовый класс, а не > через конструктор собственно потомка? Потому что условно в БД хранится тип объекта (к примеру число objType), и мне чтобы через конструктор потомка получать экземпляр объекта - мне надо имя класса этого потомка знать по его objType? И потом делать этот озвученный "динамический трюк" $objItem=new $objClassName(); А как я узнаю, что в переменной $objClassName - корректное название класса? Эта вот неоднозначность меня смущает. Я не могу понять - как получается в случае динамического варианта, что имя класса - экземпляр объекта которого я хочу получить - верное?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от Аноним (18), 15-Фев-23, 13:56
	>А как я узнаю, что в переменной $objClassName - корректное название класса? А оно надо? Кто пользователь ORM - программист или внешний пользователь, который про эти имена классов вообще знать ничего не должен?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Какой верный путь для получения экземпляро объектов по их типу?"	+2 +/–
	Сообщение от Вервер (?), 15-Фев-23, 19:25
	> А оно надо? Кто пользователь ORM - программист или внешний пользователь, который > про эти имена классов вообще знать ничего не должен? Пользователь ORM - получается программист, т.е. Я. Она (типа ORM, хотя конечно нет) для построения логики с сущностями которые реализуют объекты в приложении. Но в любом случае неважно должен внешний пользователь знать про имена классов или нет, как для "динамического" варианта я должен соотнести objTypeID из базы с именем класса, чтобы выполнить итоговою строку $objItem = new $objClassName(); ? Варианта вижу 2: Или в коде формировать связь objTypeID => objClassName, т.е. $objTypeData = [ Doc_Dogovor::OBJ_TYPE => 'Doc_Dogovor', Doc_Pismo::OBJ_TYPE => 'Doc_Pismo', ]; ...... $objItem = new $objTypeData[$objTypeID](); Либо в самой БД хранить не objTypeID - а сразу имя класса, но вроде это совсем грязь, хранить куски кода в БД. Или я чего-то не понимаю?
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Какой верный путь для получения экземпляро объектов по их типу?"	+4 +/–
Сообщение от Аноним (3), 11-Фев-23, 16:03
>[оверквотинг удален] > //Получить объект нужного типа (из БД к примеру тип приходит) > $docObj = Document::getDocByType($neededTypeFromDB); > > Так вот вопрос собственно в том, насколько оправданно или наоборот плохо и > как лучше всего такой тип задачи реализовывать? > А задача значит получение экземпляра объекта указанного типа. Видел, что во всяких > автозагрузчиках классов сейчас используется динамическое их получение условно такой схемой > что если запрошенного класса нет, он подгружается по имени и дальше > также создаётся объект класса, название которого в переменной > $docObj = new $objClassName(); Дяденька, а зачем вы диспатчите типы через enum, как будто у вас algebraic data types вместо классов?
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Какой верный путь для получения экземпляро объектов по их типу?"	+4 +/–
	Сообщение от Вервер (?), 11-Фев-23, 20:42
	> Дяденька, а зачем вы диспатчите типы через enum, как будто у вас > algebraic data types вместо классов? Я вообще не понял вашего словосочетания. Что значит, что я диспатчу? enum - это как раз реализация через их перечисление в switch {case..}? А как правильней?
	Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Какой верный путь для получения экземпляро объектов по их типу?"	+5 +/–
Сообщение от Аноним (3), 11-Фев-23, 16:13
>Так вот вопрос собственно в том, насколько оправданно или наоборот плохо и как лучше всего такой тип задачи реализовывать? А это вам как зайдёт, вот вы изобрели в пхп типы данных из хаскеля - осваивайте, укладывая мысль в них.
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Какой верный путь для получения экземпляро объектов по их типу?"	+4 +/–
	Сообщение от Вервер (?), 11-Фев-23, 20:43
	> А это вам как зайдёт, вот вы изобрели в пхп типы данных > из хаскеля - осваивайте, укладывая мысль в них. С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от Аноним (10), 12-Фев-23, 04:50
	>С хаскелем не знаком кроме как слышал название этого языка. Ознакомьтесь на досуге, такая штука есть во всех ML-подобных языках, Haskell, Ocaml, Standard ML и так далее. Заодно расширите кругозор и сможете писать на своём языке так, как раньше не писали, если в функциональном стиле не пишете (но тут было бы проще ознакомиться с Scheme, я учил ФП с него, правда вот алгебраических типов в нём нет). Вы изобрели, грубо говоря, вот это: data Point = Point2D Double Double \| Point3D Double Double Double В хаскеле это объявление записи по имени Point, у которой есть два варианта: Point2D из двух координат типа Double и Point3D из трёх координат. Тип Point закрытый - его нельзя расширить, при этом вся работа с данными в основном заворачивается на тип Point, а не на подтипы. В языках же с классами и их наследованием класс, как правило, открытый - на основе одного класса вы можете сделать очень много потомков и подпотомков, при этом основные методы родительского класса должны работать при этом без особых изменений. И вот своим case по тегам подтипов в родительском классе вы нарушаете наследование без проволочек, превращая тип в закрытый, как в хаскеле. Разумеется, после этого вам и придётся со временем всё больше работать со своим типом так, как будто он нерасширяемый.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Какой верный путь для получения экземпляро объектов по их типу?"	+5 +/–
	Сообщение от Вервер (?), 11-Фев-23, 20:44
	> А это вам как зайдёт, вот вы изобрели в пхп типы данных > из хаскеля - осваивайте, укладывая мысль в них. С хаскелем не знаком кроме как слышал название этого языка. Можете пожалуйста пояснить, что я изобрёл и во что мне надо укладывать мысль?
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору

11. "Какой верный путь для получения экземпляро объектов по их типу?"	+5 +/–
Сообщение от Аноним (11), 12-Фев-23, 07:01
сделай обычный class Document. От него наследуются class Dogovor и class Pismo (еще обзови их class DoroBop и class nuCbMo, раз так фанатеешь от русских названий - сарказм на всякий случай). Класс Document при этом не должен знать о существовании своих подклассов и никак их не упоминать. Далее создай в совершенно отдельном месте функцию, которая принимает $typeFromDb и делает по нему return new КонкретныйКласс, можно через switch.
Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Какой верный путь для получения экземпляро объектов по их типу?"	+6 +/–
	Сообщение от Вервер (?), 12-Фев-23, 09:04
	> сделай обычный class Document. От него наследуются class Dogovor и class Pismo > (еще обзови их class DoroBop и class nuCbMo, раз так фанатеешь > от русских названий - сарказм на всякий случай). Класс Document при > этом не должен знать о существовании своих подклассов и никак их > не упоминать. Далее создай в совершенно отдельном месте функцию, которая принимает > $typeFromDb и делает по нему return new КонкретныйКласс, можно через switch. Если что, на самом деле эти Документы, Договора и Письма - чистая выдумка для иллюстрации. С моей текущей задачей конкретно такие сущности никак не связаны. По поводу организации функцией, а не в родительском классе - в чём у такого подхода принципиальная выгода или "правильность"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Какой верный путь для получения экземпляро объектов по их типу?"	+5 +/–
	Сообщение от Аноним (11), 12-Фев-23, 15:11
	> По поводу организации функцией, а не в родительском классе - в чём > у такого подхода принципиальная выгода или "правильность"? Класс Document не должен знать о существовании своих подклассов, т. к. это открытый класс. Я могу написать по месту ад-хок class Issue1488_Document extends Document специально для юнит-теста, и мне не придется вводить фуфловый $docType = 1488, которого в базе естессно не будет. Функция -- это пример для простейших систем без подгрузки кода по требованию. Я могу представить себе систему, в которой class LetterDocument подгружается только тогда, когда он реально нужен. В этой системе модуль "поддержки писем" зарегистрировал бы docType под номером 420 и указал бы, что "если встретишь docType = 420, то загрузи такой-то класс из такого-то файла, а я гарантирую, что это будет подкласс от Document". Похожим образом делает линукс с драйверами: встретив PCI-устройство, линукс смотрит в свой modalias на предмет того, нет ли модуля, предоставляющего драйвер для PCI-устройства с таким-то идентификатором, и если есть - загружает его.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от ACCA (ok), 13-Фев-23, 03:54
	Коллеги, я в растерянности. Такое впечатление, что вы вернулись к бредовым идеям самомодифицирующегося кода. А ничё, что вас там ждёт cyclomatic complexity?
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	17. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от Вервер (?), 13-Фев-23, 17:18
	> Коллеги, я в растерянности. Такое впечатление, что вы вернулись к бредовым идеям > самомодифицирующегося кода. > А ничё, что вас там ждёт cyclomatic complexity? Уважаемый АССА, уточните пожалуйста, что вы имеет в виду? Самомодифицирующийся код - это в смысле динамическая подгрузка классов или наоборот фабрика которую я начал обсуждать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Какой верный путь для получения экземпляро объектов по их типу?"	+2 +/–
	Сообщение от Аноним (18), 15-Фев-23, 13:59
	Самомодифицирующийся код - это когда ты на асме берёшь и меняешь инструкции своей собственной программы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от Вервер (?), 15-Фев-23, 19:27
	> Самомодифицирующийся код - это когда ты на асме берёшь и меняешь инструкции > своей собственной программы. Ну уж читать и википедию листать я и сам умею, и всё это конечно сразу после АССА'вого коммента прочитал. Я не понял как это к обсуждению относится. Про это и спросил.
	Ответить \| Правка \| Наверх \| Cообщить модератору

15. "Какой верный путь для получения экземпляро объектов по их типу?"	+8 +/–
Сообщение от Аноним (15), 12-Фев-23, 18:55
Фабричный метод с маппингом - подход имеющий право на жизнь. Вопрос в том, для чего это применять. Очевидно, что у вас есть некая универсальная форма, которая посылает ид типа создаваемого документа. И дальше вы создаете документ исходя из его ид. И в базу потом пишете с тем же самым ид. Вместо этого можно для каждого типа документа сделать свои формы, тип создаваемого документа разруливать по маршруту обработчика, ид для базы держать в константе класса и работать с ним только при записи в базу - то есть, в контроллере вообще никогда.
Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Какой верный путь для получения экземпляро объектов по их типу?"	+3 +/–
	Сообщение от Вервер (?), 15-Фев-23, 19:57
	> Фабричный метод с маппингом - подход имеющий право на жизнь. Вопрос в > том, для чего это применять. > Очевидно, что у вас есть некая универсальная форма, которая посылает ид типа > создаваемого документа. И дальше вы создаете документ исходя из его ид. > И в базу потом пишете с тем же самым ид. > Вместо этого можно для каждого типа документа сделать свои формы, тип создаваемого > документа разруливать по маршруту обработчика, ид для базы держать в константе > класса и работать с ним только при записи в базу - > то есть, в контроллере вообще никогда. Не хотел в нудные подробности углубляться, но если это поможет пониманию и оконкретит что главное как лучше это реализовать, то вот, опишу более полно и близко к оригиналу: Есть такая сущность, как Статья. Это сущность из которой будет формироваться условно страница с самой этой Статьёй: //Отображение её в БД TABLE Article ( id SERIAL PRIMARY KEY, title CHAR(20) NOT NULL ) Статья состоит из кусков разных типов объектов - Частей Статьи. //Отображение Частей Статьи в БД TABLE ArticleParts ( id SERIAL PRIMARY KEY, artID BIGINT UNSIGNED NOT NULL, partType TINYINT UNSIGNED NOT NULL, partOrder TINYINT UNSIGNED NOT NULL, FK(artID) => Article(id) ) Так вот поле partType - это как раз тот самый objTypeID по которому мы понимаем Часть Статьи какого типа это: //Общий предок Частей Статьи Class ArticlePart { const PART_TEXT; //Чисто текстовый блок const PART_IMG_GALLERY; //Набор картинок в блоке const PAT_POLL; //Блок с голосованием ....... //Получить объект нужного типа static public & getPartObjByType($objType){ $objItem = false; switch($objType){ case ...: $objItem = ....; break; .... ...... } } } //Классы самих Частей Статьи Class ArticlePart_TEXT extends ArticlePart { static const OBJ_TYPE = ArticlePart::PART_TEXT; //У каждого вида Части Статьи свой способ оформления в БД, //со своими таблицами и связями и пр. public function DB_Save(){ ..... } //Тут к примеру у каждого вида Части Статьи своя генерация HTML под него public function getHTML(){ ..... } } И условно статью предполагается создавать из таких вот блоков разных типов. Они могут быть интерактивными, каждый из блоков, со своей связанной с пользователем информацией и пр. А уже как у статьи в общем может быть там пагинация и прочая херня. Короче велосипед, но мой и хочу чтобы колёса сразу квадратными не выбирались :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Какой верный путь для получения экземпляро объектов по их типу?"	+/–
	Сообщение от Аноним (25), 16-Фев-23, 13:26
	Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена классов просто в базу сохранять, без искусственных partType. Выборок по этим ид нет же?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Какой верный путь для получения экземпляро объектов по их типу?"	+1 +/–
	Сообщение от Вервер (?), 16-Фев-23, 21:17
	> Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена > классов просто в базу сохранять, без искусственных partType. Выборок по этим > ид нет же? Блин... Ну вот сама принципиально идея сохранять имена классов в БД... Ну т.е. условно есть скептическое отношение к языку basic, оператору goto, к использованию непроверенного пользовательского ввода во всякого рода SQL-инъекциях, к использованию конструкции eval, не является ли использование данных из БД в качестве исполняемого кода - плохой практикой? Ведь если в БД хранится имя класса, то мы должны использовать что-то типа: $objItem = $stringFromDB(); . Т.е. как я вижу это - есть концепция "динамического кода", когда сам код программы - неясен на момент исполнения, и во время него более того тоже меняется. Т.к. в процессе исполнения получается сам код программы становится результатом его работы. А есть условно "статический код", т.е. в ближайшем приближении - код который можно скомпилировать в исполняемый файл и запустить сам по себе. Всякие eval() и $objFromString() вроде бы представляют собой часть динамической составляющей. Вот я и хочу разобраться, насколько это имеет смысл. Я так понял, что среди плюсов динамического подхода: Проще реализация - исключаем часть "конечного автомата по выбору класса для Объекта" Минусы у динамики - Смешение кода и данных, т.к. код для создания объекта берётся в любом случае из внешнего источника (БД или Роутинг из URL), также я думаю к минусам можно отнести скорость исполнения (если динамически инклудить файлы с описанием класса для Объекта) Плюсы и минусы у Статики - соответственно противоположные. Так ли это? Какие ещё есть варианты реализации таких вот как Товарищ выше описал "Контроллеров" и их "Контроллерчиков"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Какой верный путь для получения экземпляро объектов по их типу?"	+1 +/–
	Сообщение от Аноним (25), 17-Фев-23, 13:42
	> Блин... Ну вот сама принципиально идея сохранять имена классов в БД... Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI контейнер получать конкретную реализацию. Это вот именно то, что вы хотите в плане поведения, на самом деле. Айдишки искусственны, удобства от них имеют косвенный характер. Будь у вас документо-ориентированная БД и вам бы в голову не пришло их использовать. Хранить в базе код и эвалом исполнять - это фактически serverless концепция, вроде AWS Lambda. Так тоже можно! Любые извращения возможны. Если вам доставляет разбираться в этих концепциях, писать свои реализации - это одна история. Если нужно сделать, чтобы работало (и забыть) - другая. Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Какой верный путь для получения экземпляро объектов по их типу?"	+1 +/–
	Сообщение от Вервер (?), 17-Фев-23, 21:15
	> Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI > контейнер получать конкретную реализацию. Это вот именно то, что вы хотите > в плане поведения, на самом деле. Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для иллюстрации. Я абсолютно не понимаю, о чём речь. > Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет. Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики объектов". Это, если я правильно понял суть реплики, не просто код для изучения концепции с теоретической целью. Цель вполне себе ясная, а этот вопрос встал на этапе реализации некоторых сущностей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Какой верный путь для получения экземпляро объектов по их типу?"	+/–
	Сообщение от Аноним (29), 20-Фев-23, 14:59
	> Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для > иллюстрации. Я абсолютно не понимаю, о чём речь. На пальцах - это штука, которая знает, как инстанцировать объект указанного вами класса, чтобы вы могли не заниматься этим в своем коде. Дергаете ее либо вручную, либо она автомагически создает для вас объекты в аргументы методов ваших классов. https://laravel.com/docs/10.x/container https://symfony.com/doc/current/components/dependency_inject... > Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики > объектов". Это, если я правильно понял суть реплики, не просто код > для изучения концепции с теоретической целью. Цель вполне себе ясная, а > этот вопрос встал на этапе реализации некоторых сущностей. Вы могли бы взять любой из фреймворков, где уже все есть, и не создавать собственные реализации, эволюционируя от более примитивных концепций к более продвинутым. Процесс увлекательный, не спорю.
	Ответить \| Правка \| Наверх \| Cообщить модератору

20. "Какой верный путь для получения экземпляро объектов по их типу?"	+6 +/–
Сообщение от Аноним (18), 15-Фев-23, 14:01
Надо не играть в бабу Вангу и чётко спросить: >Я тут пишу свои всякие поделки В чём смысол поделки, самопальная ORM?
Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Какой верный путь для получения экземпляро объектов по их типу?"	+6 +/–
	Сообщение от Вервер (?), 15-Фев-23, 19:30
	> Надо не играть в бабу Вангу и чётко спросить: >>Я тут пишу свои всякие поделки > В чём смысол поделки, самопальная ORM? Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM, но оно не самоцель, а лишь часть в моей общей замути. Спрашиваю, чтобы на этапе пока не накодил много объектов выбранным (и опробованным) способом который в вопросе и описал, и не пришлось потом всё перелопачивать из-за того, что выбранный способ унылый.
	Ответить \| Правка \| Наверх \| Cообщить модератору