@Gera01
Unity, С# и больше ничего.

Соответсвует ли код принципам солид?

Есть код, который написан был мной по принципам solid и использованием ооп. Вопрос в том, все ли правильно и чтобы вы посоветовали исправить или добавить? Заранее прошу прощение за всю кровь которая у вас вытечет из глаз, присылайте группу, отправлю почтой)
Клик
  • Вопрос задан
  • 331 просмотр
Пригласить эксперта
Ответы на вопрос 2
K0TlK
@K0TlK
Буллю людей.
Разделять код на миллион монобехов != ооп. Единственный способ достичь правильного ооп в юнити - отделять всю логику от движка, а монобехи использовать как вьюшку, чтобы отображать всякое. Но реализуемый для тебя способ - использовать интерфейсы, под каждый паблик метод отдельный интерфейс, взаимодействовать через эти интерфейсы, учиться нормально прокидывать зависимости: всегда должна быть какая-то точка входа, где будут инициализироваться компоненты и передаваться все зависимости.
Virtual методы = плохо, класс в идеале должен быть либо abstract либо sealed.
Protected поля = public поля = нарушение инкапсуляции/иммутабельности.
PlayerHealth, PlayerEnergy, Health - это все одно и то же с разными реализациями, есть интерфейс IHealth все под него и просто этот интерфейс реализуешь.
AudioPlayer вообще какой-то ужас. Во-первых, почему GameObject takeDamageSourseObject и т.д Почему GameObject, если ты потом получаешь у него компонент AudioSource, ты можешь конкретные компоненты в инспекторе передавать, т.е. не GameObject, a AudioSource и GetComponent потом делать не нужно будет. Во-вторых, из всего этого можно было сделать один компонент, в котором будет один метод Play, который будет принимать AudioSource и проигрывать его. Либо напрямую пропихивать AudioSource и воспроизводить звук.
Нет какого-то единого кодстайла, где-то есть нижнее подчеркивание, где-то нет, где-то есть _cs где-то нет, для чего эта _cs я так и не понял. Где-то сериализуемое приватное поле, где-то тупо паблик.
Про солид вообще смысла говорить нет. Интерфейсов пара штук на весь проект. Зависимости нормально не прокидываются, всё через поля.
Это так, навскидку. Думаю, если зайти в папку bot, то можно будет диссертацию написать по содержимому этой папки.
Ответ написан
@mayton2019
Bigdata Engineer
Есть такой анекдот что на 100 строк разработки Java приходится 10 строк Clojure с точно таким-же
алгоримическим смыслом. Так вот мне кажется что в данном исходнике этот коэффицент еще худе.

Код - по большей части ничего не делает. Он настолько формален и общ, что мне кажется что 50% callbacks можно заинлайнить и кода станет меньше а читаемость пострадает не сильно. Вобщем - редкий случай когда SOLID вместо помощи разработчику - создаёт ненужные абстракции.

У кода - очень неравномерная плотность информации. Например в Weapons/Bow.cs есть метод BallisticVel который резко контрастирует с другим кодом. Тут - как будто клавиатуру взял другой человек и написал в Haskell-style формулу. У меня возникает вопрос. Почему автор так старался декомпозировать всякий формализм а сложную функцию не декомпозировал? Вобщем такая резкая смена плотности информации на квадратный метр исходников - очень настораживает.

В качестве метрики "полезности" - я-бы спросил автора

- Ты бы сам себе заплатил-бы за такой код?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы