Всем привет! Сегодня я буду говорить о том, как правильно определять действующих лиц и как они структурированы.

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

Перво-наперво, кто такой актер? Это просто объект, перед которым в нашей программе будет стоять конкретная задача, и для этого он обычно имеет состояние и поведение.

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

Вы также должны знать, что модель акторов - это иерархическая модель, поэтому каждый актер является потомком другого актера. Это помогает нам управлять ошибками, концентрируя их на родителях, вы можете узнать больше об этом в официальной документации akka.

Взглянем на код небольшого класса акторов, чтобы мы могли проанализировать его части:

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

Разберем структуру:

  • Первое, что мы видим, это PathQualityResponse, это ответ, который этот субъект вернет запрашивающей стороне, когда он закончит. Рекомендуется объявлять все типы сообщений, на которые будет реагировать субъект, как можно ближе к определению субъекта. В этом случае PathQualityResponse - это не сообщение, на которое этот субъект будет реагировать, но это ответ, который субъект вернет всем, поэтому это хорошее место для его объявления.
  • Затем у нас есть их атрибуты, эти атрибуты формируют состояние этого актера. Изменяемыми являются только атрибуты pendingWorkers и initialTime. При определении актера важно подумать, какие из них изменяемы, а какие нет.
  • Затем у нас есть метод props и конструктор. Props - это класс конфигурации, который вы можете определить как рецепт для создания этого актора, мы никогда не будем создавать никаких акторов, вызывающих его конструктор, вместо этого ActorSystem будет использовать эти рецепты для их создания.
  • Следующим шагом является стратегия наблюдения, здесь вы можете определить, как субъект должен реагировать, когда один из его дочерних элементов терпит неудачу.
  • Методы preStart и postStop являются частью жизненного цикла акторов, preStart вызывается после создания актера, но до того, как он получит какое-либо сообщение, а postStop вызывается сразу после актера. полностью остановлен, обычно для очистки используется postStop.
  • Наконец, мы можем увидеть метод createReceive, который используется для объявления событий, на которые актер хочет отреагировать. В данном конкретном случае у нас есть только одно событие Path . Как видите, реализация поведения не в методе createReceive, а в методе onPath, делая это, мы можем получить более читаемый код. и мы можем четко видеть реализацию каждого события.

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

Надеюсь, вам понравилось читать!