В PHP нет такого понятия как захардкоженое имя класса.
Вгрузите другой класс с тем же интерфейсом, вместо старого и всё будет нормально.
С использованием неймспейсов это как раз плюнуть — заменить use-вызов в начале.
Ну я не хочу долго рассказывать историю пропела, но долгое время проект был заброшен и симфони от него отказались, потом его взял один из разработчиков первой симфони, а сейчас он набрал ещё себе команду и они делают Propel2.
Инициатива сделать Propel2 появилась буквально месяц назад и все вопросы архитектуры обсуждались.
Та уже обсуждалось. Что синглтон для многих вещей отлично подходит ибо прост как пробка, в отличии от DI. В том же Propel2 отказались от DI ибо ради одного конекшна вводить целый DIC не было никакого резона.
Добавлю, что тестировать это дело очень даже просто. Можно вполне подменить одни клас его моком при загрузке и всё ок. Даже не знаю, проблема тестирования дико раздута.
Будет. Но разница только в том сколько времени на него тратится. Если это время можно сократить (не в ущерб качеству кода), значит больше времени остается на решение бизнес-задач.
Но за полгода вы можете там достигнуть такого уровня зарплат, которых в РНР вы никогда и не увидите. По крайней мере, я слышал много таких success story. Люди меняли профиль, или просто устраивались на новое место джуниором, а потом быстро становились senior'ами и выше.
Ок, но какая основная мысль?
Мы можем начать писать сайт как <?php echo "Our Site" ?>
а потом при усложнении бизнес-задач его рефакторить?
Наверняка нет. Если вы рефакторите — значит нынешняя архитектура недостаточно продумана или просто устарела для решения текущих задач. Если есть возможность создать расширяемую архитектуру, и нововеденья внедрять в неё без гавнокода, значит не нужно рефакторить после каждого чиха.
Архитектура тем лучше чем меньше в ней надо будет рефакторинга.
Ну а я привожу пример того, что DIC в этом плане недостаточно хорош.
Кстати, какие тогда вообще конкурентные преимущества в РНР? Если я усвою все эти паттерны и они мне понравятся, я просто уйду кодить на Джаве. Там платят больше. А принципы те же, только лучше.
Не то что никаких… Скорее, их чуть меньше. В примере с репозиториями доктрины, ок, интерфейс есть. От этого легче? Нет. Всё равно сигнатура кастомных функций неизвестна. И вперед бегать по всем файлам, открывать тот самый репозиторий, смотреть его функцию… В интерфейсе может быть вообще одна функция, а в реализации их десть-двадцать. И потому интерфейсы не особо помогают :(
Ага, не решать конкретные задачи, а рефакторить код. Господа, так не бывает.
Есть бизнес-задачи, есть рефакторинг. Бизнес-задачи приоритетнее. ТОт паттерн эффективнее, что помогает избегать рефакторинга, а не тот, что провоцирует его. Иначе вообще зачем нужны паттерны, если в случае чего мы будем перестраивать архитектуру?
Вкратце выскажу мнение. Скорее всего DI в том виде в котором его подают не нужен для большинства задач.
Он нужен для разработчиков библиотек, продуктов и пр. Для веб-сайта и веб-приложения как раз не столь необходим.
Суть Dependency Injection ясна и правильна, но вот контейнеры это зло. Потому что если вдруг оказалось, что какой-то класс мы забыли добавить в контейнер, то нужно рефакторить весь код и заменять все вызовы. А зачастую так же все и происходит. Сначала у вас класс простой, а потом он разрастается, появляются зависимости, их нужно конфигурить… И в момент, когда вы понимаете, что вам нужен DI для этого класса, необходимо рефакторить код. Короче, какая-то дедукция в разработке получается.
А ещё зло эти ваши фабричные методы. Никогда не знаешь что оно вернет и с какими методами/свойствами. То как реализованы в доктрине вызовы репозиториев, это вообще печаль — никогда не знаешь какие методы в этом репозитории. Каждый раз нужно отдельно открывать файл репозитория и проверять сигнатуры нужных функций.
Вгрузите другой класс с тем же интерфейсом, вместо старого и всё будет нормально.
С использованием неймспейсов это как раз плюнуть — заменить use-вызов в начале.
Нельзя бездумно портировать парадигму. Нужно понимать плюсы и минусы языка.
Инициатива сделать Propel2 появилась буквально месяц назад и все вопросы архитектуры обсуждались.
Если вам интересно почему они не отказались от синглтона, их аргументация тут:
github.com/propelorm/Propel2/issues/22
Архитектура это обычно как раз построение реализации.
Как отношение имеет архитекутура к внешнему поведению?
Мы можем начать писать сайт как <?php echo "Our Site" ?>
а потом при усложнении бизнес-задач его рефакторить?
Наверняка нет. Если вы рефакторите — значит нынешняя архитектура недостаточно продумана или просто устарела для решения текущих задач. Если есть возможность создать расширяемую архитектуру, и нововеденья внедрять в неё без гавнокода, значит не нужно рефакторить после каждого чиха.
Архитектура тем лучше чем меньше в ней надо будет рефакторинга.
Ну а я привожу пример того, что DIC в этом плане недостаточно хорош.
А sandbox нужен только если вы даете левым людям на сайте гонять команды PHP.
Есть бизнес-задачи, есть рефакторинг. Бизнес-задачи приоритетнее. ТОт паттерн эффективнее, что помогает избегать рефакторинга, а не тот, что провоцирует его. Иначе вообще зачем нужны паттерны, если в случае чего мы будем перестраивать архитектуру?
Он нужен для разработчиков библиотек, продуктов и пр. Для веб-сайта и веб-приложения как раз не столь необходим.
Суть Dependency Injection ясна и правильна, но вот контейнеры это зло. Потому что если вдруг оказалось, что какой-то класс мы забыли добавить в контейнер, то нужно рефакторить весь код и заменять все вызовы. А зачастую так же все и происходит. Сначала у вас класс простой, а потом он разрастается, появляются зависимости, их нужно конфигурить… И в момент, когда вы понимаете, что вам нужен DI для этого класса, необходимо рефакторить код. Короче, какая-то дедукция в разработке получается.
А ещё зло эти ваши фабричные методы. Никогда не знаешь что оно вернет и с какими методами/свойствами. То как реализованы в доктрине вызовы репозиториев, это вообще печаль — никогда не знаешь какие методы в этом репозитории. Каждый раз нужно отдельно открывать файл репозитория и проверять сигнатуры нужных функций.