Объясните дураку ооп. Видимость переменных в разных инстансах.

[VVWind]

Собственно эти пункты можно свести к одному - зависимости. И фактически ты повторил то же, что он привёл в моей цитате, но при этом VVWind видит лишь моральные проблемы Печалька.

Ни в коем случае, просто привел примеры.

 

[radioheaded]

И эти люди запрещают мне ковыряться в носу! © Ничего плохого не хочу сказать, просто всегда вызывает улыбку, когда самые рьяные знатоки внезапно задают такие вопросы.

На самом деле, многое кажется странным до тех пор, пока не поймешь, как это работает изнутри, ну или хотя бы фундаментальные принципы, на которых это работает. Так появляются сборники типа http://wtfjs.com или http://www.phpwtf.org . Там на самом деле глупые примеры, но если не знать чего-то, то они кажутся либо багами, либо мистикой.

 

[Breeze]

И эти люди запрещают мне ковыряться в носу! © Ничего плохого не хочу сказать, просто всегда вызывает улыбку, когда самые рьяные знатоки внезапно задают такие вопросы.

стыдиться нужно не незнания, а невежества и нежелания учиться

 

[WMix]

http://hashcode.ru/questions/92217/php-паттерн-singleton

Вот об этом и был вопрос - "ЗАЧЕМ?". Ответ простой - да, НЕЗАЧЕМ

ну а в общем статик это все что угодно: логгер, сессия, реквест, респонз, конфигурация, все другое что действительно может быть в одном экземпляре, и для чего лень создавать обьект, но иметь доступ отовсюду....
(выдаю статик и синглетон как одно и тоже, только для примера использования.)

-Пап, а о чем ты думаешь?
-да вот пытаюсь обратится к методу класса обьект которого не инициализирован во время выполнения программы

пример в яве

System.out.print("Hello world")

тут out вероятнее всего статич[еска/на]я переменная класса System

 

[fixxxer]

Проектирование библиотеки как синглтона - это зло. Единственность экземпляра объекта - это характеристика конкретного дизайна приложения, а не библиотеки самой по себе. No exceptions, я на любой пример приведу контрпример, когда нужно несколько инстансов.

Потому синглтон и называют антипаттерном. При этом, в синглтоне вида

function db() {
    static $instance = null;
    if (!$instance) $instance = new mysqli(...);
    return $instance;
}

такого недостатка нет.

Но поскольку
1) такие функции писать лениво
2) хочется еще и управлять зависимостями (в приведенном выше примере, очевидно, вместо "..." будет обращение к конфигу)

и разрабатываются те или иные способы dependency management.

И, да, global $db - это частный случай глобальной зависимости (выраженной через глобальную переменную), в этом нет ничего плохого, если в приложении гарантированно нужно только одно соединение, и присваивание переменной инстанса объекта делается один раз. Здесь больше проблема контроля - если в любой DI/SL/registry/синглтон можно запретить переопределение элементано поставить debug_backtrace, то переопределение глобальной переменной отловить заметно сложнее. Но это не так важно (решается банальной дисциплиной), как вопрос зависимостей, почему-то все забывают про это.

 

[MiksIr]

> в приложении гарантированно нужно только одно соединение
Гарантировано кем? В реальном мире, а не мире абстракций, требования меняются со временем. Что будет через год, когда нужны будут две базы.

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

Именно по-этому Синглтон (как паттерн) по сути мало чем отличается от глобалов ибо он провоцирует его использование внутри вашего класса, а значит вы скрываете - что классу нужно для работы. Это решается только инжектированием зависимостей.

 

[fixxxer]

Гарантировано кем?

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

вопрос зависимостей остается не решенным... Это решается только инжектированием зависимостей.

Штирлиц знал, что запоминается только последнее слово.

Я, как бы, о том же.

 

[MiksIr]

Я, как бы, о том же.

А не воспринимай все посты как возражения, я в общем для закрепления темы.
Хотя с function db() я бы поспорил

 

[fixxxer]

Я бы тоже поспорил. Это самый минимально возможный пример синглтон-провайдера, не более того.

 

[WMix]

public static function db( $name = 'default' ){
    if(!isset(self::$db[$name])) ...
}

и сингл и мулипле...

 

[fixxxer]

Угу. До некоторого предела роста сложности (скажем, просто мастер и слейв, или 2-3 соединения по ролям) оно вполне нормально.
А вот когда код функции перестает помещаться на экран, уже пора делать ConnectionPool.

 

[WMix]

как это было, This is a matter of balance and trade-offs. все правда, статик нужно избегать и понимаю что все статики это чаще причина лени, но я думаю, почему же приверженец краткого простого кода является противником более простому способу?

 

[Lionishy]

fixxxer

Проектирование библиотеки как синглтона

Что же это за зверь такой: библиотека как синглтон?

Всё равно, что: дом как окно.

 

[Фанат]

если в приложении гарантированно нужно только одно соединение.

Погоди. А кто мешает написать global $db2;?

 

[fixxxer]

..., $db3. ... $db10. Никто не мешает, конечно =)

Только чем больше таких глобалсов, тем
- менее все управляемо
- сильнее нужен lazy load