все успели закапитанить, а ты нет)

....толстые модели....

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

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

Из хорошего - параметры конструктора (обычно) невозможно забыть - компилятор напомнит. А сеттер забыть вызыать - это запросто.

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

ну, я толстые имею в плане rich

ну, я толстые имею в плане rich

ну так рич они не толстые)

они рич

а точнее whole

God

sucks)

упитанные :D но да, сорри

God

не, боги это жирная шляпа с низким кохиженом

ни разу не whole value

Ну такое да... согласен, не в тему

Из хорошего - параметры конструктора (обычно) невозможно забыть - компилятор напомнит. А сеттер забыть вызыать - это запросто.

лечение насморка переломом

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

объект передай

лечение насморка переломом

на самом деле слишком много параметров конструктора может быть симптомом.... а может и не быть) это просто хороший признак для того что бы начать думать

ааа

или у вас не жс

как это сеттеры не нужны? в конструктор передавать 20 параметров, чтобы инициализировать свойства?

ответь лучше на такой вопрос. Этому объекту для всех его операций нужны все 20 полей?

или хотя бы каждый метод юзает 15 из 20 полей

ну так, что бы подумать

или у тебя там только геттеры?)

возможно этот 1 объект надо разделить на несколько, каждый из которых будет уже юзать данные на всю катушку

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

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

и бизнес аналитики все эти которые модели данных рисуют.... ух

когда люди начинают делать "правильно", получается ещё хуже) так что делать надо, как умеешь, с небольшой (!) оглядкой на всё прочее. В процессе исправится.

а причина проста: сколько людей знает, как оно должно быть на самом деле?)

когда люди начинают делать "правильно", получается ещё хуже) так что делать надо, как умеешь, с небольшой (!) оглядкой на всё прочее. В процессе исправится.

твоя позиция вообще никакой точки зрения не выражает

ну или я могу трактовать ее как "ииии тааак сойдет!"

+/- так и есть

а причина проста: сколько людей знает, как оно должно быть на самом деле?)

в этом и загвоздка - никто не знает

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

при том что это... не сложнее

просто по другому

просто надо чуть больше думать - с точки зрения затрат для бизнеса это примерно одно и то же

и да я знаю что думать больно

но не думать - бывает больнее

бизнесу тоже надо думать, что бы все были счастливы) но если программисты порой хотя бы вид делают, что думают, то думающий бизнесс === единорог

и вот как раз у последних в львиной части случаев "хуяк-хуяк и в продакшен, потом поправим". Думать тупо некогда.

бизнесу тоже надо думать, что бы все были счастливы) но если программисты порой хотя бы вид делают, что думают, то думающий бизнесс === единорог

недумающий бизнес умрет рано или поздно

это не столь важно

да все рано или поздно умрут)

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

предлагая варианты

они тебе цели должны ставить, а не что делать говорить

другое дело что целей нет часто - это абсолютно другая проблема

не думаю что стоит ее обсуждать)

можно провести аналогию - "заюзать микросервисы без цели" - это то же самое как "у меня есть новая идея офигенная - соц сеть!"

ну или че там в 2018-ом... "как слак только мой"

да, с геттерами и сеттреами хороший пример... В последний раз вспоминал о декомпозиции, когда читал Гради Буча :) А отсутствие сеттеров будет способствовать и декомпозиции и агрегации. Если я всё правильно понял.

да, с геттерами и сеттреами хороший пример... В последний раз вспоминал о декомпозиции, когда читал Гради Буча :) А отсутствие сеттеров будет способствовать и декомпозиции и агрегации. Если я всё правильно понял.

именно, это такие гадкие штуки которые сами по себе ничего плохого не несут, но заставляют тебя прекратить думать

если бы так ещё каждый паттерн вкурить )))

а то проект на работе хороший, но не способствует :(

Это не паттерн, это здравый смысл

я о паттернах говорил )

уже задолбался перечитывать, а практики, как таковой, нет

если бы так ещё каждый паттерн вкурить )))

главное что стоит понять - что такое паттерны и для чего они нужны.

Ну так их не надо вкуривать, а надо понимать зачем оно

главное что стоит понять - что такое паттерны и для чего они нужны.

Именно

а нужны они больше - как быстрый способ описать что ты хочешь сделать/сделал. Ты не должен ими мыслить

"шаблнное мышление" - звучит не очень, правда?

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

главное только без фанатизма) в памяти свеж пример со стратегиями)

главное только без фанатизма) в памяти свеж пример со стратегиями)

спаситель яблок - это было забавно)

ну нейминг меня так себе волнует, у самого Google Translate Development...)

про 20 параметров конструктора... обычно это говорит о том, что разработчик не умеет VO.

ERROR: S client not available

про 20 параметров конструктора... обычно это говорит о том, что разработчик не умеет VO.

мы это уже обсудили)

https://www.youtube.com/channel/UCbF-4yQQAWw-UnuCd2Azfzg

мне вот этот чел нравится - это неплохое место с которого можно начать "думать дальше"

ну я очень хотел вставить свои 13 капитанских копеек

VO - это что?

value object

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

не обессудьте )

https://www.youtube.com/channel/UCbF-4yQQAWw-UnuCd2Azfzg

Он там 1 час 40 минут объясняет паттерн итератор. Не проще ли за 10 минут про это прочитать в GOF?

Он там 1 час 40 минут объясняет паттерн итератор. Не проще ли за 10 минут про это прочитать в GOF?

ну видимо не проще)

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

паттерны типа фасада например так разжевывать не надо)

Было бы горазно интереснее, если бы кто-нибудь брал более менее средний проект и на его примере объяснял, что хорошо, что плохо, а то все пишут про "выделяйте бизнес логику в сервисе", а на деле - или всё впихнуто в контроллер, или 100500 классов-оберток и непонятно, с чего начинать разбираться.

Было бы горазно интереснее, если бы кто-нибудь брал более менее средний проект и на его примере объяснял, что хорошо, что плохо, а то все пишут про "выделяйте бизнес логику в сервисе", а на деле - или всё впихнуто в контроллер, или 100500 классов-оберток и непонятно, с чего начинать разбираться.

выделять бизнес логику в сервис - это далеко не всегда хорошая идея)

но нет, я не про контроллеры сейчас

что до "средних проектов"

тут есть 3 нюанса: - NDA. - Средний проект уже достаточно большой что бы проявлялись эффекты от "хороших практик" но он уже слишком большой что бы хотя бы за цикл видео недельный покрыть все эти нюансы. - Преимущества по настоящему раскрываются только с течением времени. Ты не можешь сказать "делайте так", потому что в определенных обстоятельствах это будет не столь эффективно

а пилить проекто просто так - я пытался... это отнимает много сил и сложно пилить продукт который никому не нужен и никем не юзается)

если он никем не юзается - примеры изменений получаются весьма искусственными что смазывает картину

ну вот пример - https://github.com/mozilla/addons-server/blob/master/src/olympia/pages/views.py

сайт мозилы, def credits это контроллер, который внутри делает то, что делать явно не должен

явное обращение к модели (у них там в django orm, что если они захотят внезапно поменять это на sqlalchemy.. хотя кого я обманываю, не захотят)

с точки зрения разработчика - да, я понимаю, это очень быстро написать, не надо думать, особенно если сроки горят, а свои 50-100к$ получить хочется.

сайт мозилы, def credits это контроллер, который внутри делает то, что делать явно не должен

единственный кусок кода который я бы там переделал - это построение гистограммы - вынес бы это в свой объект

все остальное, тот факт что там идет построение запроса - это нормально

ответь просто на вопрос - зачем выносить это дело?

единственный кусок кода который я бы там переделал - это построение гистограммы - вынес бы это в свой объект

ок, но ответственность контроллера - взять контекст и вызвать render('template.html', context), разве нет?

ок, но ответственность контроллера - взять контекст и вызвать render('template.html', context), разве нет?

он это и делает)

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

давай по другому, допустим мы вынесли построение запроса в отдельную хрень - что мы этим добились? в чем преимущества?

даже если ты захочешь на sqlalchemy переходить - не думаю что у тебя этот запрос будет там отличаться сильно. Будет тот же квери билдер