Options in Loose Coupling

We loosely couple architectural layers because we assume each architectural layer is likely to change for different reasons. Loose coupling of each architectural layer can improve the resilience to change of each layer. It can also reduce dependencies of shared objects (or API projects, see Creating Functional Areas) as less dependent objects exist. However, loose coupling comes at a price. The looser an object is coupled to another object, the higher the cost of readability. Sometimes, objects are not likely to change and very loose coupling only introduces overhead.

There are options in loose coupling that developers can consider depending on the likelihood of change. The following explains options in coupling on one example relationship between an object of the presentation layer (ContactListPM) and a domain layer (Contacts). The ContactListPM references an items property of type mx.collections.IList on the Contacts domain.

Concrete References to Domain

A concrete reference of one object to another represents no coupling. It is the easiest option to read at the cost of a lower resilience to change and a higher number of dependent objects when shared.

Furthermore, unit tests cannot substitute the concrete reference with a test double in order to focus the purpose of the test to the object under test, simulate and test interactions and test difficult-to-test behavior in case the concrete object is difficult to test. See the Agile Testing paper for more information.

Domain Interface

The domain could implement an interface of its API. Preferable this interface will abstract the domain from the presentation with i.e. only describing the interaction with the PM. Domain interfaces allow a unit test to substitute the domain in case that is preferable.

Abstracted Interface

A domain interface could be further abstracted to not describe that the PM interacts with a domain. For example a ContactListPM might need to read an IList collection of a domain object. Instead of creating a domain interface, create an abstracted interface that only describes the property of an IList i.e.

public interface IItems
{
    function items():IList;
}

Metadata Injection

A metadata tag can be created that injects the items property of the Contacts domain into the PM.
The Cairngorm Observer library offers one example build upon Parsley

[Wire(id="contacts",property="items")]

The "contacts" value is how the Contacts domain is declared in the context.

Presenter

Presenters are part of the presentation layer and take a higher level role than PMs. They can coordinate PMs but also loosen the coupling of a PM to a domain. A ContactListPresenter could be created that subscribes to a domain event whenever its items collection is changed. On a change, the presenter would directly update the PM as it contains a reference. The coupling is not loosened overall, but if the PM is regarded to be reused in a different context, this form of coupling could be a consideration.

Messaging

A messaging mechanism allows two objects to communicate with each other by only knowing about the shared messaging mechanism. Various architectural Flex frameworks support a messaging mechanism with different requirements on each participant to know about the messaging mechanism. Cairngorm 2 requires both participants to know about a concrete framework component, while Swiz can loosen the framework coupling of the message handler part with metadata while comletley removing it on the message dispatching part. Parsley messaging either only requires both participants to know about metadata or specify the coupling externally via a context.

Messaging can achieve a low coupling between objects, often with introducing further dependencies on frameworks, or the introduction of event objects. Furthermore, the scope of messaging is often global, which can lead to further complications where and in what order messages are handled.