A un objet actif est associé une description comportementale (une machine à état typiquement)
Rien n'oblige à ce qu'un objet actif soit une machine à état formellement. L'instance de ta classe se trouve dans un processus à part entière, et réagit aux messages reçu (qui n'appellent que les méthodes de ta classe en fait).
Certes, ton objet actif se retrouve donc avec un état local, qui n'est pas accessible directement de l'extérieur.
Par contre, où je te rejoins, c'est que cela demande de concevoir son application différemment, en forçant plus sur la modularité. Néanmoins, l'avantage que je préfère des acteurs, c'est que ça permet de créer un système bien plus robuste, dans le sens où chaque acteur peut planter sans faire planter l'application entière : on relance un acteur identique, ou en a déjà plusieurs acteurs qui font le même boulot, et ils traiteront les messages suivants.
[^] # Re: Retour sur les objets actifs
Posté par Jiehong (site web personnel) . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 2.
Rien n'oblige à ce qu'un objet actif soit une machine à état formellement. L'instance de ta classe se trouve dans un processus à part entière, et réagit aux messages reçu (qui n'appellent que les méthodes de ta classe en fait).
Certes, ton objet actif se retrouve donc avec un état local, qui n'est pas accessible directement de l'extérieur.
Par contre, où je te rejoins, c'est que cela demande de concevoir son application différemment, en forçant plus sur la modularité. Néanmoins, l'avantage que je préfère des acteurs, c'est que ça permet de créer un système bien plus robuste, dans le sens où chaque acteur peut planter sans faire planter l'application entière : on relance un acteur identique, ou en a déjà plusieurs acteurs qui font le même boulot, et ils traiteront les messages suivants.