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

и в целом плохо читаешь доки

почему - хз, тебе виднее

ты ж не пытаешься разобраться

Про разделение ответственности в доках не встречал, может я невнимательно читаю)

пока нигде)

Ну я не про конкретную про такси) Думал, может где публикуете?

и в целом плохо читаешь доки

А в каких доках это можно встретить?)

Про разделение ответственности в доках не встречал, может я невнимательно читаю)

просто погугли

в целом больше гугли.

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

Мне кажется, что перед фреймворками неплохо бы порешать абстрактные задачки на ООП. Например консольные шахматы, где есть различные зоны ответственности: - логика шахмат, не зависящая от отображения - обработка хода (игроки по очереди вводят команды вроде "e2-e4" в консоли) - консольное отображение Потом добавить игру по сети и проанализировать сколько кода нужно исправить Или добавить возможность играть в правила Фишера и опять посмотреть, как много нужно задеть кода для этой фичи. Чем меньше - тем лучше разделены ответственности, то есть получаем наглядный профит от хорошей архитектуры, а не слепо верим всяким Зандстрам и GoFам.

Мне кажется, что перед фреймворками неплохо бы порешать абстрактные задачки на ООП. Например консольные шахматы, где есть различные зоны ответственности: - логика шахмат, не зависящая от отображения - обработка хода (игроки по очереди вводят команды вроде "e2-e4" в консоли) - консольное отображение Потом добавить игру по сети и проанализировать сколько кода нужно исправить Или добавить возможность играть в правила Фишера и опять посмотреть, как много нужно задеть кода для этой фичи. Чем меньше - тем лучше разделены ответственности, то есть получаем наглядный профит от хорошей архитектуры, а не слепо верим всяким Зандстрам и GoFам.

слишком сложно, игра по сети на php, сокеты...

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

это правильно

как по мне можно калькулятор консольный написать)

сначала что бы он умел простые выражения. потом добавляем туда sin/cos

потом историю операций

но это для js удобно. ибо тогда можно будет помимо текстового поля кнопки фигарить

да и не только UI нам надо отделять

Калькулятор с парсером арифметических выражений? Я извращался как-то, не скажу что лучше научился ООП понимать

Много нового приходится изучать при создании парсера, не до ООП

Раз попроще, то ещё встречал такую задачу

https://gist.github.com/wbars/2c3590206ee4a590eca5

Ох уж эти превью :(

Калькулятор с парсером арифметических выражений? Я извращался как-то, не скажу что лучше научился ООП понимать

не, это больше на разделение ответственности

ооп ты на шахматах не особо поучишь)

ну то есть, какие у тебя объекты будут? интерфейс фигура, и на каждый тип фигуры реализация. + доска

ну да, полиморфизм можно потренировать

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

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

но тогда зачем шахматы?)

и ты ООП тренькать собрался или разделение ответственности?

для ООП мне понравилась задачка - система координации лифтов

типа у тебя есть 4 лифта, и надо максимально утилизировать их загрузку. Пользователи могут на первом этаже указывать куда они хотят

и на других этажах - вверх или вниз

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

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

а учитывая что там геймдев, то ООП очень нужно, иначе погрязнешь быстро в лапше

В геймдеве вообще сложно без этого

шахматы наверное потому, что легко придумывать новые требования (есть разные шахматы с разными правилами, можно тренировать шахматные этюды, можно добавить примитивный ИИ). Но под эту категорию наверное много игр подходят. > и ты ООП тренькать собрался или разделение ответственности? Я с ФП не знаком, так что мне разделение ответственности без ООП сложно представить. Просто Arky хочет где-то в доке прочитать про разделение ответственности, а нужно ведь не только читать, но и практиковаться.

а учитывая что там геймдев, то ООП очень нужно, иначе погрязнешь быстро в лапше

в гемдеве чуть серьезнее с разделением ответственности)

это да, но это и ивенты, и эктор модел, и много чего еще

типа у тебя есть 4 лифта, и надо максимально утилизировать их загрузку. Пользователи могут на первом этаже указывать куда они хотят

это поэтому я каждый раз 2 лифта отправляю на 20ый этаж чтоб на третьем спуститься в паркинг?)))

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

Но суть в том что пока мы тут рассуждаем о паттернах, ребята на yii2 и процедурщине пилят проекты

А как известно обсуждение бизнесу не приносит профита

что за приравнивание себя к бизнесу?)

А как известно обсуждение бизнесу не приносит профита

а потом бизнес приходит ко мне с вопросом "какого хрена, вроде ребята говорят что все норм сделали а у меня что не релиз то баги"

а я потом сиди аудит делай

что за приравнивание себя к бизнесу?)

Не себя, в целом мы же для чего-то пишем код

а потом бизнес приходит ко мне с вопросом "какого хрена, вроде ребята говорят что все норм сделали а у меня что не релиз то баги"

Да, бывает и такое

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

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

Код пишется для решения поставленной задачи

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

у бизнеса по-умолчанию включены "флажки" чтоб все збс работало

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

так что ориентироваться на него тоже не стоит

и черевато тем что не разберешься ))

вот к примеру возьмем наших соседей из data science

есть там крутые дядьки математики-статистики, которые там себе написали модель на R/Python

но она не годна к проду вообще никак

потому что ее не могут поддерживать никто кроме них, и люди потом портируют их модель на java/scala, чтобы эта моделька была поддерживаемая и приносила какой-нибудь value для бизнеса

вот так и с MVP

нахуярить то можно, но поддерживать и лить в прод это нельзя

Код пишется для решения поставленной задачи

1. решения поставленной задачи 2. качество кода влияет на предсказуемость сроков 3. бизнес парит предсказуемость

Третий пункт не совсем понял

По второму пункту, можно же рассматривать такой вариант. Необходим проект N, ребята по быстрому пилят его CRUDом, внутри полный говнокод, но он как-то работает.

эт MVP или прототип называется

Выходят на рынок - есть профит, переписывают нормально.

ERROR: S client not available

Нет - проект в топку

выход на рынок это не всегда 1-2 месяца

а есть реальный такой опыт?

переписывания проекта который приносит деньги)

выход на рынок это не всегда 1-2 месяца

Да и так-то это не совсем заботы разраба

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

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

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

у нас куда меньше щас времени чем было 3 года назад

ибо появляются доп проблемы, фичи нужно тоже делать, еще ops часть появляется

так что "потом перепишем" это из рубрики "в понедельник в зал пойду!"

п.с разгребаем гавнокод вот щас с коллегой в субботний вечер)

п.с разгребаем гавнокод вот щас с коллегой в субботний вечер)

Symfony?

да

попутно до 3.4 обновились

и готовим к 4.0

Рефакторить говнокод symfony думаю проще, чем тот же yii2 например?

Или умудряются тоже?

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

Например что в приведенном тобой проекте адски неправильно ребята сделали?

использование сущностей в твиге

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

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

В смысле напрямую вызов сущности из шаблона?

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

и дальше for order in user.orders и поехали

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

То есть Users = findBy(status=lol) Render(some view, users) плохо?

То есть Users = findBy(status=lol) Render(some view, users) плохо?

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

в итоге ты связан по рукам с рефакторингом

и это нужно делать очень осторожно, чтобы не похерить шаблоны

и дальше for order in user.orders и поехали

Что-то типо? https://github.com/za4me/symfony.dev/blob/knp/app/Resources/views/genus/list.html.twig