пул объектов

[domino]

пул объектов

доброе время суток.
объекты классов создаются без использования синглтона.
для этого существует класс objects_pool у которого есть массив (пул) объектов. при создании объекта запрашивается метод пула get_instance в котором происходит проверка - существует ли объект в пуле - если да, то вернуть его, если нет, то создать, записать в пул и вернуть.

возникает вопрос - имеет ли вообще смысл такой класс?

что будет хранится в элементах такого массива - ссылки на классы в памяти или действительно сами классы?
если ссылки на память, то мы всё равно фактически не управляем местом хранения классов, так имеет ли смысл такой класс как пул объектов?

 

[rotoZOOM]

Пачетай тут

 

[whirlwind]

> ссылки на классы в памяти или действительно сами классы?

Вот это можно еще раз поподробнее?

 

[Angerslave]

domino
Если хочешь реализовать массив Singleton'ов для классов, то следует вызывать, скажем, STPool::getInstance('SomeClass', $var1, $var2...);, который будет проверять, есть ли в массиве созданных синглтонов объект заданного класса, если есть - отдавать его, иначе - создавать с введёнными параметрами, записывать в массив по ключу имени класса и отдавать.

Смысл... Ну, если тебе будет нужно быстро реализовать синглтоны для множества классов, которые на это не расчитаны, то будет смысл. Но, скорее всего, проще в нужные классы непосредственно внедрить синглтон-код.

А в массиве будут храниться ссылки на объекты.

 

[domino]

2 Angerslave:
ты пишешь - если хочешь реализовать и т.д. - это реализовано ) не переписвай мне как работает мой класс. я знаю. внедрить сингтон код не проще, т.к. нужно копировать один и тот же метод в каждый класс проекта. не очень прикольно.

2 whirlwind:
имеется ввиду, что если бы мы сделали бы такую штуку для с/с++, то мы бы точно были уверены, что код my_array[xxx] = new A(); создаст в памяти экземпляр класса А по адресу *my_array[xxx].
это может быть полезным, если мы например заюзаем какой-нить глобальный указатель на метод класса и будем перемещать его по массиву вызывая таким образом методы класса по какому-то алгоритму.

в пхп мы не можем управлять памятью и не знаем где фактически хранятся созданные объекты. т.е. попытка написать $my_array['class_name'] = new A(); не создаст экземпляр А по адресу $my_array['class_name'] (хотя, я не знаю точно потому и спрашиваю), а скорее всего, объект А создастся где-то в памяти, а в элемент масстива скопируется ссылка на начало этого объекта в памяти.

вот и возникает вопрос - есть ли смысл в существовании такого класса, как пул объектов. сначала это показалось крутым мы сделали два основных класса - пул данных и пул объектов.
ну, с пулом данных всё ясно - он стандартизирует передачу данных по всему проекту и если данные лежат в пуле, то им можно на 100% доверять. это работает классно и красиво. и иногда даже даёт такие интересные эффекты о коотрых мы даже не оч. задумывались при проектировании. например, создание шредов получилось просто с полтычка - на каждом шаги сохранил данные в data_pool и вот тебе все шреды. а вот с пулом объектов возникли проблемы. т.к. изначально пул предоставлял метод get_instance и этот метод был public сейчас мы его сделали protected и встал вопрос - а нужен ли вообще этот пул.

get_instance понадобилось делать protected потому что все новички на проекте норовили сделать факин хак и если им нужен был например объект для работы с доступом к базе не использовали нормальный подход, который был заложен при проектировании и позволял написать в любом классе что-то в духе $this->core->select() а использовали $obj = $this->core->get_instance('mysql'); $obj->select(). после закрытия метода гет_инстанс мы заставили всех юзать именно открытые интерфейсы на каждом уровне - ядро, выше, выше и т.д.

 

[Angerslave]

domino
Тебе в каждом классе проекта нужен Singleton? 0_o

 

[domino]

2 Angerslave
чувак, ты понимаешь чё я спрашиваю или как? у меня вообще нету синглтонов в проекте. в данный момент.

 

[john.brown]

у меня вообще нету синглтонов в проекте

проверка - существует ли объект в пуле - если да, то вернуть его, если нет, то создать, записать в пул и вернуть

А это что - не некая реялизация синглтона? Ты уж как то определись, есть синглтоны у тебя, или нету...

изначально пул предоставлял метод get_instance и этот метод был public сейчас мы его сделали protected и встал вопрос - а нужен ли вообще этот пул

Как то проблема не оч. понятна. Сделав гет_инстанс зашишенным, ты как то иначе стал обеспечивать механизм создания единственного экземпляра? Тогда, конечно, не нужен...

 

[domino]

2 john.brown:
синглтон это вполне конкретный паттерн проектирования.

сорри, это была ошибка на счёт protected get_instance.

класс пула как предоставлял public так и продолжил предоставлять паблик.

методом этого класса пользовался класс core который содержал одноименный метод. - просто обёртка. этот одноимённый метод мы и сделали protected. основная идея при проектировании была в том, что есть несколько уровней - ядро, системный уровень, библиотеки, бизнес логика и вывод. на каждом уровне есть 2 специфических класса - xxx_objects - где ххх - это название уровня. этот класс является родителем для всех классов уровня, ну там нет ничего кроме инициализации по дефолту. и второй класс это обёртка - xxx_shell_name. вот обёрка - это как бы API уровня. все обёртки наследуются от нижнего уровня и вверх. и служат только для того, чтобы предоставлять более верхнему уровню все public методы всех классов уровня. вот в самом низу в core мы и защитили get_instance чтобы пулом объектов могли пользоваться только обёртки. вызов любого паблик метода обёртки имеет примерно такую реализацию

public function foo_name($par)
{
   return $this->get_instance('class_name')->foo_name($par);
}

получается что пока никому не нужен паблик метод, объект не создан.

-~{}~ 27.06.08 03:04:

вопрос с целесообразностью пула объектов потому и поднят, что стоит ли под это дело отводить целый класс, если по сути никакого особо умного контроля над созданными объектами он предоставить не может, кроме того, что у него есть массив для хранения таких объектов (ссылок наобъекты в памяти??????). или всё же какое-то полезное использование такого класса возможно?

 

[atv]

и позволял написать в любом классе что-то в духе $this->core->select() а использовали $obj = $this->core->get_instance('mysql'); $obj->select()

А в чём принципиальная разница? Для чего запрещать второй способ.

если по сути никакого особо умного контроля над созданными объектами он предоставить не может

Неопределённость цели приводит к неопределённости результата. Определитесь, какой контроль вы хотите получить, за вас этого никто не сделает.

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

Опять же, есть чёткое обоснование такого решения? Чего вы хотели добиться таким архитектурным решением?

 

[grigori]

на с/с++ код my_array[xxx] = new A(); создаст в памяти экземпляр класса А по адресу *my_array[xxx]

но попытка написать $my_array['class_name'] = new A(); не создаст экземпляр А по адресу $my_array['class_name']

"Чувак, ты понимаешь чё ты спрашиваешь или как? "(С)

Тебе памятью надо управлять (экземпляров класса на с) или в PHP-скриптах проектировать объектную модель?
В PHP любая переменная - ссылка на память, тут нет работы с памятью, вообще.

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

Сейчас в "подходе, который был заложен при проектировании" замечается отсутствие четко сформулированной цели
Не мог бы ты написать нам цели этой идеи "специфического класса пул объектов, родителя всех классов уровня " и привести простой пример его использования?

 

[texrdcom]

Вроде кто то выпил не кажеться?

-~{}~ 09.07.08 01:52:

А если по существу уже давно написали и сделали смотрим зенд фреемворк - Zend_Registry в названиях класса могу ошибаться.

 

[domino]

сорри. сейчас в дороге. доберусь до нормального инета - отвечу

 

[Alexandre]

вот и возникает вопрос - есть ли смысл в существовании такого класса, как пул объектов.

с точки зрения рациональности - нет
но с точки зрения архитектуры - есть.

 

[angry.creater]

хз, скорее зависит от специфики проекта, хотя, мне лично трудно представить настолько специфический проект, и следовательно архитектурный принцип, подобного решения в случае WEB-приложений

собсна, зачем Вам "глобальная" свалка ВСЕХ объектов?

 

[[DAN]]

Эта глобальная свалка (она же Registry, она же Context, она же $GLOBALS) - вешь нужная и полезная. Можно создавать, хранить объекты в глобальном пространстве, к которым можно получить доступ из почти любого места программы. Не нужно заботиться о создании и инициализации связанных объектов (классов). Но в то же время работать с этим инструментом надо аккуратно.

Например, объект-регистратор (пул) хранит в себе ссылку на объект для работы с БД (допустим, DB). При обращении к пулу возвращается ссылка на объект DB. И тут может случиться ситуация, когда в одном месте программы мы меняем какие-то свойства (коннект, к примеру) объекта DB, и эти изменения повлияют на работоспособность другой части программы. В этом случае требуется workaround, такой как копирование объекта или создание нового.
Также нужен какой-то механизм, который будет гарантировать наличие нужного объекта в пуле.
Еще может быть такая ситуация, как инициализация сложного объекта (свойства которого - объекты других "тяжеловесных" классов). Тогда, по правилам пул должен будет полностью проинициализировать объект перед тем, как его вернуть, хотя нам в конкретном случае может этого не требоваться. Тогда придется докручивать пул техниками lazy loading.

Вобщем, как и любой инструмент, пул объектов надо использовать с умом.

Я бы рекомендовал вместо него использовать Registry:
http://martinfowler.com/eaaCatalog/registry.html

 

[angry.creater]

Не нужно заботиться о создании и инициализации связанных объектов (классов).

"Эта" нужная штука называется IoC Container http://wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code , которая, (в зависимости от конкретной имплементации) действительно может использовать Реестр http://martinfowler.com/articles/injection.html

Здесь речь идёт о такой-себе глобальной фабрике-сингелтоне как таковой, к которой обращаются некоторые объекты для создания других объектов, но НЕ содержащей никакой информации о зависимости объектов (и соответственно не умеющей порождать зависимые объекты).
То есть просто "глобальная" свалка объектов.

Теперь, если я например, придерживаюсь стандартов кодирования диктуемых данным фреймворком, то что бы создать просто какой-нить Value Object в одном методе, для передачи в другой метод (ярус, слой, уровень и т.д), я должен его "регистрировать" в этой свалке и хранить там себе до скончания работы инстанса конфигурации сайта, порождённой конкретным запросом... зачем такой перерасход памяти.
Ведь, например, объекты создаваемые раз-два за весь вариант использования, в зависимости от БП, в некоторых методах, вместо того, что бы уничтожаться, продолжают жить вместе с другими используемыми объектами.
Вот именно такое приложение мне трудно себе представить... а точнее - его архитектурную оправданность.

Например, объект-регистратор (пул) хранит в себе ссылку на объект для работы с БД (допустим, DB). При обращении к пулу возвращается ссылка на объект DB. И тут может случиться ситуация, когда в одном месте программы мы меняем какие-то свойства (коннект, к примеру) объекта DB, и эти изменения повлияют на работоспособность другой части программы. В этом случае требуется workaround, такой как копирование объекта или создание нового.

описанная проблема чаще всего решается той или иной парадигмой Обозревателя. Так же, это классический случай полезности и оправданности применения Сингелтона, но не некоего базового ф-нала, придающего ВСЕМ объектам ф-ность этого паттерна, путём организации глобальной помойки ВСЕХ объектов

Также нужен какой-то механизм, который будет гарантировать наличие нужного объекта в пуле.
ну да, интерпретатор PHP выступает таким гарантом ) вместе с логикой БП, если в ней (логике) нет ошибок... ИМХО, слишком дорогое страхование получается

Еще может быть такая ситуация, как инициализация сложного объекта (свойства которого - объекты других "тяжеловесных" классов). Тогда, по правилам пул должен будет полностью проинициализировать объект перед тем, как его вернуть, хотя нам в конкретном случае может этого не требоваться. Тогда придется докручивать пул техниками lazy loading.

чего-чего делать? )
имхо, IoC и здесь выруливает

Вобщем, как и любой инструмент, пул объектов надо использовать с умом.

именно, ПУЛ объектов, но не ПУЛ ВСЕХ объектов (вспомогательных, временных и прочая байда) системы, который стал ПУЛ лишь только в силу побочного эффекта желания наделить ВСЕ объекты системы сингельтоно-подобными способностями

хз, ИМХО это лишнее для любого архитекрурного (а тем более архитектурно-определяющего - каркас приложений) решения... возможно, при оччень-оччень больших приближениях - как некая запись "макросов" при демонстрации возможностей движка

-~{}~ 11.07.08 19:30:

... ну под макросами имеется ввиду сериализация и десериализация всех объектов хранимых в этом ПУЛе, в определённой последовательности

 

[[DAN]]

angry.creater
вобщем-то все правильно сказал.
я как раз указывал на недостатки подходя "всё в одном".

насчет предложенных тобой решений я бы еще подискутировал но это выйдет за рамки трэда.

моя основная мысль - пул - это хорошо, но аккуратно.
отвечу на вопросы топикстартера

возникает вопрос - имеет ли вообще смысл такой класс?

Имеет, только пихать в него порождения всех объектов не имеет смысла.

что будет хранится в элементах такого массива - ссылки на классы в памяти или действительно сами классы?

ссылки на объекты (не классы)

если ссылки на память, то мы всё равно фактически не управляем местом хранения классов, так имеет ли смысл такой класс как пул объектов?

на этот вопрос уже ответил grigori

 

[grigori]

Автор оригинала: angry.creater
Здесь речь идёт о такой-себе глобальной фабрике-сингелтоне как таковой ...
просто "глобальная" свалка объектов.

Это "родитель для всех классов уровня", а совсем не глобальная свалка.
Я как-раз вижу проблему в том, что это куча независимых свалок-родителей. Это скорее всего приведет к независимым изменениям отдельных пулов, и они начнут работать по-разному.

что бы создать просто какой-нить Value Object в одном методе, для передачи в другой метод (ярус, слой, уровень и т.д), я должен его "регистрировать" в этой свалке и хранить там себе до скончания работы инстанса конфигурации сайта, порождённой конкретным запросом... зачем такой перерасход памяти.

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

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

Мы этого не знаем.

-~{}~ 20.07.08 16:41:

[DAN], пул - это неизбежно для любого модульного проекта

Проблема, когда этих пулов много, и перед ними ставятся цели управления памятью и программистами!