Context switching

From cdd
Jump to: navigation, search

I came up with the idea of context switching in 2011 and blogged about it here. The pattern has been improved since then in a way that state and behaviour now are completely separated. The first release of CDD (1.0) was built on top of mutable state which turned out to be a mistake. The new version, 2.0, can work with both immutable and mutable state. If you choose to work with immutable state, the default behaviour is to expose the state. With the state exposed, each object in a context does not need to know about other context which makes the code more decoupled. The upside of the extra coupling we add when letting a context know about another contexts makes the code more fluent and can increase the readability.


The ability to have a set of different context representations is an effective way to reduce the amount of code needed to integrate different parts of the system. The switching is performed without affecting the state format or breaking the encapsulation. It encourages putting behaviour inside objects close to its data so they can perform tasks themselves, which is good and follows the Tell Don't Ask principle. In addition to a facilitated integration CDD also let us create objects that focus on one task at a time, following the Single responsibility principle.


In an earlier example we switched context to be able to perform the save operation:

person.asPersistable().save();

...which can be illustrated by this diagram:


CDD-context-switch.png


The switching was performed by the method asPersistable():

package com.myproject.behaviour;
 
import com.myproject.state.PersonState;
 
public class Person extends PersonBehaviour {
    public Person(PersonState state) {
        super(state);
    }
 
    public PersistablePerson asPersistable() {
        return new PersistablePerson(state);
    }
}


Context switching allows our objects to switch and perform well defined tasks in different parts of the system almost friction free. We don't need to convert between different state representations when crossing context borders because the state format never change. Conversion between state representations is a common source of error that is almost eliminated in CDD.


Let's take a slightly lager example to illustrate the concept context switching.


CDD-context-switching.png


Imagine that we start by retrieving an instance from a repository (Context 1), present it in the GUI (Context 2), perform some editing in the GUI (Context 3) followed by some domain operations (Context 4) and finishing by writing the state to a file (Context 5).

Dependencies

When we add the method asPersistable to Person:

person.asPersistable()

...we introduce a connection to PersistablePerson. This will facilitate integration between the two contexts. The good thing is that Person and PersistablePerson can be changed independently without affecting each other (a bad thing can be that we introduce a direct dependency).


An alternative is to use immutable state and switch context outside the involved objects:

new TextPerson(person.state);


< Back          Next >