новый мутный вопрос...

вот есть к примеру у меня класс $db = new db(); для работы с базой данных, подключается всегда, так как и нужен всегда
далее, в модуле имеется другой класс, который совершает запросы к БД, естественно он использует уже налаженное соединение и функционалом класса db.
в методе пишу:



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


вот скажите, как вы делаете? или мне опять не беспокоиться?

Синглтон для работы с БД. Коннект - статик свойство.

Все кому нужно работать с БД, работают с этим синглтоном

а мне нужно более одного экземпляра. как раз касаемо работы с БД

не все http://wiki.agiledev.ru/doku.php?id=ooad:m...ies_in_php_code


независимость это, конечно, хорошо. Но я считаю, что чтобы усложнять должны быть причины. Пока что похоже причина одна. Если измениться название переменной, то надо будет поменять ряд мест в коде. Допустим будет Синглтон. С тем же успехом можно предположить, что название класса может измениться. В статье, кстати, сказано, что привязка к именам классов хуже, чем к именам переменных


а зачем?

Тогда логично было бы использовать какой-либо реестр коннектов к БД. Добавлять получать их через статические методы класса.

bars80080, более одного коннекта одновременно тебе нужно? Зачем такая роскошь?

Я полагаю bars80080 имел ввиду несколько коннектов к разным серверам.

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

нет, до разных серверов ещё не развился


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




вообще, задача общая. помимо db есть ещё два класса используемых постоянно. правда, они используются одиножды. есть ещё один класс, который теоритечески может использоваться несколько раз, хотя я пока не реализовал эту задачу, но уже сейчас могу придумать обоснование нужды.
и есть частные классы, к примеру, по работе с файлами, по работе с БД, по работе со структурой сайта, дампер, и прочие. они используют вышеупомянутые классы, и везде где нужно приходится писать в методах global $db, $main;

уже само по себе неудобно

Это точно оправдано? Что-то кажется, что никак. У тебя для одного сайта использется более одной базы данных?

А если будет 10 баз, то будете делать 10 коннектов?   Почему просто в запросах не использовать полные имена таблиц? Т.е. Db1.Table1, Db2.Table2, etc.


Самый простой способ использовать некий контейнер, реестр этих объектов, в качестве примера реализации можно привести ZF http://framework.zend.com/manual/en/zend.registry.html Ну и, как уже сказал, Simpliest можно использовать шаблон Singleton.

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

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

нет, одна для сайта и одна для интерфейса работы



мне нужно несколько экземпляров

Я в таких случаях использую фабрику. Мне удобнее всего писать так

если уж принципиально использование нескольких коннектов

icewind, и каждый раз будет создаваться новый объект с новым внутренним состоянием...

NewDima, и почему это?

Все равно делай один общий пусть даже с пулом БД или коннектов.

Хотя если общего кроме хостинга ничего нет  тогда - да. Каждому приложению своя прослойка.

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

Тебе уже указали. Registry заменяет собой пачку синглтонов.

icewind, извини, не вник, оплошал =)
Посчитал, что ты у фабрики запрашиваешь каждый раз новый объект

Конкретно для БД - все вменяемые. Такое уточнение подойдет?

Чем меньше точек входа для базовых операций - тем лучше.


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

И статью следует читать аккуратно. Писали ее не гуру. Но даже гуру ошибаются 

NewDima, да не за что извиняться. С кем не бывает   

разобраться б что там написано

Один объект, который представляет собой реестр, хранящий список инициализированных объектов, и обладает геттерами, возвращающими эти объекты (ссылки)

Это сообщение отредактировал(а) icewind - 24.9.2009, 16:52

bars80080, а в чем конкретно?
Как использовать зендовский реестр? так просто, по строковым ключам, которые в твоем случае могут быть для тебя в виде 'interface' и 'site'. Разве не удобно?

объектов разных классов?

да хоть чего вообще, это же альтернатива глобальному массиву

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

потом


а лучше


Хотя мне кажется обычная фабрика здесь подойдет отлично. Пример я приводил

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

наверное, самый важный момент, на него мне ещё не ответили

вот есть:

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

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

На мой взгляд да. Нужно отходить и использовать factory для получения коннекта к базе.

Тогда я не совсем понимаю, что значит "для интерфейса работы". Но в любом случае, раз на сервере используются несколько баз, то вполне оправданно было бы использовать полные имена и отказаться от select_db.


Да, фабрика хорошо бы подошла если бы были коннекты к разным серверам. А так, конечно, от нее не очень много проку в фабрике одного объекта  Хотя, с другой стороны универсальность и задел на будущее...

или

  

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

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

Я имел ввиду

А все запросы переписать так, что бы они не завесили от того site это или interface   

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

bars80080, может просто в конструктор передать? Агрегирование пойдет?

В register ты всегда можешь контролировать, что у тебя там лежит и зачем. К примеру, можешь сделать его read only или вести логи к его объектам или же вовсе изменить способ хранения объектов.
А globals - это просто бесконтрольная помойка переменных.

изначально - не помойка, но может такой стать

вот, интересный момент.

допустим, так:


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

а с какой это стати объект будет дублирован?

bars80080, иногда пугаешь)
ты пишешь под четверку?
По ссылке передашь и не будет никакого дублирования

bars80080, мой вам совет -- не пытайтесь решить одну конкретную проблему, задав вопрос на форуме. Вы вырываете ее из контекста и какие бы гуру вам не отвечали -- все равно получится костыль.

Получите системные знания по объектно ориентированом проектировании. Системности знаний могут помочь книги, а не ответы на форуме или статьи. 

Из того, что читал я, могу посоветовать:
Т.н. банда четырех - хрестоматийная книга, но тяжела для восприятия. 
Фаулер - Архитектура корпоративных программных приложений. Опять же хрестоматия, но читается намного легче (как и все его книги).
Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования - написана легко, примеры на php, примеры на web задачах.

фиг знает. я тут заметил одну заморочку в js, что если приравнять один массив m1 к другому m2, то m1 станет ссылкой на m2.
а мне ответили, что так и должно быть (в смысле, это нормально для языка иметь такой механизм)



ряд сайтов лежит на хосте с 4-кой. стало быть поддерживаем



это всё хорошо, но время, время...

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

возьмём эту литературу на заметку

Для меня это было очевидно, но хорошо. Исправил.


Минутку. Вам провести тест мешала именно статическая зависимость.
Вы ее не убрали, вы сменили шило на мыло. Теперь вместо правки кода Server мы будем править код Locator. А чем это лучше?

Избавится от статических зависимостей внутри класса вы можете инъекцией зависимости (Dependency injection), или паттерном строитель(Builder), который будет строить/собирать нужный объект. Вы не сделали ни того, ни другого. В чем был смысл сотрясания воздух в статье?

А финальный пример с toolkit вы там видели? Это же абзац полный. Вы создали жуткий звездный объект помойку. В котором неизвестно, что, где, когда и откуда.

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

Как итог куча лишнего геморроя. За облегчение жизни в виде прозрачного маппинга моделей в базу и отсутствие необходимости думать над ее структурой.

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

Добавлено @ 13:55

Если не поставишь в конструкторе проверку на соответствие интерфейсу - грозит неработоспособностью 

То что ты написал это dependency injection вкупе с delegation

P.S. что меня еще убивает в паттернах, так это то, что для осуществления похожих действий существует не один паттерн :(

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

так эта...


кроме того, я не нашел там "панической боязни". Увидел только, что статическая зависимость рассматривается как один из недостатков. Если это учитывать, все становится не таким черным. Там не говориться, что делать. Там обсуждаются разные варианты с их плюсами и минусами. Сравниваются


а разве статических зависимостей не стало меньше? 


я этим toolkit'ом не пользовался и мне не очевидно, что это помойка. Я считаю так: ее можно превратить в помойку

Там останавливаются на конкретном решении, - которое им подошло, - Service Locator.
Dependency Injection упомянут вскользь, видимо, для них он оказался слишком сложным.

И в свете

Их осталось столько же.

Был один "звездный" объект мы его заменили другим объектом путем прямого редактирования кода объектов.
Статическая зависимость, которая якобы мешала ТДД осталась.
Надо будет опять поменять - мы будем или редактировать эти объекты или будем увеличивать "звездность" и запутанность Service Locator.

А представьте, если нам нужно будет добавить новый функционал не затронув старого для соседей?
В случае Injection я просто в конкретном месте передам новый объект реализующий нужный интерфейс.
В случае Locator -  мне придется выдумывать пляски с бубном.  Мне нужен объект с интерфейсом IA, а какой конкретно из 2х - хрен его знает. 

Смысла телодвижений 0. Оставались бы уже с Singleton.

в смысле?

Внедрение зависимости. Ну а по делигации -- в гугл )

для нашего сурового и слегка окостеневшего моска там слишком тонко написано. тонко и размазанно

а в трёх фразах можно же?

Конечно можно. Внедрение зависимости, это когды зависимости внедряются, а не содержатся в исходном коде класса ))

у тебя какое-то субъективно-негативное отношение к этой статье. Может потому, что не любишь TDD? Да, они для себя выбрали решение, но тем не менее они рассказали про другие варианты


как это осталось столько же? Была куча звездных объектов, выполненных в качестве Sinleton'ов, вместо них остался один toolkit



не думаю, что это распространенная задача в TDD. У нас есть тесты. Можно исправить tool и тех, кто его использует. Но даже если мы хотим это оставить на потом, ничто не мешает добавить нам исправленный tool под другим именем в toolkit


вот, например, статическая зависимость

т.е. Server напрямую обращается к объекту. Но можно избавить его от лишней информации

при этом мы сможем не меняя класс Server передать ему другой объект. Для одного клиента это не так важно, но когда клиентов много...

так это здесь получилось копирование объекта?
а зачем? пусть один объект для всех идёт

это не копирование, обьекты в php передаются по ссылке (упрощенно) 

всегда, что ли?

в 5-ой версии

 Да, всегда. Пора бы уже и основы PHP знать.

 Во всех актуальных. Т.е. в 5 и 6(ее уже пора принимать во внимание).

почему?

зато у bars80080 одна награда есть  

 Что почему? Что объекты всегда передаются по ссылке?

 А у авторов inphp.org есть сайт inphp.org, и что? Это еще не значит, что они хорошо знают php ;)

почему отношение такое негативное? вы не кушали сегодня йогурт "нежный"? или вы опять кому-то отказали?