If it's not blatantly obvious, I value the Actor Framework (AF) as an important part of my toolkit. It's not the right tool for every job, but it is a useful tool for many. One part of the AF I don't love is the necessary tedium of building Actor Core event-handling UIs and then dragging reference controls (for my by-reference updates) into the Class Private Data Cluster. This got me thinking... In general, adding controls to a class feels like a relatively clumsy process, even when not using the AF. I let this mild frustration stew inside my melon for years, and then I finally did something about it.
In my last post I took a look at data-centric and message-centric communication and their effects on software systems. This post will take that discussion a little bit further by connecting the idea of data-centric messaging to Event Driven Architecture (EDA). Along the way, we will build up a vocabulary that we can use to disucss systems of actors and the types of coupling we encounter while building them.
Typically the first program you write when you are learning a programming language is, "Hello World!". Due to the popularity of my prior post on optimizing the traveling salesman problem with genetic algorithms I decided to write a general parallelized Genetic Algorithm Framework for LabVIEW, naturally the first thing I taught it to do was to say, "Hello World!".
Communication between Actors is meant to be done by traversing the Actor tree. Assuming we decide not to pass message enqueuers around to all Actors in the tree, we will end up with a lot of message classes and a lot of message routing. The extra messages and routing, however, buys us robustness as Actor E has no way of knowing if Actor C currently exists. But what if we could bypass the tree for certain types of messages in a way that allowed us to decouple our actors from each other...
As writers of software we strive to craft code with high cohesion and loose coupling. This can be tough to do with the Actor Framework as the default method of sending messages between actors effectively couples them together. Depending on your application this coupling may not matter, but I will show you one way to manage it if it does.
The above image illustrates a small section of the flow of control for an application used to calculate properties of a black hole. There is a high level module used to calculate the tidal force that objects experience while near a black hole's event horizon. This tidal force calculation requires the black hole's mass as an input, which is calculated by a lower level module. The high level tidal force module needs the black hole's mass in order to perform its calculation, and it depends on the low level mass module to supply it.