OO concepts: Observer pattern

Introduction

In this post I sum up the Observer pattern, an interesting OO pattern very useful in many situations.

Description

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject’s state.

This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.

Basic Pattern

Complex Pattern

Consequences

The advantages are:

§          You can vary and independently reuse classes for the Subject and Observer objects.

§          The abstract classes (or interfaces) are coupled together. Therefore, the coupling is looser than if the concrete classes were coupled.

§          You can easily add Observer objects without a single change to the Subject object.

The disadvantages are:

§          An observer system can become flooded with updates if the granularity of the update is too fine or its frequency too high. This is a critical problem in distributed systems.

§          The observer system often calls the subject when it receives a notification. This can create a bottleneck, preventing the timely update of the other observer systems.

References

Gamma, Helm, Johnson, and Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - Anticorruption layer

Introduction

In this post I sum up the most important concepts about Domain Driven Design.

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

Scenario

On a large project, one subsystem will often have to interface with several other, independently developed subsystems. These will reflect the problem domain differently. When systems based on different models are combined, the need for the system to adapt to the semantics of the other system can lead to a corruption of the new system’s own model.

We should create an isolating layer, ANTOCORRUPTION LAYER, to provide clients with functionality in terms of their own domain model. The layer talks to other system through its existing interface, requiring little or no modification to other system. Internally, the layer translates in both directions as necessary between the two models.

Note: ANTOCORRUPTION LAYER is not a mechanism for sending messages to another system, is a means of linking two BOUNDED CONTEXTS.

Designing the interface

The public interface of the ANTICORRUPTION LAYER usually appears as a set of SERVICES. Building a whole new layer responsible for the translation between the semantics of the two systems gives us an opportunity to reabstract the other system’s behavior and offer its services and information to our system consistently with our model.

Implementation

The ANTICORRUPTION LAYER is a combination of FAÇADES, ADAPTERS and translator, along with the communication and transport mechanisms needed to talk between systems.

A FAÇADE is an interface for a subsystem that simplifies access for the client and makes the subsystem easier to use. It should be written strictly in accordance with the other system’s model. The FAÇADE belongs in the BOUNDED CONTEXT of the other system. It just presents a friendlier face specialized for your needs.

An ADAPTER is a wrapper that allows a client to use a different protocol than that understood by the implementer of the behavior. When a client sends a message to an ADAPTER, it is converted to a semantically equivalent message and sent on to the “adaptee”. The response is converted and passed back.

For each SERVICE we define, we need an ADAPTER that supports the SERVICE’s interface and knows how to make equivalent requests of the other system or its FAÇADE.

The remaining element is the translator. The ADAPTER’s job is to know how to make a request. The actual conversion of conceptual objects or data is a distinct, complex task that can be placed in its own object, making them both much easier to understand. A translator can be a lightweight object that is instantiated when needed. It needs no state and does not need to be distributed, because it belongs with the ADAPTER it serves.

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.