Comments 11
Это вот что было сейчас? «Не используйте переменные до их инициализации» на примере классов?
+3
UFO just landed and posted this here
del
0
инъекция через конструктор логично выглядит. а вот зачем фабрика еще сверху? не совсем понимаю, выглядит как усложнение…
+1
1) Через set-методы можно сетить необязательные зависимости.
Еще удобно их использовать для иньекции зависимостей в случае наследования от какого-то класса с уже объявленным конструктором. Дабы не перегружать его. Насколько это правильно — вопрос, но нужно всегда иметь ввиду, что setter может быть не вызван. Всегда проверять значение переменной.
2) init-методы часто используются для того, чтобы сделать создание объекта как можно быстрее. А инициализация происходит в момент непосредственного использования. Эдакая lazy-загрузка. Пример
Еще удобно их использовать для иньекции зависимостей в случае наследования от какого-то класса с уже объявленным конструктором. Дабы не перегружать его. Насколько это правильно — вопрос, но нужно всегда иметь ввиду, что setter может быть не вызван. Всегда проверять значение переменной.
2) init-методы часто используются для того, чтобы сделать создание объекта как можно быстрее. А инициализация происходит в момент непосредственного использования. Эдакая lazy-загрузка. Пример
0
1. Ведь необязательная зависимость выглядит как противоречие. В таком случае хватит только геттера.
Использование геттеров необходимо в случае обеспечения обратной совместимости. Вот пример поддержки BC во второй Мадженте
2. В вашем примере метод вызывается на clone(), то есть в приниципе не влияет на создание обьекта.
Использование геттеров необходимо в случае обеспечения обратной совместимости. Вот пример поддержки BC во второй Мадженте
2. В вашем примере метод вызывается на clone(), то есть в приниципе не влияет на создание обьекта.
0
1) Это если вы знаете из чего получить экземпляр.
Например, может быть какой-то сеттер, который позволит подключить дополнительный функционал.
Вы можете через CompilerPass (на примере Symfony) установить свою реализацию этой необязательной зависимости для какого-то вендорного сервиса. Например, что-то такое
2) Не только на clone, а и в нескольких других случаях, когда необходима работа с уже реальными загруженными данными. Из примера выше (родительский класс)
Например, может быть какой-то сеттер, который позволит подключить дополнительный функционал.
Вы можете через CompilerPass (на примере Symfony) установить свою реализацию этой необязательной зависимости для какого-то вендорного сервиса. Например, что-то такое
2) Не только на clone, а и в нескольких других случаях, когда необходима работа с уже реальными загруженными данными. Из примера выше (родительский класс)
0
1. Это похоже на некорректную реализацию обсервера и больше частный случай.
2. Я не вижу ничего хорошего в данном инициализаторе. Он обязывает второго разработчика знать о своем существовании. Если стояла цель lazy-loading, то ИМХО лучше было создать фасад/прокси который бы отвечал за подгрузку обьекта.
2. Я не вижу ничего хорошего в данном инициализаторе. Он обязывает второго разработчика знать о своем существовании. Если стояла цель lazy-loading, то ИМХО лучше было создать фасад/прокси который бы отвечал за подгрузку обьекта.
0
Sign up to leave a comment.
PHP и Temporal Coupling