D
а перезапуск то да, весь посмотрел
Size: a a a
2020 June 08
RK
Это слишком - их же не 1/3. :)
те ты собираешься ущемлять меньшинства?)
AH
ну я про классику, я не смог)
Я даже не начинал)
VY
ой янемогу. остановите шарик, я сойду
На ходу прыгай :)
Можно присоединиться к Илону
Можно присоединиться к Илону
VY
те ты собираешься ущемлять меньшинства?)
Пока они ещё в меньшинстве... А то потом они всех ущимят, мало не покажется...
DA
А еще нубский вопрос.
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
A
А еще нубский вопрос.
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
Когда через DI сразу видно что вот этот класс юзает этот. И это реально важно в больших проектах.
A
Например если зависимостей становится много, значит что-то надо делать
A
Разумеется, там есть ещё отличия...
DA
Ммм.. да, хорошо. спасибо)
J
Статические методы - не очень хорошая практика в принципе. Они убивают многие преимущества ООП и приближают его назад в прошлое к процедурной парадигме
А
Статические методы - не очень хорошая практика в принципе. Они убивают многие преимущества ООП и приближают его назад в прошлое к процедурной парадигме
А как быть, если не нужен объект?
J
Объект нужен всегда, хотя бы синглтон
J
Мое мнение - статические методы - это функции из процедурного в красивом фантике под ООП
J
А еще нубский вопрос.
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
Чем плохо использовать функциональность сервисов через статические методы? Например:
ProjectService::getBestProjectsByUser($user_id).
Лучше ли через new ProjectService и ProjectService->getBestProjectByUser?
Или с помощью DI в конструкторе?
В чем преимущество включения сервиса с помощью DI, если не планируется биндить разные реализации этого сервиса...?
DI обеспечивает слабую связность. Слабая связность - это хорошо 😊
DA
На уровне лозунгов я это понимаю, а вот на практике... :)
В какой момент я расстроюсь из-за того, что использовал ProjectService::getBestProjectsByUser($user_id), мне пока не ясно)
В какой момент я расстроюсь из-за того, что использовал ProjectService::getBestProjectsByUser($user_id), мне пока не ясно)
DA
Не ООП, да.. по сути такие хэлперы, выделенные в отдельный класс для удобства.
J
Чем реализация от интерфейса отличается, есть понимание?
DA
Да, думаю есть.
DA
И если, скажем, у меня может смениться источник каких-то данных, я, используя тот же интерфейс, сделаю bind другой реализации, и будет все хорошо. Так?