User:Ljr1981/Action Queue

Action Queue

An Action Queue (or Action Sequence) is an object oriented software design construct where object routines are represented as objects themselves and then collected or queued for delayed execution. Action Queues can be thought of as a `Do [each action item] when [event] happens.'

Comparison to Message Queues

Action Queue's are unlike message queue's, which hold messages between Publishers and Subscribers. Action Queues hold action (routine) objects for delayed execution triggered on some event rather than messages to be sent (e.g. message queue's).

A comparison of Message Queues to Action Queues is somewhat misplaced. Message Queues are designed to operate in a Stateless type of State (computer science) topology, whereas Action Queues are designed specifically to operate in a full state environment such as an executable program on a local computer system. Nevertheless, it is important to understand the distinction between the two technologies. Most specifically, the two technologies are not competing for the same space, but are actually different technologies operating in different environments for different purposes.

First, message Queues based on stateless topology leave open the possibility of having no handler (listener) to handle the message. Second, if a message handler is found, there remains a possibility of the handler either not understanding the message or not having a response action. Last, if a message is understood and responded to, there is some potential of the response not matching the need of the message creator.

In systems with state, Action Queues and their contained action objects close the loops left open in Message Queues and messages. The action object represents a known routine on an object in memory, so there is no potential for an orphaned listener. Second, the routine call is specific, so there is no potential for an improper call unless the programmer calls the wrong routine. Last, the programmer also knows the routine code and results of it, so there is little potential for getting an incorrect response from the action call.

The last point is the one caveat: Polymorphism and the capacity to redefine an actions routine code does present a small challenge to ensure an appropriate response. However, this challenge is the same for all object oriented code and is not a challenge created by Actions Queues or their contained action objects.

Action Queues & Agents

Action Queues are collections of action objects to execute as needed. In the Eiffel programming system and language these routine objects are called Agents. Such Agents are not to be confused with Software agent's, which are another paradigm altogether. Agents as related to Action Queues are based on Lambda Calculus or Closure (computer science), where the function is regarded as some form of discrete run-time object.

Action Queues Coupling

The remainder of this article will use terms like 'tight coupling' or 'loose coupling' in the context of Action Queues. These notions of Coupling (computer programming) as applied to software elements are not the same as when applied to Action Queues and their actions (Agents).

Action Queue coupling has to do with what Action Queues are used to place Publisher actions. Tight or Direct coupling is when a Publisher's action is directly placed on a Subscribers Action Queue. Loose or Indirect coupling is when a Published action is placed on an Action Queue other than one belonging directly to a Subscriber. For instance:

container.change_actions

Vs.

text_box.change_actions

Therefore, additional layers of Action Queues' or actions' each serve as a decoupling of the Publisher from the Subscriber in view of placement of the actions.

A finer point to note is how Action Queues (and the actions they contain) already have the notion of loose coupling within the structures that define them. Queues of actions, which are available to execute on-demand (with open or closed arguments), already decouple the entity calling for execution of the actions in the Action Queue from the entities having the actions.

In the 'tightly coupled' design, the execution requesting entities know nothing about entities whose functions are being executed (the actions). Moreover, the execution requesting entities are possibly not the same entities who loaded (placed) the actions into the Action Queue to begin with. Therefore, there is a large dismantlement of direct references between the entities involved: Subscribers, Publishers, Linkers, Executors and even the Subscriptions (actions or Agents) themselves. The relational knowledge coded between each of these entities is very decoupled and thin by the very design of how Action Queues and Agents work.

Direct or Tightly Coupled

In the simplest form, a Publisher and Subscriber are linked when an Publisher's Agent is placed into a Subscriber's Action Queue. A simple example of this is a Text box subscribing to Save button. An Agent for the `enable' function of the Save button is placed into the `change action' Action Queue of the Text box.

When data in the Text box is changed, the actions queued in `change action' are executed, which performs a `call' of the `enable' function. The result is the Save button becoming enabled in response to user changes in the Text box.

text_box.change_actions.extend (agent save_button.enable)

See also: Coupling (computer programming)

Indirect or Loosely Coupled (Decoupled)

In the tightly coupled example above, the Text box and Save button are highly dependent on each other by means of a direct reference (e.g. the `change action' queue contains an Agent, which is a direct reference to the Save button `enable').

Decoupling the dependency between the Publisher and Subscriber allows a co-variant relationship, which is a far more flexible form of the same code -- that is -- the Text box or the Save button can be exchanged independent of each other without breaking the design intent of the code (e.g. the design intent is for one control to affect enabling of another control based upon changes to its data.).

One form of Action Queue decoupling creates either a queue or a function call on an object other than the Publisher or Subscriber. Continuing with the Text box and Save button example, the decoupling object might be a Window or other container. Conceptually, a third object is given knowledge of both the Text box and the Save button, effectively decoupling them from direct reference between each other.

Creation of a decoupling Action Queue or function on the third object is not mutually exclusive. One method or both methods can be used in the decoupling design. An example using a some form of container:

First, link the Text box change actions to a container change actions queue by means of an agent in the Text box action queue which executes all of the agents in the containers queue.

text_box.change_actions.extend (agent container.change_actions.execute)

Next, place an Agent in the container change action queue to call a container `enable save' routine.

container.change_actions.extend (agent container.enable_save)

The `enable save' of the container then executes the actions in a container `save enable' queue, each causing some control associated with saving to be enabled.

container.enable_save_actions.extend (agent save_button.enable)

This dual decoupling mechanism has now effectively broken the direct or tightly coupled nature of how the Text box relates to the Save button. Either control can now be swapped or made variant.

Action Queue Linking

Tightly Coupled Linking

Placement of actions (e.g. Agents) into Action Queues happens by means of a subscription or subscribing process. Some code entity must finally be responsible for knowing what Publisher actions to place on what Subscriber Action Queues. A natural first approach is to give the action queue container this responsibility or knowledge. This is a tightly coupled approach -- that is -- coupling the action queue container to knowledge or responsibility to populate the queues.

Decoupled Linking

Providing a separate linking entity other than the action queue container yields a design where decision logic can be swapped out. This means the logic controlling what Publishers and linked to what Subscribers can vary together with varying Publishers and Subscribers.

Upward/Downward Linking

See also: Decoupling, Publish/subscribe

External links

• Eiffel.com
• Eiffel Programming Language