Download and Login to the NIWeek Mobile App

VIEW FIND BUILD

WEEKLY SCHEDULE YOUR SESSION YOUR SCHEDULE

More Information at [Link]/niweek

OO: SOLID Actor Programming
Dmitry Sagatelyan
Certified LabVIEW Architect
LabVIEW Champion
sagatedm@[Link]

Arktur Technologies LLC NIWeek 2018

 Abstract
Presentation discusses how applying SOLID Design Principles affects design and architecture of actor-
based software. It covers the following topics:
• Why you should use SOLID Principles?
• Brief SOLID Principles Recap
• What is Actor Programming?
• Actor Programming Best Practices
• Actor Programming and SOLID Principles
• Messaging Topologies
and concludes with a summary:
• Consider using SOLID Principles to :
• Adapt Application Code to Requirements changes at incremental cost
• Substantially increase Code Reuse Levels
• Enable design of Plug-In Architectures
• Actor Designs based on Command Pattern are SOLID-unfriendly
• Do proper due diligence before committing to a particular Actor Design or Framework
• Message Brokers provide SOLID support for Hybrid Messaging Topology

NIWeek 2018 OO: SOLID Actor Programming 4

 About Myself …
• Software Engineer by Training
• Masters of Science in Computer Science
• Using LabVIEW since 1998 (LV 5.0)
• Certified LabVIEW Architect (2012 – 2022)
• LabVIEW Champion
• Passionate about:
• Using Contemporary SW Engineering Methods in LabVIEW (ex: SOLID Principles)
• Actor Programming
• Regular presenter @ NIWeek, CLA Summits, Bay Area LUG
• Designed several Actor Frameworks (2005/07/11/15)
• Designed ArTLib – a first (?) LabVIEW Reuse Library built on SOLID Principles (2011-18)
• Full Time LabVIEW Consultant in San Francisco Bay Area (Arktur Technologies LLC)
• Presentation List

NIWeek 2018 OO: SOLID Actor Programming 5

 Presentation Outline

1. SOLID Principles Recap

2. What is Actor Programming ?
3. Actor Programming Best Practices
4. Actor Programming and SOLID Principles
5. Messaging Topologies
6. Q&A

NIWeek 2018 OO: SOLID Actor Programming 5

 Manifesto for Agile Software Development
2001

2017

Robert C. Martin
AKA ‘Uncle Bob’

2003

“Simplicity – the art of maximizing the amount o

f work not done – is essential” 2017
NIWeek 2018 OO: SOLID Actor Programming 7
 Why Use Agile OO Design Principles ?
Observation 1:
“We live in a world of changing requirements …” (1)
Observation 2:
“Requirements change in ways that the initial design did not anticipate” (2)
Goal:
“… make sure that our software can survive those changes” (1)

Using Agile Design Principles allows to:

1. Adapt code to requirements changes at incremental cost
2. Substantially increase your code reuse level
3. Enable design of plug-in architectures with no extra effort

NIWeek 2018 OO: SOLID Actor Programming 8

 SOLID Principles Package Design Principles
Applied at Module Level Applied at Component Level
(.lvclass & .lvlib) (VIPM & NIPM Packages, PPLs)

REP The Reuse-Release Equivalency Principle

ADP The Acyclic Dependency Principle
SRP The Single Responsibility Principle CCP The Common Closure Principle
OCP The Open-Closed Principle
LSP The Liskov Substitution Principle
ISP The Interface Segregation Principle CRP The Common Reuse Principle
DIP The Dependency Inversion Principle SDP The Stable Dependencies Principle
SAP The Stable Abstraction Principle

NIWeek 2018 OO: SOLID Actor Programming 9

 Design Smells – The Odors of Rotting Software
1. Rigidity – The system is hard to change because every change forces many other
changes to other parts of the system
2. Fragility – Changes cause the system to break in places that have no conceptual
relationship to the part that was changed
3. Immobility– It is hard to disentangle the system into components that can be reused in
other systems
4. Viscosity – Doing things right is harder that doing things wrong
5. Needless Complexity – The design contains infrastructure that adds no direct benefit
6. Needless Repetition – The design contains repeating structures that could be unified
under a single abstraction
7. Opacity – It is hard to read and understand. It does not express its intent well

[1] Robert C. Martin, p.88

NIWeek 2018 OO: SOLID Actor Programming 10

 Design Examples Theme

Loading Robot

GUI Fluidics
Peltier
Peltier

Pump Manifold Valve

XY Stage Sample Scanner

Z Stage Camera
Interlocks

Light Source Excitation Shutter Filter Wheel ...

NIWeek 2018 OO: SOLID Actor Programming 11
 The Single Responsibility Principle
“A class should have only one
reason to change”
Calls
Scanner Camera DXCC33

Shutter HF202HT

Blatant SRP Filters HF200HT

Violations ! Xenon Lamp

Changes & Fixes to Device Handling IX83 Z Stage

Methods requires regression testing
of Scanner GUI and Workflow Ludl XY Stage
implementations …

OO: SOLID Actor

NIWeek 2018 12
Programming
 The Single Responsibility Principle
“A class should have only one
reason to change”
Switching to other Configuration formats (INI, XML , JSON, etc.) or other
storage media (files, database) requires changes in class code – triggering
regression testing of Scanner GUI and Workflow implementation …

SRP Violation ! Simple Fix : Pass Configuration cluster into class

Constructor and return it from class Destructor.
Works for 90% of Use Cases …
OO: SOLID Actor
NIWeek 2018 13
Programming
 The Dependency Inversion Principle (A)
“A. High level modules should not depend on low level
modules. Both should depend on abstractions”
Calls Implements
Scanner Camera Sony DXCC33

Excitation Shutter HF202HT

Filter Wheel HF200HT

“Abstraction”
means Interface Light Source Xenon Lamp

Z Stage IX83 Z Stage

Important in
Design of Inversion of XY Stage Ludl XY Stage
Plug-In Ownership
Architectures

NIWeek 2018 OO: SOLID Actor Programming 14

 The Dependency Inversion Principle (B)
“B. Abstractions should not depend on details.
Details should depend on abstractions”

Abstraction is a metaphor – it “Abstraction: the

does not change when details amplification of the essential
change and the elimination of the
irrelevant” ([1] p.194)

DIP.B provides guidance for building Interface Hierarchies

OO: SOLID Actor
NIWeek 2018 15
Programming
 DIP.B Example : Sample Scanner
What is ESSENTIAL for Sample Scanning ?
Sample Scanner Sample API
Move_To
(Image ID)

Set (Dye, %) Snap (T msec)

Excitation API Imager API 2-Axis Stage

Light Source
Has a Has a CCD Camera
Filter Wheel Excitation Imager
1-Axis Stage
Excitation Shutter Scanner Business Logic is decoupled from
details irrelevant to Sample Scanning

NIWeek 2018 OO: SOLID Actor Programming 16

 Dependency Injection Pattern = Container
“A. All
High level classes shouldAll
application- not depend
Reusable on low level
Objects
specific code
classes. Both should depend on interfaces”
Assembler Class:
Creates
Configures
Injects

Where to Create and Configure Objects

Assembler Class : used by High Level Classes ?!
1. Groups all application-specific details (as it knows everything about the application)
2. Configures application-wide subsystems (Configuration Management, Logging, Error
Handling, Messaging Support)
3. Instantiates and configures reusable class instances (objects)
4. Injects Dependencies (low-level objects) into high-level objects

NIWeek 2018 OO: SOLID Actor Programming 17

 Dependency Injection UML Diagram
Creates Inversion of Ownership
Configures
Injects Imager

Assembler
Runs Scanner
Sample Scanner
1. Create & configure Imager
2. Create & configure Scanner
Calls 3. Inject (pass) Imager object
into Scanner object
Imager Interface
4. Run Scanner object
Creates
Configures Implements
Injects into Scanner
Imager

1. Assembler knows concrete types of Scanner & Imager classes (application-specific details)
2. Scanner & Imager Objects and associated References have lifetime of Assembler Object
(i.e. application lifetime) by design

NIWeek 2018 OO: SOLID Actor Programming 18

 The Open-Closed Principle
“Software entities should be open for extension,
but closed for modification”
Don’t Do
Pike Camera Camera

Add Change Extending the behavior of an Implements

existing class should not result in
changes to the source or binary Base Pike
code of the class …
Extends

Async Pike

NIWeek 2018 OO: SOLID Actor Programming 19

 The Liskov Substitution Principle
“Subtypes must be substitutable for their base types ”
1. Class Contract: declares preconditions and post-conditions for each method
(input types/ranges/default values, generated results/default
values/errors/events)
2. A Child Class shall never violate its Base Class contract
3. In OOP Inheritance (“is a” relationship) is all about behavior
4. LSP enables use of OCP and DIP (substitutable behavior)
5. Eiffel natively supports Design by Contract. LabVIEW does not …
6. But Contracts can be also specified by writing Unit Tests for the Base Class
7. LSP compliance can be verified by running Base Class Unit Tests on a Child Class
LSP Violation : X,Y are in ‘mm’,
while Interface specifies ‘inches’
LSP Violation : LSP Violation : LSP Fix : implement Soft Home
unexpected Error Degenerate Method in Cheap Stage Driver

OO: SOLID Actor

NIWeek 2018 20
Programming
 The Interface Segregation Principle
“Clients should not be forced to depend
on methods that they do not use.”
HT Scanner Assembler

Calls Calls Calls

Sample Scanner Fluidics

Sample Scanner
Calls Fluidics
Calls

Calls
Scanner Config Calls
Fluidics Config

Implements Implements
Requires Multiple Inheritance
HT Configuration Handler for by-value G Interface
implementations !!!
NIWeek 2018 OO: SOLID Actor Programming 21
 SOLID Principles Summary

Before … … after

2017 … never bend a nail again. Ever.

OO: SOLID Actor
NIWeek 2018 22
Programming
 SOLID Principles References
General
[1] Agile Software Development, Robert C. Martin, Prentice Hall, 2003
[2] Clean Architectures, Robert C. Martin, Prentice Hall 2017
[3] Inversion of Control Containers and the Dependency Injection Pattern, Martin Fowler, 2004

For LabVIEW Developers

[4] TS9518: How Applying Agile SW Design Principles Changed My Designs and Code, Dmitry Sagatelyan,
NIWeek 2016
[5] Computer Science for the G Programmer, Year 1, Stephen Loftus-Mercer, Jon McBee, NIWeek 2014
[6] Computer Science for the G Programmer, Year 2, Stephen Loftus-Mercer, Jon McBee, NIWeek 2015
[7] Principles of Package Design, Jon McBee, CLA Summit 2016, Austin

Applying SOLID Principles in LabVIEW

[8] TS0251 : SOLID Error Handling, Dmitry Sagatelyan, NIWeek 2017
[9] Design Pattern: Multiple Interface Support in G, Dmitry Sagatelyan, LabVIEW Best Practices Forum, 2016

NIWeek 2018 OO: SOLID Actor Programming 23

Models of Process Interactions
1. Implicit Model (G compiler partitions code
into clumps)

2. Shared Memory Model

3. Message Passing Model

NIWeek 2018 OO: SOLID Actor Programming 24

Shared Memory Model
1. Shared-Memory Model uses threads & shared state/resources
2. Multiple threads of execution communicate by writing to and
reading from a memory location accessible to all threads
3. In LabVIEW, a Race Condition may happen when two or more
threads attempt writing to shared memory at the same time.
4. Race Conditions may be avoided by obtaining exclusive access to
shared memory while writing/reading data (ex: Semaphores)
5. Locks may lead to another (more severe) issue – Deadlocks
6. When locks on two resources are acquired in inverse order, both
threads would eventually ‘deadlock’
7. Race Conditions and Deadlocks are notoriously hard to reproduce

“If debugging is the process of removing bugs, then

programming must be the process of putting them in”
Edsger W. Dijkstra

NIWeek 2018 OO: SOLID Actor Programming 25

 Actor Model of Computation
• Actors are universal primitives of concurrent computation Prof. Carl Hewitt
MIT, Computer Science Lab, 1975

• Messages are the universal units of communication

Hypothesis:
• Types enable secure communication with any Actor “All physically possible
• When an Actor receives a message, it can concurrently: computation can be
1. Send messages to Addresses of other Actors directly implemented
using Actors”
2. Create new Actors
3. Designate how to handle the next message it receives
(by changing its state) Actor
Mes
sage
• Actor Programming is loosely based on Actor Model of
Computation (55 frameworks/libraries in 22 languages)
Message
Transport

NIWeek 2018 OO: SOLID Actor Programming 26

 Actor Implementation in LabVIEW

LabVIEW Actors are Message

Handling Loops (MHLs)

Race Conditions
A lesser chance of Race Conditions
and Deadlocks, but be careful
when :
• Communicating with Helper
Loops
• Using blocking Request-Reply
Deadlocks
messages

NIWeek 2018 OO: SOLID Actor Programming 27

 Types of Messaging Architectures
Data Only Messages Executable Messages
(Command Design Pattern)

LapDogAPI, ~2010 (aka Agile Actors?)

JKI State Machine Objects, 2013 Actore [Link]

Delacor Queued Message Handler, 2014 (?)

Messenger Library for LabVIEW, 200X (?) NI Actor Framework (AF), 2010
ArT_Message_Broker, 2015 ArT_Actors, 2011

NIWeek 2018 OO: SOLID Actor Programming [20] AF Example by Stefan Lemmens 28
 Actor Programming Best Practices
[Link]: Actors do things to themselves (are self-deterministic)
[Link]: Actors can receive any message at any time
[Link]: Actors are not Job Processors
[Link]: Callers have no jurisdiction over Message Priorities
[Link]: Avoid using Self-Message Sequences
[Link]: Avoid using blocking Request-Response Messages (DS:
too limiting)
[Link]: Avoid using direct messaging. Message along Actor Tree
instead (DS: too limiting)
[12] Fundamentals of Actor-Oriented Programming
Dave Snyder (AKA Daklu), CLA Summit 2014, Austin

NIWeek 2018 OO: SOLID Actor Programming 29

 Actors Do Things to Themselves
1. Things are not done to an Actor – Actor does things to itself
2. Messages are Requests – not Commands
3. Actor does not share its state and/or internal resources
with other Actors (no locking required)

Example: Scanner Actor should not lock Camera Actor while

performing a Scan – instead, Camera Actor should reject or
ignore incoming Requests based on its internal state and
business rules Unconditionally executes [Link]

Example: AF implementation does not comply with this

practice as AF Actors unconditionally (independent of state)
execute all received messages …
Actor
Actore [Link]
State

NIWeek 2018 OO: SOLID Actor Programming 30

 Actors Can Receive Any Message At Any Time
1. Actors have no control over who has their address
2. Actors send messages on their own schedule
3. Actors have to gracefully handle unexpected messages

Log & drop all

unsupported
messages

Branch on
Message
Subject Log & drop all
messages of
unexpected type
Check
Message
Type

NIWeek 2018 OO: SOLID Actor Programming 31

 Actors Are NOT Job Processors
1. Well-behaved Actors should process incoming messages as they arrive – without By-Value
Object
creating message backlogs
2. Use dedicated Helper/Worker Loops for executing ‘longer’ actions (i.e. Jobs)
3. Actors may keep some subsystems as by-value objects
Nested Helper
4. Helper Loops might evolve into Nested Actors and vice versa Actor Loop

From Actor Model view there is no difference between an Actors and Helper Loop
However, from a practical point:
a. Helper Loops are designed to handle a single task (simplicity)
b. Helper Loops should not be visible outside of Actor (encapsulation)
c. Helper Loops do not have to use Actor Message Transport type
d. Actors extend the base Actor class. Helper Loops do not
e. Helper Loops may be implemented as private/protected actor class methods
f. Helper Loops need their own State Data (thus, it would take more effort to keep
Actor State in-sync with Helper Loops State)

NIWeek 2018 OO: SOLID Actor Programming 32

 Avoid Using Message Priorities
1. Using Helper Loops for handling time-consuming tasks makes Message
Priority unnecessary
2. As actors are fully responsible for their state & behavior I consider
having a need for Message Priority a Design Smell – perhaps one
needs to re-evaluate actor responsibility assignment in such case …
3. Regular Messages and Interrupt Messages (insert at front) are
sufficient for most use cases. Cancel/Abort messages should be
implemented as Interrupts
4. It might be important improving Actor/Helper Loop ‘interruptability’
5. Getting rid of Priority Queues reduces application complexity

NIWeek 2018 OO: SOLID Actor Programming 33

 Avoid Using Self-Message Sequences
1. It is harder to understand business logic implemented using “…our intellectual powers are rather
Self-Message Sequences geared to master static relations and
… our powers to visualize processes
2. It is ridiculously hard implementing complex workflows (in
evolving in time are relatively poorly
need of if-then-else and loops) using Self-Message Sequences developed” Edsger W. Dijkstra
– as control logic is part of a call site – not part of Message
implementation …
3. Self-Message Sequences do improve Actor “interruptability”
(the only reason I occasionally use them)

NIWeek 2018 OO: SOLID Actor Programming 34

 Avoid Using Blocking Request-Response Messages
1. Risk of Deadlocks
2. Often used just to Get_Value from Nested Actors (bad
programming habit) – start using Publish/Subscribe
instead
3. They do have a very important and safe use case: Deadlocks
implementing complex workflows using dataflow
diagrams inside Helper Loops
4. I often use blocking Requests for the above use case.
And so should you …
5. More details in my 7x7 presentation @ Austin CLA
Summit (September 2018)

NIWeek 2018 OO: SOLID Actor Programming 35

 Command Pattern: ArT_Actors Project (2011)
Features beyond AF 3.0 : “In many applications, a state machine
written to represent one subsystem or
1. Split Actors into a Functional Aspect (Actor Classes) and piece of hardware would be duplicated in
Messaging Aspect (Actor Component has the Actor Core) its entirety to support another similar
2. Ensure Zero Coupling Solution is enforced ‘by-design’ subsystem or piece of hardware”
3. Replace Actor Messages with Actor API Classes for well-
[16] Using the Actor Framework 3.0 in LabVIEW
controlled actor access (Actor APIs encapsulate Actor
Messages) Creates

4. Decouple Actors Components from Message Transport

Sends

implementations
5. Enable Messages to be sent in blocking/non-blocking mode,
with/without a Reply Message based on call site settings
6. Support Publish/Subscribe Messaging Has a …
Executes

Calls

[14] ArT_Actors: A Step Beyond Actor Framework 3.0 ?

NIWeek 2018 OO: SOLID Actor Programming 36

 Actors and SOLID Principles
Data Only Messages Command Pattern
(Actor Framework Example)
Inject
Request
Actor A Class Object
??? Caller Class
Creates
Sends Has a … Sends
Calls Method
Data Message Class Sends
Response Class
Receives
Processes

Actor B Class Caller Nested Actor

Dependency Request Class Response Class Dependency
Interface Interface

Request Class
Sends
“Simplicity – the art of Calls Method Sends Has a …
maximizing the amount of ??? Nested Actor Class
work not done – is Inject
Response

essential” [17]
Object
High
ZeroSOLID
Coupling
Solution
Solution
Efficient Actor Framework Development: Str
ucture and Messaging
NIWeek 2018 OO: SOLID Actor Programming 37
 Actors and Command Pattern
Development overhead for each Actor Take Home Message: Do due diligence
Message (Request or Response) : 5 files prior to using Command Pattern based
• One Abstract Message Class Actors on your Project
(.lvclass, [Link]) • Implement a smaller-scale non-
• One Message Class (.lvclass, [Link]) critical project using the framework
• One Accessor Method of choice
([Link]) • Make incremental changes to
requirements and implement such
Design Smells changes to estimate project
• Viscosity maintenance costs
• Needless Complexity • Do a code review with your team and
• Opacity solicit their feedback

Actor Designs based on Command Pattern

are SOLID-Unfriendly !
NIWeek 2018 OO: SOLID Actor Programming 38
 Messaging Topologies
1. Direct Messaging (Peer-2-Peer) Cons:
• Hard to understand ‘subsystem’ behavior (fuzzy subsystem boundaries)
• Hard to troubleshoot system-wide behavior – Direct Messaging couples Scanner Abstraction
Layer
Actors to global context …. (similar to global variables) Boundary
Excitation Imager
• Increases configuration/runtime coupling between Actors and static
coupling between Actor classes (in case of Command Pattern)
• Note: AF [currently] discourages Direct Messaging
Shutter Camera Z Stage
2. Hierarchical Messaging (Actor Tree) Cons: Open?

• Introduces Message propagation delays

Shutter Topic
• Messages might cross Abstraction Layer Boundary
• Smells of SRP violation – an Actor has to have code for routing messages
between Nested Actors (not part of its functional responsibilities)
• Overly restrictive – limits Actor interaction opportunities
3. Hybrid Messaging (Message Bus) – encourages using Hierarchical Messaging
for Request Messages and allows using Direct Messaging for Event Messages

NIWeek 2018 OO: SOLID Actor Programming 39

 Message Types
1. Request – a message sent to a specific address, requesting to carry out an action[s]
on sender’s behalf (future)
2. Event – a message issued by Actor notifying about Actor’s change of state (past)
3. An Actor may decide to change state (take action) upon receiving an Event
(example: interlock events)
4. Hybrid Messaging encourages using Direct Messaging for Events and Hierarchical
Messaging for Requests
5. Direct Event Messaging may be efficiently implemented using Publish/Subscribe
Pattern
6. Publish/Subscribe creates an “Event Data Bus” for each Topic. Topics with multiple
Publishers may be used as [sub]system-wide Billboards
7. Message, Event & Request are highly overloaded & vague terms – I use them in a
way that may not match their use in Reactive Programming or some other
“programming” niche …

NIWeek 2018 OO: SOLID Actor Programming 40

 Most Systems Have Multiple Aspects
Legend :
Start Scan
Requests
1. Functional (what it does)
Pause Scan
Events
Resume Scan
Events
Cancel Scan
2. Safety (Enclosure Doors/Interlocks) GUI
Set (Dye,%)
Scanner
Snap (T msec)

3. System Monitoring Excitation Imager

4. Etc.
Inter
Shutter Camera Z Stage
Locks
SRP: “A class should have only
one reason to change” Data
Shutter Topic

Bus
Interlocks Topic

• How to integrate support for multiple Aspects into the same class/actor without
coupling Aspects to each other?
• How to propagate cross-aspect Messages without coupling Actors ?
Issue: Do not expect cross-Aspect Messages to be compatible !
Solution: Use cross-Aspect Message Translation to avoid FRAGILITY !
NIWeek 2018 OO: SOLID Actor Programming 41
 Message Translation (Semantic Decoupling)
Improved
Simple Shutter
Shutter
Message Translation :

• Must be executed by Publisher

• Must be decoupled from Publisher

•It is configured by App Assembler

as part of Topic Name Mapping
On “[Link] FALSE” Request :

If (Open? == TRUE) then CloseShutter () ;

DisableShutter () ;

Abstract Message
Translator Object

NIWeek 2018 OO: SOLID Actor Programming 42

 Ad Hoc Publish-Subscribe
Pros:
• Publishers are decoupled from Subscribers + Subscribe (Topic Name, Message Transport)
+ Unsubscribe (Topic Name, Message Transport)
Cons:
• Publisher has to implement Publisher
Interface & maintain Topic Subscriber Lists
Publisher Subscriber Class
(possible SRP violation ?) Subscribe
Unsubscribe
• Subscribers must have Publisher reference Receives
Processes
to send it Subscribe/Unsubscribe Implements

messages at runtime Publisher Class Message

Creates
• Publisher must be up and running prior to Has a: Broadcasts
Subscribers sending it Subscribe messages
(imposes restrictions on Actor
Initialization Order - may be a major issue
for large applications)
Can we do any better ?

NIWeek 2018 OO: SOLID Actor Programming 43

 Mediator Design Pattern

Mediator defines an object

that controls how a set of
objects interact.

1. Planes communicate with Control Tower – not with each other

2. Control Tower imposes constraints (Policies) on arriving and departing Planes
3. Mediator Pattern promotes Object Decoupling (i.e. is SOLID-friendly)

NIWeek 2018 OO: SOLID Actor Programming 44

 Asynchronous Event Aggregator

Event Aggregator
Publisher 1 Topic 1 Subscriber 1
Topic 2
Publisher 2 Topic 3 Subscriber 2
Topic 4
… … …
Publisher N Topic K Subscriber M

1. Decouples Publishers & Subscribers from each other

2. Decouples Publishers from Topics
3. Supports 1:1, 1:M or N:M Message Routing
4. Objects may Publish and/or Subscribe to multiple Topics
5. Removes constraints on Object Instantiation Order

NIWeek 2018 OO: SOLID Actor Programming 45

 ArT_Message_Broker Design
Uses
Message Transport Client Transport
Implements
Uses
Uses
Uses Message Client Message
Implements
Uses

Calls
MB Interface Client
+Subscribe
+Unsubscribe Publisher Objects
+Register_Publisher Subscriber Objects
Implements
+Unregister_Publisher
LVQ_MB API
“Always two there are, Message Broker = Event Aggregator
Calls
no more, no less”, Yoda + Message Translation
LVQ_MB

A ‘by reference’ Message Broker Class

NIWeek 2018 OO: SOLID Actor Programming 46
 Message Broker Command & Message Flow
Register_Publisher (Topic Name, &Topic MT)
Unregister_Publisher (Topic Name, &Topic MT)
Message Broker Subscribe (Topic Name, My Transport)
Unsubscribe(Topic Name, My Transport)
(a ‘by reference’ shared Object)

Calls Calls

Spawn
Subscribe
Unsubscribe
Stop

Sends Data Messages Broadcasts Data Messages to all Subscribers

NIWeek 2018 OO: SOLID Actor Programming 47

 Message Broker Use Example

As simple as it gets …

ArT_Event_Aggregator Library
NIWeek 2018 OO: SOLID Actor Programming 48
 Actor Decoupling Flavors
1. Spatial Decoupling: Publishers & Subscribers do not need to know each other’s
address/reference (keeps Actors location-agnostic) . Any proxy code necessary to
communicate across EXE boundary resides inside Message Broker & Message Transport
code …

2. Temporal Decoupling: Publishers do not need to be up and running for Subscribers to issue
subscription requests (greatly simplifies Actor initialization by removing restrictions on
actor start-up order)

3. Synchronization Decoupling: Publishers and Subscribers may do their stuff without losing
messages (message buffering)

4. Semantic Message Decoupling : Not yet - it’s an Event Aggregator right now – with
Semantic Message Decoupling coming soon to a theater near you …

NIWeek 2018 OO: SOLID Actor Programming 49

 ArT_Message_Broker Summary
Pros:
1. Lightweight, Simple & Scalable
2. Statically decouples Publishers & Subscribers from each other
3. Decouples Topics from Publishers – removing constraints on Publisher/Subscriber
Initialization Order
4. Decouples Topics from Subscriber Message Transport choices (Queue, User Event, etc.)
5. Supports 1:1, 1:M and N:M Topic Modes
6. Easy to add a new Message Type
7. Easy to add a new Message Transport
8. Provides both, Asynchronous & Synchronous Publishing Options

Cons:
Non so far …

NIWeek 2018 OO: SOLID Actor Programming 50

 Actor Programming References
General
[10] Actor Model of Computation, Carl Hewitt, [Link], 2010
[11] Parallel Programming Models, Wikipedia
[11a] Reactive Programming vs. Reactive Systems, Jonas Boner, Viktor Klang, 2016

Actors in LabVIEW
[12] Fundamentals of Actor-Oriented Programming, Dave Snyder, CLA Summit 2014, Austin
[13] Actor Programming without an Actor Framework, Dmitry Sagatelyan, CLA Summit 2015, Austin
[14] ArT_Actors: A Step Beyond Actor Framework 3.0 ?, Dmitry Sagatelyan, White Paper & Discussion, AF Forum, 2012
[15] Decoupling Actors with Event-Driven Architectures, Jon McBee, Blog, 2016

NI Actor Framework
[16] Using the Actor Framework 3.0 in LabVIEW, Allen Smith, Stephen Mercer, AF Forum, 2011
[17] Efficient Actor Framework Development: Structure and Messaging, Allen Smith, CLA Summit 2018, Madrid
[18] TS1767: What a Software Architect Needs to Know When Using Actor Framework, Dave Snyder, David Staab, NIWeek 2013
[19] Zero-Coupled Actor Project, DMurrayIRL, AF Forum, 2015
[20] Actor Framework from Basics to PPL PlugIn, Stefan Lemmens, AF Forum, 2018

OO: SOLID Actor

NIWeek 2018 51
Programming
 Simplicity …

“A designer knows he has achieved perfection

not when there is nothing more to add, but
when there is nothing left to take away”
Antoine de Saint-Exupery

NIWeek 2018 OO: SOLID Actor Programming 52

 Summary
1. Consider using SOLID Principles to :
• Adapt Application Code to Requirements changes at
incremental cost
• Substantially increase Code Reuse Levels
• Enable design of Plug-In Architectures
2. Actor Designs based on Command Pattern are SOLID-unfriendly
3. Do proper due diligence before committing to a particular Actor
Design/Framework
4. Message Brokers provide SOLID support for Hybrid Messaging
Topologies

OO: SOLID Actor

NIWeek 2018 53
Programming
Before you go,
take the survey.
 Questions ?

NIWeek 2018 OO: SOLID Actor Programming 55

 Appendix

OO: SOLID Actor

NIWeek 2018 56
Programming
 What I like about NI Actor Framework
1. AF is an Elegant Design
2. AF is a Scalable Design
3. AF now comes as part of LabVIEW
4. AF has a vibrant User Community
5. NI provides AF Customer Support
6. But, most importantly, AF started a meaningful discussion on Actor
Programming in the LabVIEW Community

NIWeek 2018 OO: SOLID Actor Programming 57

 Why I do not use NI Actor Framework
1. AF is SOLID-unfriendly (requires substantial effort to keep applications SOLID-compliant)
2. AF Actors are tightly coupled to message transport (enqueuer)
3. AF Actors unconditionally execute all received messages
4. AF bundles together steps for creating/configuring and running an Actor – enqueuer
becomes available only after Actor had been started (bad for Dependency Injection)
5. Using Publish/Subscribe in AF is too complicated
6. Adhering to messaging along Actor Tree may be an SRP violation (Caller has to implement
message forwarding)
7. Using AF rapidly leads to too many classes – making LabVIEW IDE unresponsive on even the
mid-size projects
8. AF has a steep learning curve
9. Mainstream LabVIEW Developers have issues understanding and supporting AF-based
projects

NIWeek 2018 OO: SOLID Actor Programming 58