Должен ли я использовать событие для уведомления класса или просто использовать return?

Question

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

Я смоделировал свою идею с помощью класса ExperienceBar.

Содержит свойства:

• int StartValue
• int CurrentValue
• int EndValue

и метод

• void UpdateBar (int)

UpdateBar добавляет параметр в CurrentValue, а затем проверяет, достигло ли оно EndValue. Если оно превышает сумму, EndValue увеличивается, и сумма продолжается. Обратите внимание, что изначально, на мой взгляд, он не связан с эффектами достижения максимально возможной суммы, просто он увеличивает конечное значение и значение StartValue сбрасывается в ноль.

Другой класс с именем Player обладает свойством класса ExperienceBar.

В моей маленькой демонстрации, когда Player.ExperienceBar.UpdateBar (int) достигает EndValue, он запускает событие, которое обрабатывается классом Player. Обновляет свойство Player.Level на единицу.

Я только что понял, что могу добиться того же, просто изменив UpdateBar (int) на тип true. Этот метод может быть протестирован классом Player, и когда true, Player.Level увеличивается на единицу.

Итак, мой вопрос - как лучше всего справиться с этим довольно специфическим обстоятельством? Как общее практическое правило для подобных ситуаций: лучше обрабатывать события или лучше просто упростить тестирование операторов возврата?

PS: Я надеюсь, что объяснил это по возможности, но я могу попытаться уточнить, есть ли у кого-то проблемы. Я полагаю, что с моей идеей уже может быть некоторая избыточность, но постарайтесь не отклоняться от вопроса, пожалуйста. Я вроде о них знаю! Спасибо:)

Answer 1

Ну ... Для меня , события - это хороший способ сделать это.

Однако, если бы я разрабатывал приложение, то был бы вопрос: будет ли событие ExperienceBars, когда оно достигает EndValue когда-либо , использоваться кем-то еще, кроме класса, вызывающего UpdateBar.

Если вы разрабатываете компонент, который будет использоваться во многих местах (что, кажется, является целью), ответ мне кажется почти определенным да , поэтому мой ответ использовать события !

/ Victor

Answer 2

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

Итак, вот в чем дело, если Player будет отвечать за обработку всех вещей, связанных с повышением уровня, тогда наличие тесной связи между Player и ExperienceBar в порядке. Допустим, вы хотите представить инфраструктуру AddIn, в этом случае вы, вероятно, захотите выставить выравнивание до внешних плагинов, и в этом случае событие имеет гораздо больший смысл.

Лично я хотел бы, чтобы XP был частью Player, и я бы Player выставил событие LevelUp, но я не знаю, будет ли это хорошей идеей для вас и вашего моделирования фреймворка / домена не видя ваш существующий код.

Answer 3

На мой взгляд, нет лучшего способа сделать это. Существуют различные способы реализации класса, которые, в зависимости от того, как он будет использоваться, подходят лучше или хуже.

Используйте события, когда вы хотите реализовать шаблон наблюдателя для многих «клиентов» или «наблюдателей», которым необходимо знать состояние объекта и которые должны получать оповещения, когда это состояние изменяется. это работает для вырожденного случая, когда есть только один клиент, но вызывающий метода, который изменяет состояние объекта, не тот, который должен знать об изменении.

Используйте возвращаемые значения, когда состояние должно быть известно только вызывающей стороне, других наблюдателей класса нет. Это просто и ограничивает область знаний о состоянии класса элементом, который должен немедленно его знать.

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

Answer 4

Я бы использовал события, а не возвращаемое значение. Зачем? Две причины:

1. Что означает возвращение true при возврате из UpdateBar? Что было обновлено? Что xyz случилось? Кто-то еще смотрит на это (или вы, через два месяца) тоже удивятся.
2. Что, если при достижении лимита должно произойти несколько вещей? Затем вы должны связать весь код, связанный с этими вещами (выравнивание, получение нового элемента и т. Д.), С методом, который вы использовали для обновления панели в первую очередь.

У меня было бы событие, связанное с достижением определенного уровня, а затем «слушатели» этого события, которые могли бы ответить соответствующим образом.

Answer 5

Я не думаю, что имеет смысл запускать в панели «Опыт» событие - в этом случае возвращаемое значение будет в порядке. Затем он может вызвать функцию PlayerUp LevelUp, которая при необходимости может вызвать событие OnLevelUp из класса Player.