Самый удобный образец ООП-архитектуры игры, который я смог сделать

1313
30 комментариев

ООП - конечно, здорово)

Только все как-то перемешано, очевидно, что нарушен принцип единой ответственности (SRP из SOLID)

Например, у вас есть класс Bullet и он знает очень много)
И про коллайдеры он знает и про перки и про ганера

Из-за этого возникает сильная связанность кода, когда все знают про все и тяжело рефакторить и масштабировать код;

14
Ответить

Подушню. Не единой, а единственной.
"У классов должна быть единая ответственность."
или
"У классов должна быть единственная ответственность."
Чувствуете разницу?

5
Ответить

А еще, в некоторых классах поехала разметка)

3
Ответить

Ипать, мне кажется вообще нельзя выдавать оценочные суждения чужого кода просто вот так один раз посмотрев на него. Ты пишешь, что "возможно вам будет сложно его масштабиршвать". Ты знаешь специфику фич, которые возможно придётся впихивать? Ты представляешь, как именно их можно впихивать? Допустим, ты пишешь простой конвертер одного формата в другой, ты тоже будешь его делать классами?

Ответить

Если каждая сущность в итоге монобех и в них апдейты, то разве не придем потом к https://blog.unity.com/engine-platform/10000-update-calls ?
Как без антипаттернов ООП вроде менеджера, сделать чтобы каждый враг посмотрел на планируемые позиции других врагов в будущем? Что бы они друг на друга не залазили.

3
Ответить

оптимизация нынче не модна

Ответить

Если говорить про чистое ООП, то паттерн service locator решит такую проблему без антипаттернов. Особенно если локатор прокинуть в некий абстрактный класс для всех игровых объектов на сцене. В локаторе найти инстанс планировщика позиций и спокойно использовать их.

Ответить