Найти в Дзене

Scala Akka - или ООП по-другому.

Для того, чтобы подмести у поъезда мы не берём за руки дворника и метём, а просто говорим о том, где необходимо подмести. Так и в ООП модели не было ли логичнее не вызывать методы созданного класса, а просто посылать ему сообщение, на которое он будет реагировать?Представляю Вам Akka - акторную модель. Главная и нерушимая концепция Akka - всё есть актор. Но что есть актор, спросите Вы? Акторы - это отдельные сущности, наделённые определённой логикой, взаимодействующей с приходящими к ним сообщениями. У каждого актора есть свой почтовый ящик, где эти сообщения хранятся, и обрабатываются в порядке, в котором они в этот ящик поступили(за исключением специальных преднастроек, меняющих степень важности сообщений). Каждый актор независим от другого, их объединяет лишь акторная система, которая имеет собственный thread-pool, который она использует, отдавая вркеров одному или иному актору. Таким образом обеспечивается многопоточная работа, не требующая от нас собственного контролирования, не в

Для того, чтобы подмести у поъезда мы не берём за руки дворника и метём, а просто говорим о том, где необходимо подмести. Так и в ООП модели не было ли логичнее не вызывать методы созданного класса, а просто посылать ему сообщение, на которое он будет реагировать?Представляю Вам Akka - акторную модель.

Главная и нерушимая концепция Akka - всё есть актор. Но что есть актор, спросите Вы? Акторы - это отдельные сущности, наделённые определённой логикой, взаимодействующей с приходящими к ним сообщениями. У каждого актора есть свой почтовый ящик, где эти сообщения хранятся, и обрабатываются в порядке, в котором они в этот ящик поступили(за исключением специальных преднастроек, меняющих степень важности сообщений). Каждый актор независим от другого, их объединяет лишь акторная система, которая имеет собственный thread-pool, который она использует, отдавая вркеров одному или иному актору. Таким образом обеспечивается многопоточная работа, не требующая от нас собственного контролирования, не вызывающая race-condition и пр.

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

В Scala для этих самых сообщений принято использовать case-classes, которые крайне удобно матчить на приёме актора. Внутри нашего класса приём сообщений будет выглядеть примерно следующим образом:

def receive = {

case MailOne(msg) => ???

case MailTwo(msg)=> ???

}

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

Если Вам интересна эта тема, может стоит написать серию статей с примера использования Akka?