Pull to refresh

Comments 6

У меня всегда вызывает некоторое недоверие код, автор которого не следует naming guidelines.

Почему используете поля вместо свойств для публичных членов? Это какая-то особенность Unity?
данная статья ориентирована скорее на начинающих
Начинающих Unity (как я) или начинающих C#? Если второе, то советую обратить внимание на то, что обьявлять свои делегаты уже давно не нужно, события объявляются используя
EventHandler/EventHandler<T>
И опять же, стоит следовать guidelines, как минимум добавив sender к вашему делегату, а иначе придется внутри обработчика опять обращаться к синглтону, что добавляет связности и усложняет тестирование.

Гайды майкрософта использовать боюсь, поскольку есть такая штука что в Unity есть некоторые различия и на мобильных устройствах все любит отваливается. А сверить как то поленился.(((

Про naming guidelines прошу прощения. Профессиональная болячка при работе в команде где каждый использует свой предпочитаем способ и я использую вырванные куски кода из своего проекта.


В остальном по замечаниям хорошо. Спасибо за советы!

Спасибо за статью. Пара вопросов:

1. Зачем нужен MonoBehaviour ещё и как Singleton для AudioManager?
2. Почему бы

public delegate void AudioSettingsChanged();
public event AudioSettingsChanged OnAudioSettingsChanged;


не заменить в данном случае на:

public Action OnAudioSettingsChanged;
Manager'ы, повсеместная статика, класс с кучей ответсвенностей, Monobehaviour'ы, которые вполне могут быть и обычными классами, кастомные делегаты вместо Action. Это очень плохой код и очень плохое решение поставленной задачи.
Чтобы комментарий был ещё и полезным, было бы грамотно расписать:
— почему повсеместная статика плохо, в каких ситуациях она может привести к проблемам;
— почему классы с кучей ответственностей не следует практиковать, чем их можно бы заменить;
— объяснить, в каких случаях не следует наследовать Monobehaviour и почему;
— в чем разница между делегатами и экшенами, почему в данной ситуации лучше использовать Action вместо делегатов.

Ну а так получается автор и читатели так и не поймут, почему код очень плохой. Я бы конечно попытался расписать и ответить на данные вопросы, но я не имею достаточного опыта, чтобы учить писать код, потому было бы интересно и более важно — полезно почитать обоснование ваших заметок.
Sign up to leave a comment.

Articles