David Ross's Blog Random thoughts of a coder

Inheritance versus the strategy pattern

Broadly the patterns described in the “Gang of Four” patterns book (Design Patterns: Elements of Reusable Object-Oriented Software) can be broken into two groups. The first group provide techniques to manage an object’s lifecycle and the second group is about splitting an object’s responsibilities into a group of interconnected smaller objects which should simplify the design. Many of the lifecycle patterns (singletons, factories etc.) are found in modern Inversion of Control containers and no longer need to be implemented by hand. Meanwhile the second group are utilised in the design of a rich domain layer.

Consider a bank that has a range of savings account products with each having a slightly different method for charging fees. Some fees might be based on the amount of money in account, others based on the number of transactions and finally some premium based products might have a flat monthly fee. When developers first learn an object orientated programming language this type of problem is solved in one of two ways:

1. Implemented using procedural techniques
   • The Fee Calculation logic is placed into the Bank Account class and is implemented using cascading if-else or switch statements
   • Adding a new Fee Calculation involves modifying the Bank Account class
2. Implemented using inheritance
   • The developer realises that are five or six distinct bank account types
   • A base class is created where the common aspects of all of the account are stored
   • An abstract CalculateFees method is placed on the base class which the children override
   • Adding a new Fee Calculation involves creating a new leaf class meanwhile the base class is not modified

The inheritance based solution is far superior to the procedural alternative since new bank account products can be added to the solution within necessitating any changes to the base class.

Unfortunately the inheritance design has some issues:

• Hard to model bank accounts that have a blended fee structure without multiple inheritance
  • Retail Plus account combines aspects of the Premium account with the Basic Saver Account
  • Debit account is the same as a Retail saver but without overdraft facility
• Inheritance can’t be switched on and off its an integral part of the objects identity
  • Act as a Premium account until number of transactions is over 20 than act as a normal account

An alternative to inheritance is to utilise the strategy pattern and to move the Fee Calculation engine out of the Bank Account object and to place into a new group of objects that share an interface. The Bank Account then delegates to a collection of Fee Calculation objects instead.

This approach:

• Enables an account to have zero, one or many fees structures
  • Allows the creation of a rules engine that allows Fees Structure to be prioritised or combined easily
  • Scales to allow for any type of behaviour that is optional or time dependent to moved out of the object and into a strategy
• Tightens up the definition of a Bank Account
  • A collection of transactions that are associated with a customer
  • Business rules can be applied to the account that generate transactions which in turn allows interest to be paid and fees to be charged

After learning the strategy pattern developers will quickly find that they begin pushing inheritance out of their entity classes and into behavioural components instead. Thus the inheritance hierarchy (this includes the implementation of an interface) is used for allowing optional runtime polymorphic behaviour as opposed to modelling an object’s type.

UML with Colour

One of the difficulties when using UML is that it doesn’t validate the quality of the design or provide guidelines to aid in the modelling process. UML with Colour (described in Java Modeling in Color with UML) meanwhile overlays UML with a set of simple design rules for building out the logical domain model. The logical model that is created is similar to 3^rd or 4^th normal form in database modelling as the resulting object model is highly decoupled.

UML with Colour is based on the premise that domain objects are split into three groups.

Party, Place or Thing objects have Role objects which modify or create Moment-Interval or Transaction objects

Example:

• <People, Person or Thing> - <Role> - <Moment-Interval or Transaction>
• Manager – Approves – Timesheet
• Customer – Buys – Products
• Trader – Cancels - Trade

Party, Place or Thing

The Party, Place or Thing archetype is used to represent all of the system’s actors. UML with Colour ruthlessly removes many of the places where inheritance is used in modelling actors by stating that a Party, Place of Thing cannot manipulate or create Transactions directly and instead this work should be delegated to a Role. When modelling the users of a system instead of having a deep hierarchy that includes managers, team leads, customer service, administrators etc. there might only be a staff object and all of the different capabilities and responsibilities of a manager or administrator is modelled as Roles.

Typically Party, Place or Thing objects:

• Will have a unique identity across the application
• Can be an aggregate root

Role

Where UML with Colour differs from classical domain modelling is that it makes the strategy pattern a core part of the design process. Consider a requirement where a manager needs to approve timesheets in a HR application. Instead of putting an Approve timesheet method on a Manager object the design starts with a Person object that interacts with a Time Sheet Approver Role. Thus a Role is an object that creates or manipulates a Transaction on behalf of a Party, Place or Thing. As discussed removing this logic from the Party, Place or Thing objects has a number of benefits with the most important being that it allows for capabilities to become optional and combinable.

Typically Role objects:

• Will implement an interface
• Will often be a factory

Moment-Interval or Transaction

The Moment-Interval object represents an event or transaction.

Typically Moment-Interval objects:

• Include a timestamp, sequence number or time period as part of their identity
• Often have a collection of children such as a Purchase Order has Purchase Order Line Items

Description

There is a fourth archetype in UML with Colour called Description which is an object that stores metadata about another object. For example a car might have attributes including its registration number, amount of fuel in the tank and miles on the odometer. In addition there are attributes that are shared by all cars of the same model such as its manufacturing year, make, model and colour. These should be placed into a Description object to ensure that the data is shareable, not duplicated and most important recognises that the data is intrinsically immutable.

Typically Description objects:

• Are value objects
• Are similar to dimension tables in a data warehouse
• Are attached to Party, Place or Things and Moment-Intervals but not Roles

Colours?

The Colour part of UML with Colour is simply that within the UML diagram each of the classes in the diagram is shaded with a different colour representing each of the archetypes. The colourisation ensures that the basic design rule whereby a Person, Place or Thing can’t connect directly to a Moment-Interval is enforced.

The four colours have been purposely chosen so that they are available within a pack of coloured post-it notes. The design process will often consist of sticking post-it notes to a whiteboard and drawing arrows between them.

• Role is yellow
• Moment-Interval is pink
• Description is blue
• Party, Place or Thing is Green

Logical to Implemented Domain Model

Once the UML with Colour diagram is completed the developer is then able to decide how the model should be implemented.

The three choices are:

• Implement classes identical to those on the logical model
• Denormalise the design and utilise inheritance so that each Role of a similar type becomes an inheriting class off the Party, Place and Thing class
• Implement the capability of the Role directly in the Party, Place or Thing class

It might sounds strange after going through a process where we extract behaviour out of entities and into separate classes the design process then advocates that the developer has the opportunity to collapse all the responsibilities back into a single entity. However this follows the tradition of all refactoring processes in that they are by-directional. For example code can be pushed out of a function using the Extract Method refactoring and in turn if a function is no longer useful as an abstraction its contents can be pasted into its callers.

Examples:

• If there are many Roles that are optional leave the design as is
• If available Roles can change for the same Party, Place or Thing instance leave the design as is
  • Trades can be approved by all team members until midday after which time only a manager can approve the trades
• If a Party, Place or Thing class only has a single Role or a group of independent Roles that act on different Moment-Intervals that behaviour is not optional the Role should be merged back into the Party, Place or Thing
• If there are a set of Roles that provide similar functionality and are not optional consider removing the strategy and inherit off the Party, Place or Thing class.

Further as we have seen it is trivial to refactor from a de-normalised model into a normalised model that utilises separate Role classes i.e. it is possible to refactor from a design where everything resides in a single class, to having one with a base class with inheritors to one where the design relies of behavioural patterns like the strategy.

Limitations

• UML with Colour is focussed on domain objects and is a poor choice for modelling the interaction between layers or systems in an enterprise application.
• In initial discussions with the business it is preferable not to discuss concept of Roles
  • Business wants to discuss problem domain using titles such as manager and team member
  • In comparison calling managers, Staff with Approver or Proposer Roles can be initially confusing
• Not a common technique
• UML itself isn’t as popular as it once was
• UML with Colour is not widely known as it was introduced in a Java design book as opposed to be championed for all developers