Спасибо! Постараюсь пробежаться по всему solid в ближайшее время, материал по ocp осталось озвучить, остальное тоже постараюсь сделать в ближайшие две три недели

Спасибо! На канале есть рубрика "Паттерны на практике" - там я написал простую игру и выложил её на гитхаб и разобрал там решения. Как раз вчера последнее видео залил. Это конечно не запись того как я игру с нуля пишу, но код можете спокойно посмотреть и что-то взять на вооружение.

Сколько месяцев искал работу?

Спасибо)

Поведение и состояние это к паттерну State, но архитектурные проблемы и задачи всей рразработки к данному паттерну не сводятся. Есть куча кейсов когда класс является перегружен, но это никак к состоянию объекта не относится. Именно в таких ситуациях SRP и говорит как именно решать проблему перегруженных классов - разбивать логику по зонам ответственности.

​@@sergeykazantsev1655 зачем нам куча кейсов, когда есть конкретный пример в видео?) Паттерн State?) Поведение и состояние определяют объект. Состояние - это множество полей объекта. Зависимости объектов реализуются через поля. Вы во всех видео говорите исключительно про состояние и поведение объектов. В примере вы связали состояние объекта с его поведением. У этого объекта нет полей, используемых в методах attack и move - очевидно, что эти поля инкапсулированы в некие объекты. Соответственно требуются ссылки на методы этих объектов. Таким образом, классы реализуют то поведение, которое меняет состояние их объектов. SRP. Без неопределенных "одна задача" и "одна причина для изменения". По поводу последнего - в исходном коде стандартной библиотеки найдется много неожиданного.

А... вы про ЭТО поведение и состояние, старая добрая инкапсуляция. Ну хорошо, тогда поехали сначала) " Класс должен реализовывать только то поведение объекта, которое меняет его состояние" - в целом да, вопрос в том, что делать если этого вашего поведения и состояния в одном классе слишком много? "Некорректно выбраны параметры объекта" - это что значит? Как их выбрать по другому? Группировать? Отрезать лишние? Для меня из ваших утверждений решение неочевидно. "У объекта Player нет полей, связанных с Attack, Move и тд" - Я их скрыл от того чтобы текст нормально на слайде уместился. Представьте что в том же классе Player есть поля типа AttackCooldown, weaponDamage, MovementSpeed и тд. Действительно - SRP говорит нам о том что надо создавать новые классы по зонам ответственности, и в один унести всю логику связанную с атакой(опять же поведение и состояние) и так далее

"нужно ли в идеале разбивать классы на отдельные классы, каждый из который должен иметь свою зону ответственности, а потом с помощью композиции связывать их с начальным классом" - ответ да, но в рамках разумного. Нужно оценивать затраты на рефакторинг а также перспективы на распухание конкретно этого класса. Если риск распухания высок - да, лучше сделать как вы сказали Анонимные классы если я вас правильно понимаю(анонимные типы) никак к SRP не относятся так как крупной логики и зон ответственности в себе не несут

телеграм канала нет. В описании есть ссылка на мой личный тг) Пока на канале мало подписчиков в телеграм канале смысла особо не вижу

Конкретно в данном примере я бы сказал что данный пример не нарушает SRP, так как внутри этих расчётов используется одна и та же логика. Пример - берём условную карточную игру "Дурак", кто-то кидает шестёрку. Логика - CanThrowCard(true если карта = 6) и IsCardValid(true если карта = 6) - это по идее один и тот же метод только по разному используемый в разных местах. Бывают более сложные случаи но тут главное не скатиться в перфекционизм который никому в итоге не нужен.В играх есть куча классов которые делают пачку похожих но не одинаковых задач и какой-нибудь зануда-перфекционист ООП-шник может это всё раскритиковать

Спасибо!

На 08:45 как раз на этот вопрос отвечал) Надо смотреть насколько это нужно и насколько оправданно. Если у вас сложная анимация и много логики с ней связано - вынести логику анимации в отдельный класс хорошая идея. Если у вас маленькая игра на 200 строк кода - в этом нет особого смысла

Запросто) есть куча начинающих мидлов которые написали несколько мелких игр, почитали про dependency injection и ECS и считают что ООП им нужен процентов на 30

Да и как раз я был тем кто думал что знаю ООП, но знал его ровно на те 30%