Правильная архитектура CMS, без static методов, с глобальным хранилищем и инициализатором Классов.

[c0dex]

fixxxer
О чем ты, какая точка, ООП - это не инстансы объектов, и ты не хуже меня это знаешь. Мне вот интересно, знает ли он и сказать не может, или реально думает оное.

 

[fixxxer]

вообще без объектов ООП не бывает. другое дело, что объект это не обязательно instance of smth

 

[Вурдалак]

В Scala сделали интересно, там статический класс — это объект-синглтон.

 

[WMix]

У меня в голове есть идея, что я должен создать какое-то глобальное хранилище классов, ещё во время выполнения bootstrap.php. И по мере обращения к какому-то классу из любой части приложения, происходит проверка на существование данного экземпляра класса, и при необходимости такой экземпляр создаётся.

И уже в приложении, я мог бы без проблем использовать конструкции типа App::Session->Check(), и в классе App, происходила бы проверка, существует ли экземпляр класса Session, если нет, то создавала бы.

Натолкните как правильно всё-же делать.

возможно несколько наоборот?

class App{
 static function check($class){}
}
App::check('Session')

http://php.net/manual/de/function.class-exists.php

а вообще есть такое понятие autoload

 

[fixxxer]

У меня в голове есть идея, что я должен создать какое-то глобальное хранилище классов, ещё во время выполнения bootstrap.php. И по мере обращения к какому-то классу из любой части приложения, происходит проверка на существование данного экземпляра класса, и при необходимости такой экземпляр создаётся.

держи говнокод =) в мелких проектах юзаю, где пофигу на относительно тесную связанность

 

[artoodetoo]

А так же избавитель от подсказок в IDE и превращатель хранилища инстансов в черный ящик.

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

/* @var $db \My\Cool\Db */
$db = App::get('db'); // избавитель от дум про синглтон

2. "превращатель в черный ящик" - это прекрасно! а можно назвать "расслабитель порочных связей".

в общем суть всем понятна, а какую лейблу на это наклеить дело ваше.

 

[fixxxer]

думать, что всегда хватит одного database connection-а - это так наивно

хотя для говносайтов сойдет

 

[artoodetoo]

а мы на это: оппа!

$db2 = App::get('db2');

теперь у нас уже не говносайт, а большой взрослый сайтище!

 

[Lionishy]

Так вроде бы в PHP по-любому нет пула соединений, потому что нет сервера приложения. Или есть?

 

[artoodetoo]

Вы можете установить несколько соединений. Это ответ?

 

[fixxxer]

ну и чем это отличается от global $db, $db2?

 

[artoodetoo]

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

 

[Lionishy]

Вы можете установить несколько соединений. Это ответ?

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

 

[artoodetoo]

Вы, кажется, не любите рабочий класс PHP?

 

[Lionishy]

На мой взгляд PHP не нужен. Но менеджеры думают иначе.
Да и мне всё равно... Если потребуется сделать что-то, что на PHP будет сложно, я просто не стану это делать.

 

[fixxxer]

И чем такой сервис локатор отличается от $GLOBALS?

App::get('db')
$GLOBALS['db']
в чем разница?

 

[Lionishy]

Хотя бы тем, что сам ресурс, в отличие от переменной, нельзя изменить непредсказуемым образом.
Хотя бы тем, что доступ к переменной контролируется вне кода, а в случае локатора -- это дополнительная инверсия управления.

 

[Фанат]

И чем такой сервис локатор отличается от $GLOBALS?

Ну вот да, я как раз в контексте прошлого своего вопроса думал об этом, и пришел к тому, что к $GLOBALS['db'] есть доступ на запись у всего приложения. И где-то что-то можно, теоретически, изменить.

 

[AmdY]

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

 

[fixxxer]

AmdY =))


Ладно, хватит троллить, разжую.

Вообще в типичных подобных регистри есть метод set. Более того, когда речь зайдет о тестировании, его ввести так или иначе придется.
Получаем тот же глобалс 1 в 1

На самом деле подобные "решения", даже если убрать сеттеры, не решают другой, главной задачи - уменьшение связности кода. Сегодня мне надо одну реализацию в зависимостях $Foo и $Bar, а завтра - разные. Решается это только передачей зависимостей извне, любые регистри-локаторы-х*яторы это замаскированный глобал.