youri, Вопрос "проектируете ли вы свое приложение?" напоминает мне "как часто вы бьете свою жену?". Какой ответ предполагается услышать?   

  ksnk   .
youri,да тут дураку понятно что "без проектирования и мысленного представления как это будет работать далеко не удишь."

Штука интересная но неимет смысла ее использовать.

вроде ж ты ответил уже
просто я тебя понял так, что проектирование - ненужная вещь

fesor, а обосновать?

Ну например тм рассматривается пример:
В класс системы пользователей передают 2 класа: для работы с БД и управление сессиями. Там же используется такой код: $this->db->execute  к примеру. Это уже задает ограничение на интерфейс класса (ну тобиш названия методов меняться не будут уже. Можно только добавить новых а иначе снова искать и убирать лишнее). Почему бы тогда не воспользоваться чем-то вроде system:: db()->execute() (кстати это довольно похоже на класс-контейнер) или db::execute() вообще...

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

Это сообщение отредактировал(а) fesor - 17.7.2009, 14:30

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

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

system:: db()->execute() -- вводятся новые зависимости. Теперь ваш класс зависит от некоего system, от db и от того проинициализирован ли класс db в system.
db::execute()  -- кто занимается инициализацией класса db? Каким образом работать с несколькими базами данных?

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


Dependency Injection в данном случае -- установка класса транспорта.

Не все то, что пораждает объекты, зовется фабрикой. Суть фабрики в том, чтобы прозрачно для клиента решить какой из подттипов объета вернуть. Фабрика не работает с любыми типами объектов. То что вы приводили в темах о подключении модулей к фабрике имеет слабое отношение.

Суть контейнера в том, чтобы:
1. Создать все объекты-зависимости
2. Создать сам запрашиваемый объект
3. Выполнить инициализацию объекта, передав все зависимости и начальные настройки.

Фабрика из всего этого выполняет лишь второй пунт.

т.е., обдумывая пути решения задачи, мы должны отбросить пути решения с помощью паттернов (даже если знаем, что их надо будет потом использовать). Это меня, собственно, и смущает. Это твоя позиция?

Тутошний контейнер не создает, а знает как создавать. Разница, в некоторых случаях значительная...

В каком месте в отквоченном мной коде производится инициализация объекта? инииализацией объекта занят сам объект... 

Ну вот, нужно начинать с определений  Что есть фабрика, что есть регистри, а что есть Dependency Injection и его контейнер? Желательно просто и понятно, как Аристотелево определение человека...

Следует иметь ввиду, что "паттерны программирования", а не "паттерны ООП программирования". То есть в определении слово "класс" и "объект" должно иметь значение "черный ящик", с определенным списком свойств.

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

Фабрика - это регистри, отягченная ограничениями.
-- не все имеют право (кроме специально обученных объектов-конфигурации) изменять соответствие имя-значение.

Фабрика объектов - выдаваемое фабрикой значение - объекты с унифицированным ( с одинаковым смыслом и порядком параметров) конструктором.


Это сообщение отредактировал(а) ksnk - 17.7.2009, 17:15

вот в этой:

Сам объект не запрашивает какой ему пранспорт использовать.

Это я упустил ;-(

Однако так получается, что у нас знания о классе - мейлере размазаны по большому количеству кода. если вообразить, что нам понадобился класс, реализованный вообще без параметров (на встроенном mail'е) нам придется править конфиг $container = new Container ... (ну это уж необходимо)
и придется править метод getMailTransport в описателе некоего контейнера неизвестно где описанного... 

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

Знания о нем сосредоточены в одном месте -- контейнере. А в идеале -- файле-конфигурации контейнера. Собственно, в этом и смысл контейнера.



Вообще-то достаточно удалить вызов $mailer->setDefaultTransport(). При использовании Symfony Service Container -- удалить одну строку его конфига.

Ну допустим класс system является главным в системе и в него все загружается (как в контейнер). Допустим где-то понадобилось вызвать базу данных. Сделав доступ к функции db() класса system мы смотрим, загружен ли класс для работы с БД и если нет - загружаем. Ну и отдаем его. Мне такая реализации кажется достаточно простой и не напряжной в плане расширения.

В какой системе? В той, которую вы пишите именно сейчас? А как испоьзовать ваши классы, расчитанные на system Sanchezzz-у, который любит называть свой мегакласс, содержащий все, 
Core? Прелесть внедрения зависимостей как раз в том, что класс не знает с каким именно классом он работает -- важен интерфейс. И прелесть контейнера в том, что класс не знает о его существовании -- нет зависимости от контейнера.