Own MVC Framework - Registry

Собственно, сабж темы в названии. Нужен ли нам класс Registry?

Уже дня 3-4 изучаю MVC паттерн. Он великолепен. Вопрос возник не просто так. В интернете огромное количество MVC Framework-ов, примеров и копипастов создания собственной архитектуры MVC. Все это, конечно, хорошо, но мне не совсем понятно наличие класса Registry во многих из примеров, в частности - в примере с хабра. Обратил внимание на этот комментарий - http://habrahabr[dot]ru/post/31270/#comment_536441 [bb-код url не понимает символа #]

Помогите советом. Ответ прошу аргументировать. Ответы "Да" и "Нет" особой смысловой нагрузки не несут.

(Отредактировано автором: 17 Июля, 2012 - 12:53:28)

Точка, через которую проходит работа между элементами системы, на мой взгляд, необходима. Это убирает чрезмерное внутреннее связывание между этими элементами. Но конкретно тот пример Registry вызывает у меня отторжение - автор зачем-то мешает разные техники (у него по одному геттеру и сеттеру - нет четкого понимания, с каким объектом, полученным из этого регистри, вы работаете, там же притянуты за уши доступ к объекту, как к массиву - мне не очень понятно, зачем и тд) ... складывается ощущение, что он на собеседовании пытается доказать, что знает кучу умных вещей, но мало понимает, зачем они.
(Добавление)
Я предпочитаю связывать приложение через фабричные методы. Это дает ряд бонусов:

1. У меня всегда перед глазами список того, что я могу получить (список методов)
2. Я всегда знаю, что получу от того или иного метода (четкость API - это очень важно)
3. Я всегда имею возможность централизованно повлиять на систему (поменяв всего в одном месте возвращаемый объект - я получаю новое поведение всей системы)
4. У меня стабильно работает автокомплит в IDE - скорость моей работы повышается в разы

Сами смотрите, что для вас более наглядно : registry->get('userCart'); //хз, есть ли этот карт или мы получим нулл, а должен ли он там быть вообще, может там надо не userCart спрашивать, а cart?

или

factory->getCart(); // уже введя 'getC' IDE вам автокомплитит, что вы можете получить, а так же сообщает, что в ответ вы гарантированно получите объект UserCart, при этом внутри метода getCart вы можете сразу прописать наполнение этого объекта, а при необходимости - логику выбора, какую корзину именно отдавать (если у вас несколько реализаций)

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

присмотритесь к паттерну Dependency Injection, это грубо говоря эволюционное развитие паттернов Регистри, Фабрика и т.д... очень мощная штука наиболее продвинутая реализация этого паттерна это https://github.com/symfony/DependencyInjection, также есть, очень легкий https://github[dot]com/fabpot/Pimple в зависимости от масшабов проекта можно подобрать один из них.

Opposite, есть абстрактная фабрика, а есть фабричный метод. В фабричном методе 1 метод возвращает 1 объект. В него не надо передавать аргументы, на каждый тип необходимых классов - свой отдельный метод, который берет на себя работу по инициализации этого объекта.

digi, долго читал, пробовал использовать - в итоге приложение получается более запутанное и сложноизменяемое - хз, почему ... может, я просто не умею его готовить Инъекции хороши для очень сложных и вариативных приложений, в вебе редко такое можно встретить. Единственное место, где я планирую его ввести - расчет доставок заказов + расчет цены заказов (для учета бонусов, скидок и тд) ... В 99% приложений этот паттерн больше мешает, чем помогает, ИМХО

Stierus, да сервис контейнер с наскоку не осваивается, это нормально ) я щас полностью перешел на Symfony2 и скажу как есть - на меньшее уже не согласен %) придумывать или использовать какие-то скромные и/или неказистые решения мне уже совсем не хочется ;) притом даже для казалось бы простых вещей ;)

изучение ДИ начал вот с этой статьи http://fabien[dot]potencier[dot]org/arti[dot][dot][dot]mponents-part-12 , затем уже полную доку c оффсайта http://symfony.com/doc/current/components/dependency_injection/index.html, по русски можно вот эту статейку почитать http://symfony-gu.ru/documentation/ru/html/book/service_container.html, но всёже лучше на ЕНГ.

Это ты его просто не пробовавал на практике. На бумаге выглядит замечательно. Количество постов на форуме где люди не могут собрать страницу на этом паттерне как бы намекает.



Чего непонятного - человек почитал книжку решил что паттерн великолепен и запрограмировал - то что он там нафиг не нужен никого не волнует.


с какого перепугу паттерны стали основой ООП?



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


только одно неудобство - очень хреново разбирать и отлаживать код с внедренными неведомо в каком месте сорцов зависимостями.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

ммм, а можете пример привести? а то я в процессе использования ДИ с такой ситуацией еще не сталкивался... может упустил что-то...

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