Singletone + Reflection + PHP 5.3

[Lirik]

cDLEON
не вижу ничего плохого чтобы вводить в архитектуру синглтон, просто нужно знать где он необходим, чтобы таких желаний не возникало потом.
>>И тогда желание сделать класс, который бы решал только задачу инициализации синглтона, отпадёт сама собой...
в смысле?

 

[cDLEON]

Принципиальную разницу, кстати, между
$GLOBALS['my_object'] и Registry::set('my_object',new blablabla());
Тоже не вижу. Перезаписать можно откуда хочешь, автокомплит не прикрутишь.... Очередной костыль в архитектуру... Зато объектный )

 

[cDLEON]

Lirik
а я вижу. При чём огромную. Проблема там в том, что когда вдруг обнаружится, что, всё таки, нужен не один, а минимум ДВА таких объекта, придётся потрошить ВЕСЬ код. Либо прикручивать ещё какие-нибудь костыли.
В прямом смысле. Какую задачу решает абстрактный класс топикстартера ?

 

[igortik]

cDLEON
думаю, патерн Singletone дает больше надежности коду. Как минимум, по этой причине при построении навороченного решения лучше его применить, чем держать в голове мысль, а есть ли тот или иной объект. Это субъективное мнение.

А вот на счет реализации патерна - вот здесь вопрос. Мой пример не самый лучший, но все же собирает в кучу одно решение.
А Reflection явно расстроил кривизной в php 5.3.2., учитывая, что к статическим приватным свойствам он может обращаться и даже менять их состояние, но не способен банально создать объект с protected/private конструктором.

 

[Lirik]

cDLEON
я говорил не конкретно про класс топик стартера, т.к там не поймешь что он делает, я говорил про "способ" инициализации в обход getInstance().
Если захочется иметь 2 объекта убери private с конструктора и все, ну и по коду заменить где надо...и конструктор и getInstance() возвращают объект все равно

 

[igortik]

Lirik
Мой код избавляет от нужды его плодить в каждом классе, где нужен патерн Singletone и хранит все созданные объекты в одном месте, чтобы потом в любой момент их можно было успешно инстанцировать да и вообще проводить какие хочешь манипуляции с ними

 

[MiksIr]

Я вообще не считаю себя профи в проектировании, но, почему-то мне кажется, что если у вас навалены в проекте в одну кучу и синглтоны и DI - произошла какая-то очень большая ошибка...
А если возникает потребность передавать какие-то параметры в синглтон... значит синглтон вам не подходит. Если честно, он вообще редко когда подходит, и, имхо, для многих является просто легкой и ленивой заменой глобальной области видимости.

 

[cDLEON]

Lirik
Ок. Допустим, мы убрали private из конструктора. Когда становится 2 объекта, они должны работать с разными данными. Раз с разными данными, значит и в конструктор нужно уже что то передавать. Вот и всплыла проблема, описанная топик-стартером. А так же - вы любезно согласились, что это уже не хорошо. Далее. Есть ещё один подводный камень - называется он тем, что как то вдруг, мы захотели сделать две реализации одного, возьмём туже БД (большинство программистов приводят именно эту ситуацию) т.е. перевести один проект с mysql, на PostgreSql . Что делать будем? Replace Mysql_Db Postgre_Db по всему коду?
Понимаю ещё синглтон aplication в дескопном программировании. Да, она там гарантировано одна.

 

[Lirik]

cDLEON
использую PDO, в любом случае я не понимаю полного отрицания Singletone в веб-программировании Вами

 

[cDLEON]

Я искренне рад за вас. Это был просто пример.

 

[MiksIr]

в любом случае я не понимаю полного отрицания Singletone в веб-программировании Вами

Извините, а какие "за"? Простота использования - воткнул куда хочешь и не паришься, откуда оно взялось?
Используя синглтоны вы порождаете жесткие зависимости вашего класса от класса-синглтона. Попробуйте оттестируете такой класс, когда нужно подсунуть, например, фейковый объект DB, а он у вас там синглтоном.
Синглтоны подходят, например, когда не вносят изменений в выполнение кода... ну... логгер, например - там не важно, в каком состоянии он находится (ну разве только если не тестируется то, как ваш код логгирует что-то). В большинстве же случаев - антипаттерн.

 

[MiksIr]

ЗЫ: была уже большая тема, переливать опять смысла нет: http://phpclub.ru/talk/threads/Почему-singelton-плохая-практика.66181/

 

[igortik]

1. Singletone не антипатерн.
2. Тестировать можно не только готовыми решениями.
3. Согласен, что создаются связи, это минус, об этом упомянул сразу (но исключительно в моей реализации сторонним абстрактным классом).

Почитайте код в первом сообщении, там и есть глобальный реестр всех объектов, это плохо? Или просто вам хочется это делать по принципу Registry::set($name,$value); ?
Какая разница?

А DI можно применять и с SIngletone, более того, мы всегда будем знать, что Конкретно в этот объект была проведена инъекция.

 

[whirlwind]

Предлагаю законодательно запретить использование синглтонов как сущности, приводящей к межколлегиальной розни.

 

[cDLEON]

Я пришёл в эту тему, что бы "поделиться опытом", а уже считаться с моим мнением или пойти самому шишки набивать - дело ваше!
Поэтому, в споре, где одна сторона приводит аргументы, а другая игнорируя их, задаёт очередной вопрос "и чо?" предпочитаю не участвовать!)

 

[MiksIr]

Предлагаю для начала ввести различие между Синглтоном и синглтоном =)

 

[igortik]

Предлагаю законодательно запретить использование синглтонов как сущности, приводящей к межколлегиальной розни.

так можно оспаривать любой патерн

Я всего лишь хотел узнать как передавать в конструктор потомка аргументы в моей реализации (см. 1 сообщение)
И какие За и Против конкретно такой реализации, добавляющей связи.

 

[MiksIr]

"Синглтон" с аргументами - это нонсенс. Если хотите аргументы - делайте реестр, о чем тут уже говорилось.
Оспаривать можно любой паттерн, если есть аргументы против него. Для паттерна "Синглтон" они есть. И DI - один из способ устранить недостатки использования паттерна "Синглтон". Но можно свалить все в одну кучу, несомненно =)

 

[igortik]

MiksIr
А как DI может помочь устранить недостатки?
Я без "заковыривания", интересно мнение и для наглядности пару операторов

 

[MiksIr]

В случае с DI вы во-первых четко знаете, что нужно этому классу для нормальной работы, тогда как синглтон вносит ложь в api, т.е. вам придется прочитать весь код класса, что бы понять что ему нужно... а ведь в Синглтонах могут быть вызовы других синглтонов... жуть.
Во-вторых, вы легко и непринужденно подсовываете какие угодно моки при тестировании этого класса.
В-третьих, Синглтон глобален, что нарушает принцип, что объект может работать только с теми объектами, с которыми ему нужно работать, и не может влиять на другие никак. Так как Синглтон глобален - это легко нарушить. Это опять же усложняет тестирование.