Applied Abstraction (part 3)

Quick Review

I have raised quite a few points from just a small section of code. It is clear a failure to apply abstraction well has subsequently allowed the misplacement of system responsibilities within the AssignmentForm class. The business policy details belong not on a user interface class but on a domain class or something similar. The domain model has the role of representing the business domain, its relationships and its policies. Centralising business logic in the domain model keeps all of the important details in one place, and it should be through abstraction that these details are exposed to the rest of the software in a way that keeps the how hidden behind the what.

Building object oriented software is all about constructing the system from software artefacts that are fashioned to work with the forces of change. As has been mentioned, a good design axiom is to build against abstract concepts rather than concrete representations. This is achieved through the use of abstract types (abstract class or interface), which are used to form the semantic substructure on which the system implementation will be written. Whenever a piece of code is built against an abstract type, it is shielded from whatever may change behind that software construct. New requirements are added to the system by “plugging in” to the foundations of the of the design, the substructure. In our example the AssignmentForm is a client, and Vehicle and Customer are the abstract constructs that the AssignmentForm should depend upon. Actual requirements are built and evolved by plugging them into these existing design elements.

Figure 2

Figure 2

 

In figure 2 Vehicle and Customer form the semantic bond, each an abstract type of core concepts in the problem domain. Underneath these abstract types there is an ever changing world of evolving requirements being constructed and modified to plug into the abstract foundation. Here the new type CorporateCustomer is introduced as a specialization of the abstract Customer type, and new vehicles are added to the system in exactly the same way. With the client’s dependent only on abstract structures, they are oblivious to these types of modifications made to the system over time. Without this type of complexity management, it would be much riskier to add new functionality to the software.

 

Substructure Metaphor

I have found the notion of a substructure a useful metaphor to help demonstrate the importance of the abstract types within object oriented software. In construction the substructure makes up the foundations on which the main structure sits. The purpose of these foundations is to withstand the forces of nature, which if ignored can uproot and move the above superstructure with ease. In software construction these forces are the natural evolving requirements. Abstract types are like the footings and foundations that take the load of the rest of the system, and provide a structure on which the requirements can be implemented.

This metaphor should only be used to appreciate the relevance of the internal underpinnings of the design. It is wrong to apply the construction metaphor completely, because here the foundations are built first before any subsequent building can take place. From a software perspective this would require a full design up-front exercise to appreciate what needs to be in the foundations. However agile development principles show us that the construction metaphor falls down when taken literally, since we can build our software safely in an evolutionary manner that allows the substructure to slowly take place as the system grows.

What this all boils down to is the need to code against specifications, not implementations. The designer of the tracking system overlooked the essence of the Vehicle when he modelled it in the software. It seems the essence of the Vehicle is that it has a property named Assignee and a property named AssigneeName, both poorly naming the concepts they represent. The Vehicle has no important role in the system but to collate some data items. A change to the vehicle hiring or returning policy has a greater chance of affecting the AssignmentForm than it does the Vehicle class; this is clearly wrong.

 

The obscure names chosen for the Vehicle properties fail to capture the true domain, and I am certain I could not talk to the domain experts about Assignee’s and AssigneeName’s without there being confusion. The fix is to focus on mapping the outside world correctly to the inside world of the software, and we do this with the help of the ubiquitous language. Using a ubiquitous language it will be easier to reason about the domain while working with the code, because the domain and the code will the same.

Ubiquitous Language

In Domain Driven Design, Eric Evans presents a technique that bridges the knowledge transfer gap between the developers and the domain experts, the ubiquitous language. This language is built on collaboration with all team members to model the domain the software is being constructed for. The team continually exercises the ubiquitous language, both in conversation as well as in the code. This not only improves the communication and understanding between the domain experts and software team, but its manifestation as the core domain model in the system further reinforces the focus on domain concepts, not technical concepts.

Our next objective then (in part 4) is to introduce just a little bit of abstraction to see how well it affects the design. In the next section I will take the code through a number of refactorings, and my objective will be to improve abstraction, separation of concerns, and better represent the problem domain within the code. By better capturing the essence of the problem I will show how the domain can be modelled in the code to improve the current readability issues.

Advertisements
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: