если ты можешь за 10- минут написать god object и решить проблему, а нормальное решение займет неделю другую

это опять же холиварно и спорно)

да нифина не спорно. GOd object = high coupling = боль

напиши god object потом со спокойной душой делай решение

> если ты можешь за 10- минут написать god object и решить проблему, а нормальное решение займет неделю другую а еще ты можешь подумать 10 минут лишних и придумать солюшен который займет у тебя 20 минут и не будет god object-ом

напиши god object потом со спокойной душой делай решение

ты видимо не понимаешь что есть god object либо.... хз

> если ты можешь за 10- минут написать god object и решить проблему, а нормальное решение займет неделю другую а еще ты можешь подумать 10 минут лишних и придумать солюшен который займет у тебя 20 минут и не будет god object-ом

в такой ситуации конечно лучше не писать

чет я тож не знаю реальной ситуации, где простое решение может быть god object

неявные зависимости, сильный каплинг

а еще потом мутабельное состояние

мммм

я подозреваю что "когда не хочется ставить контейнер зависимостей"

но это такое.... composer require php-di/php-di

типа да

т.е. методы UserService объединяет то, что они все работают с User?

@KuvshinovEE

да в данном примере

тогда вопрос, почему эти методы не в классе User?

а какие методы?

UserService

оттуда

ну обычно UserService это процедуры для данных (User)

тогда вопрос, почему эти методы не в классе User?

может быть его нет потому что?

может быть его нет потому что?

нет класса User?

или может для User это просто valueobject ?

так а почему он value object?

user -> valueobject

я думал он сущность)

так потому что принято в приложение?)

зависит от ситуации

полно деталей

ну я и спрашиваю детали

просто круто быть всем таким идеалистом и не писать godobject

когда это может быть нужно

но если посмотреть все мы их писали

все мы юзали singleton и тд

singleton != god object

все мы жили без php-di или pimple и подобного

я знаю что !=

у большинства на проекте есть косяки или недоработки

если было бы идеально то мы бы над проектом не работали потому что он был бы готов

и делать вид типо нам абстрактно видней как лучше делать тоже не всегда

потому что делая архитектуру по теории потом команда начинает все делать через одно место стоит уйти в отпуск

а в вашем приложение способны разобраться только один человек(автор) ну и теоритически Фаулер или чьи видео использовали

правильного ответа нет, есть решение удовлетворяющее требования

и сегодня оно подходит завтра нет

а попытка предугадать все возможные ситуации может не окупиться

потому что могут через месяц убрать модуль так как им пользователи не пользовались или не выгодно и тд

просто круто быть всем таким идеалистом и не писать godobject

мне кажется что мы по разному трактуем этот термин. Как ты определяешь что "это god object"?

https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B6%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82

то что говорили тут вы сейчас будете выводить не в god object а в то что это facade

для приложения а уже части кода выполняются там нужные

у фасада почти нет своей логики

но что мешает использовать напрямую нужный объект а не facade ?

https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B6%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82

вики все читали. Меня интересует что для тебя god object

ибо как я понимаю для тебя это любой объект с чуть большей зоной ответственности чем нужно

понятие "чуть большей" субьективно

это тоже понятно)

и на вики в первом предложение вместо "чуть больше", "слишком много" тоже в кавычках

можешь мне привести вот твои личные границы

зависит от приложения

и от ситуации

ну тогда о чем мы вообще говорим

грубо говоря

ERROR: S client not available

https://cs7054.vk.me/c637330/v637330551/28d57/H8OZToiJQ2c.jpg

если в приложение есть более адские вещи и проблемы

надо просто пробовать находить баланс с couling и coheasion

то понятие слишком много, не достигается почти никогда

что не просто само по себе

именно

именно если на проекте ад и view в перемешку с sql

и с бизнес логикой

то ты как то забьешь на объект который в стороне и делает все что тебе надо

и называется он как нибудь CoreService, AppService и тд

тебя он вполне устроит и ты будешь мешанину шаблонов и sql разделять

но когда в приложение все сделаешь удобно можно и этот объект посмотреть и возможно разделить

или тебя позвали на битриксе что нибудь пофиксить, в шаблоне там что то поменять, получаешь проект смотришь и со словами ебать тут нет ddd,cors, solid, еще я привык к doctrine, php-di, phpunit (coverage 100%), behat и тд

и начинаешь все это приводить в порядок))

но только нафига?)

ну это совсем другой разговор)

или тебя позвали на битриксе что нибудь пофиксить, в шаблоне там что то поменять, получаешь проект смотришь и со словами ебать тут нет ddd,cors, solid, еще я привык к doctrine, php-di, phpunit (coverage 100%), behat и тд

позвали на битриксе?

это работа с жестким легаси)

и плаванье в говнокоде

ну похорошему от такого надо сразу бежать

bitrix, joomla хорошие стопслова)

я знаю как это бывает

плавал

"тип там только чуть-чуть подправить, надо зарелизить уже"

"фрилансеры делали на joomla"

да

и в вариенте с битриксом любое решение сделанное через godobject, singleton или даже goto

является допустимым

даже заявление по собтсвенному на русском, тоже допустимое решение.

и в вариенте с битриксом любое решение сделанное через godobject, singleton или даже goto

ты только что объяснил почему там так плохо все)