Comments 6
У меня всегда вызывает некоторое недоверие код, автор которого не следует naming guidelines.
Почему используете поля вместо свойств для публичных членов? Это какая-то особенность Unity?
Почему используете поля вместо свойств для публичных членов? Это какая-то особенность Unity?
данная статья ориентирована скорее на начинающихНачинающих Unity (как я) или начинающих C#? Если второе, то советую обратить внимание на то, что обьявлять свои делегаты уже давно не нужно, события объявляются используя
EventHandler/EventHandler<T>
И опять же, стоит следовать guidelines, как минимум добавив sender к вашему делегату, а иначе придется внутри обработчика опять обращаться к синглтону, что добавляет связности и усложняет тестирование.+1
Про naming guidelines прошу прощения. Профессиональная болячка при работе в команде где каждый использует свой предпочитаем способ и я использую вырванные куски кода из своего проекта.
В остальном по замечаниям хорошо. Спасибо за советы!
0
Спасибо за статью. Пара вопросов:
1. Зачем нужен MonoBehaviour ещё и как Singleton для AudioManager?
2. Почему бы
не заменить в данном случае на:
1. Зачем нужен MonoBehaviour ещё и как Singleton для AudioManager?
2. Почему бы
public delegate void AudioSettingsChanged();
public event AudioSettingsChanged OnAudioSettingsChanged;
не заменить в данном случае на:
public Action OnAudioSettingsChanged;
0
Manager'ы, повсеместная статика, класс с кучей ответсвенностей, Monobehaviour'ы, которые вполне могут быть и обычными классами, кастомные делегаты вместо Action. Это очень плохой код и очень плохое решение поставленной задачи.
0
Чтобы комментарий был ещё и полезным, было бы грамотно расписать:
— почему повсеместная статика плохо, в каких ситуациях она может привести к проблемам;
— почему классы с кучей ответственностей не следует практиковать, чем их можно бы заменить;
— объяснить, в каких случаях не следует наследовать Monobehaviour и почему;
— в чем разница между делегатами и экшенами, почему в данной ситуации лучше использовать Action вместо делегатов.
Ну а так получается автор и читатели так и не поймут, почему код очень плохой. Я бы конечно попытался расписать и ответить на данные вопросы, но я не имею достаточного опыта, чтобы учить писать код, потому было бы интересно и более важно — полезно почитать обоснование ваших заметок.
— почему повсеместная статика плохо, в каких ситуациях она может привести к проблемам;
— почему классы с кучей ответственностей не следует практиковать, чем их можно бы заменить;
— объяснить, в каких случаях не следует наследовать Monobehaviour и почему;
— в чем разница между делегатами и экшенами, почему в данной ситуации лучше использовать Action вместо делегатов.
Ну а так получается автор и читатели так и не поймут, почему код очень плохой. Я бы конечно попытался расписать и ответить на данные вопросы, но я не имею достаточного опыта, чтобы учить писать код, потому было бы интересно и более важно — полезно почитать обоснование ваших заметок.
+2
Sign up to leave a comment.
Системы событий в Unity3D