Агенты Scala - худшие методы? [закрытый]

• По возможности избегайте !? . Вы получите заблокированную систему!

• Всегда отправлять сообщение из потока подсистемы актора. Если это означает создание переходного Актера с помощью метода Actor.actor , пусть будет так:

  case ButtonClicked (src) => Actor.actor {controller! SaveTrade (trdFld.text)}

• Добавьте обработчик «любое другое сообщение» к реакции вашего актера. В противном случае невозможно определить, отправляете ли вы сообщение не тому актеру:

  case other => log.warning (это + «получено неожиданное сообщение» + другое

• Не использовать Actor .actor для ваших основных актеров, вместо подкласса Actor . Причина в том, что только путем создания подклассов вы можете предоставить разумный метод toString . Опять же, отладка акторов очень трудна, если ваши журналы завалены такими заявлениями, как:

  12:03 [INFO] Отправка RequestTrades (2009-10-12) в scala.actors.Actor $ anonfun $ 1

• Задокументируйте актеров в вашей системе, явно указав, какие сообщения они будут получать и как именно они должны рассчитывать ответ. Использование акторов приводит к преобразованию стандартной процедуры (обычно инкапсулированной в метод) в логику, распределяемую по реакциям множества акторов. Легко заблудиться без хорошей документации.

• Всегда убедитесь, что вы можете общаться со своим актером вне его цикла react , чтобы найти его состояние. Например, Я всегда объявляю метод, который будет вызываться через MBean , который выглядит как следующий фрагмент кода. В противном случае может быть очень сложно определить, запущен ли ваш актер, отключился, имеет ли большая очередь сообщений и т. Д.

.

def reportState = {
  val _this = this
  synchronized {
    val msg = "%s Received request to report state with %d items in mailbox".format(
                   _this, mailboxSize) 
    log.info(msg)
  }
  Actor.actor { _this ! ReportState }
}

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

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