Ha senso avere messaggi vuoti, per invocare semplicemente un attore?

Question

Ha senso avere messaggi vuoti, per invocare semplicemente un attore?

#1 da (2 voti)

1

Sto acquisendo familiarità con una base di codice Akka.NET esistente e con il modello di attore stesso, e noto che un certo numero di attori sono configurati per ricevere messaggi vuoti e fare il loro lavoro.

class Invoke
{
}

class MyActor : ReceiveActor
{
    public MyActor()
    {
        Receive<Invoke>(i => /* do work */);
    }
}

L'uso di una classe personalizzata Invoke invece di una classe ipotetica fornita dal framework mi mette in dubbio questo tipo di utilizzo. Ho provato a trovare informazioni su Google, ma i vari termini di ricerca non hanno prodotto risultati interessanti.

Questo tipo di utilizzo ha senso nel modello degli attori? Forse non sto usando i termini di ricerca giusti? O il modello dell'attore è usato impropriamente qui?

actor-model

posta Stijn 10.07.2017 - 13:12

fonte

1 risposta

Leggi altre domande sui tag actor-model

La tecnica del percorso di base (derivata dalla complessità ciclomatica) può essere utilizzata su un codice non sorgente? Dichiarazione di una funzione senza parametri denominati che accetta almeno 1 argomento

score 2 · Accepted Answer

Capisco la tua domanda, ma mi piacerebbe dare qualche spunto di riflessione qui: ha senso avere un "vuoto" prima del nome di ciascun metodo che non restituisce un valore? Come il vuoto pubblico DoWork (); ?

Il pattern di messaggistica di Akka è una convenzione, rendendo esplicito per il programmatore che sta chiamando un oggetto da qualche parte in modo asincrono, e la convenzione afferma che tu passi messaggi ovunque, anche messaggi vuoti.

Qual è la differenza tra chiamare il metodo DoWork1 () su un oggetto o DoWork2 () sullo stesso oggetto? Il nome del metodo, solo.

Come esercizio, pensa ai messaggi come ai nomi dei metodi che vuoi eseguire sull'oggetto remoto. Questa è una buona ragione per non avere un Message.Empty predefinito, perché ciò significherebbe che ogni oggetto nel tuo framework che esegue un lavoro senza restituzione o nessun parametro dovrebbe gestire questo messaggio e questo può portare a confusione nell'esempio sopra.

Che cosa succede se si dispone di un attore che gestisce 2 diversi lavori senza parametri? Vuoi dichiarare:

class MyActor : ReceiveActor
{
   public MyActor()
   {
      Receive<Message.Empty1>(i => /* do work 1 here */);
      Receive<Message.Empty2>(j => /* do work 2 here */);
   }
}

Non ti sembra strano per te?