sTa1kEr, сначала нужно, чтобы bars80080 решил, что соединение должно быть одно. А потом многое отпадет  

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



Singleton допускает больше одного объекта: "Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of instances that the application uses. Only the operation that grants access to the Singleton instance needs to change." (книжка банды четырех)


не подойдет. TDD-шники не любят Singleton


есть разумные доводы. Ты б статью почитал прежде чем говорить ;) : "Характер зависимости может быть Динамическим – когда мы легко можем подменить один объект другим, и клиент об этом не узнает, если интерфейсы все также поддерживаются." Динамическую зависимость можно подменить, в отличие от статической. Важно как минимум для TDD. А статья - хорошая


я бы сказал "в разумных пределах"

Это сообщение отредактировал(а) youri - 24.9.2009, 17:25

что сие значит?



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

Добавлено через 24 секунды

почему?

Это личные тараканы вас неопытных TDD-шников. Я говорил про вменяемых программистов, которые исповедуют KISS & DRY.


Нет там разумных доводов, там есть искусственно созданные проблемы самому себе. 

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

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

Добавлено через 8 минут и 36 секунд

Брр, прошу прощения, но меня это запутало еще больше.

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

Вот смотри, есть у нас некоторый слой абстракции работы с БД. 

•  мы ему можем передать запрос
• можем использовать какой-либо из реализованных примитивов

Допустим, нам нужно чтобы работа некоторых модулей с БД логировалась отдельно. Тогда нам нужно предусмотреть это в асбтракции.

Например -
Декларация выглядит примерно так



Все, когда нам надо, мы передаем другой объект ведения лога

Все равно не понимаю. Имеем один, сервер, один коннект к нему и два разных интерфейса взаимодействия. Первый интерфейс реализует операции " создать базу, редактировать, создать таблицу...", второй то, что необходимо сайту. Все. Зачем тут два коннекта?


Это значит

Точнее вообще отказаться от переключения баз.

Добавлено через 1 минуту и 7 секунд

Это само собой, разумеется.

 Я юзаю Registry-паттерн.

 Зачем? о_О

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

отлипли от БД.
есть класс подключения страницы, один объект, одна страница, ряд операций с ней. надеюсь, религия вам не мешает загонять три контента в один вывод?

теперь задаю вопрос: внимание!
может теперь увидите


в ряде методов некоего третьего класса. нужно ли отходить от этой схемы?


-------------------------------------------------------------------------------------------------------------
вопрос был выше



как я понял, нужно. но судя по всему вы не можете определиться как. или я что-то упустил. можете конкретезировать?

/ни о какой БД мы здесь не говорим/

Тебе уже давно ответили. Только ты ответа не захотел увидеть.

Отходить нужно.

Как именно отходить - тебе дали "надцать" вариантов ответов.

Singletone, Registry, через одно место можно Factory.

вот, registry. значит, завтра (может быть) будем разбираться, что это за зверь такой


в слове три, формы "надцать" нет  

палишься ;)


если человек не хочет слушать...


ответили почему: чтобы постоянно не писать и не забыть написать global
ответили как... чем отличаются варианты можно почитать в статье (кстати, писали разработчики limb). Фактически, если не практикуешь TDD, можно остановиться на Singleton, остальные варианты скорее для TDD (если неправ, объясните почему). Причем не обязательно создавать класс Singleton, можно обойтись функцией (см. выше)

??? вменяемость как-то противоречит KISS & DRY?


Тут не о чем говорить. Тесты не должны менять поведение тестируемого класса. Нигде и никогда.
Иначе я вам рефлексией такого наменяю, что из детской коляски у меня получится АК-47, как в пресловутом анекдоте.

Если вы и автор той статьи допускаете такое поведение - значит грошь цена вам, как профессионалам.

а кто сказал менять. Неужели моки уже considered harmful?

Мда, и как я такое пропустил


К сведению. Отказаться от этого нужно не по причине забывчивости.

А по причине безопасности. Переменные в global scope могут быть изменены любым! случайным модулем. Этого быть не должно.


Никакой прямой связи между Singleton и TDD нет. Проблема в узком мышлении и попытке покрыть непокрываемое, впихнуть невпихуемое.

Singleton это объект, который должен существовать в одном (ограниченном) числе. Все. Остальное от лукавого.
Все домыслы о том, что он мешает TDD - суть домыслы. Внятных аргументов, - чем он мешает, - нет, не было и не будет.
Боитесь статических связей? Откройте для себя делегаты и фабрики. И наслаждайтесь динамическими связями. Но причем тут Singleton и TDD?

Добавлено @ 22:30

А вы не пробовали читать статью на которую ссылаетесь?
Я вам даже цитату оттуда приводил.

"В тестах иногда нужно иметь возможность изменить поведение этих методов"
Ага?

Там еще куча перлов. Например, паническая боязнь статических связей.
Пишем: Синглтон - зло он завязывает на себя объект статически.
и сразу код где мы напрямую в коде класса (статически) зависим от класса Log



И тут же пишем какая классная вещь сервислокатор.
и сразу код.

Убейте меня тапком, если Locator :: instance()->getServer(); не статическая зависимость.
Что мы поменяли? Подсунули еще одну прослойку(абстракцию), а от статической связи не избавились.
Статическая - не значит что вызывается статический метод. А то что мы зависим от класса Locator напрямую

Черт побери! И эти люди запрещают ковыряться мне в носу?

Я вам говорил что статья очень спорна. И написана далеко не гуру. Специально освежил свои впечатления.
И таких ляпсусов там с полдесятка точно, и это на мой взгляд непрофессионала, который около полутора лет не писал ничего вообще.

Это сообщение отредактировал(а) Simpliest - 25.9.2009, 13:46

вот, а ещё говорите, что насоветовали надцать вариантов. singleton опять же оказывается одиночным, фабрика не к месту, а статья, которую обязательно надо прочитать, лучше не читать, или читать но осторожно


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


а разве в register я не могу поменять переменные любым случайным модулем?

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


может ты и прав, что проблема высосана из пальца


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



да, статическая зависимость, но мы же можем подменять объекты, которые service locator раздает


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

Это сообщение отредактировал(а) youri - 25.9.2009, 02:41