OOP Design Patterns in Actor Framework Part 2

Design Patterns , OOP

Samuel Taggart

Mar 3, 2019 • 4 min read

This is a continuation of my previous post on GOF Design Patterns in the Actor Framework. I found a lot of examples, so I decided to break it into 2 posts. You can access part 1 here and my review of the GOF Book here. Part 1 showed examples found in the Actor Framework itself. In this post we will talk about some examples that use the Actor Framework to implement a design pattern.

Proxy

If you have taken the AF class, you may remember that there was a lesson on calling actors from synchronous code. The basic idea was to start with an actor that was written to be called by another actor, so any data it returns is sent via abstract messages. The problem presented is how to reuse this actor in a non-AF synchronous project. The solution was to write a proxy actor that launches your original actor and forwards messages to it. You then hide that actor inside a synchronous API class which is what your synchronous code calls.

When you initialize the synchronous API class, it creates some references (queues, notifiers, etc) and passes them to the proxy actor before launching it and grabbing it’s enqueuer. To send commands the API sends them to the proxy, which forwards them. When the proxy get’s a message back from the original actor, it stores the data in the references provided by the API class. The API then has methods to allow the synchronous calling code to access the data in the references synchronously. Closing the synchronous API shuts down the actors and closes all the refs.

Remote Proxy

Network Endpoint override of Recieve Message.vi

Network Endpoints are a great example of a remote proxy. The calling actor interacts with the network endpoint as it would any other actor. It sends messages using the Network Endpoint’s enqueuer. The Network Endpoint overwrites receive message.vi to forward those over the network. The caller can also receive messages back. The Network Endpoint has a helper loop in its Actor Core that monitors the network connection and sends any messages it receives over the network back to the caller using its enqueuer. From the point of view of the caller, it doesn’t care that the end recipient of the messages is on the other side of the network connection.

State Pattern

The State Pattern Actor is a great example of an implementation of the state pattern using Actor Framework. The UML above is from the State Pattern Actor Sample Project. The Process Actor represents a State Pattern Actor for a particular process. In this case, the process has 2 states: Idle and Running. Each is a child class of Process Actor. Each can have its own data, handle messages in its own way, and execute logic on enter and exit. From the point of view of the caller the running Process Actor seems to switch between the various states. Process Actor is a placeholder for any logic or data that is common to all of the states. Due to the nature of the AF, it also handles the GUI.

The State Pattern Actor is also a great example of how different patterns can work together. In the UML class diagram above, the State Pattern Actor acts as a template. It makes sure that when changing from one state to another that:

The current state has the opportunity to execute an action on exit.
Any data is preserved.
The new state has the opportunity to execute an action on enter.

The State Pattern actor core also acts as a template. It makes sure that initial state executes its action on enter and that when actor core stops that the final state executes its action on exit.

Mediator

Ethan Stern has come up with something called the MVA Framework. It is an implementation of the Model View Controller using a variety of GOF patterns, most notably the Mediator pattern. It is built on top of the Actor Framework. The top-level actor is a Controller (which he calls a viewmodel) which launches 2 separate actor hierarchies (1 for the view and one for the model). It also launches a 3rd Actor called a Mediator which mediates communications between the view and the model. He also uses the Composite Pattern to have views that contain other views and build really complicated UIs. I can’t really do it justice here. I suggest you watch Ethan’s presentation from the CLA Summit.