Subclass Per Team

A small team of students with a common interest in photography

...dividing up work among different teams is less straightforward than it looks. It is simply impossible to partition the work perfectly; teams will always have some overlap in each others' work. 

✥ ✥ ✥

Subsystem teams have differing interests and design points.

When two teams work in the same class definition, they will be optimizing for different maintenance and performance characteristics. Besides being in conflict as to which way to optimize, they will also lose track of which parts of the module are used by whom (see OwnerPerDeliverable, above). 

Therefore: 

Where two subsystems collide in one class, factor their code into separate classes that separate development teams' interests. Each class can be owned by its respective team (OwnerPerDeliverable) and the classes can be combined with inheritance and design patterns to integrate functionality.

Object-oriented programming gives a particularly nice way to split a class along lines of separate interests--the class hierarchy. It is appropriate that different interests reside in different places (VariationBehindInterface, since a change to one team's module should not damage the other teams' modules). Where inheritance is not available (in non-OO development), it sometimes can be mimicked using call delegation. 

Various design patterns can be used to support flexible and convenient combination of such classes; in particular, see TemplateMethod in [BibRef-GOF1995]. 

An example of teams' interests mixing is at the root domain class. Here is where the domain team puts its generic behavior. Here also is where the persistence team puts generic transaction behavior. Ideally, the two are independent. Further, by job description and expertise, the domain class person is different from the persistence mechanism person. The teams will be making changes to their interfaces and implementations concurrently. They have different interests, and different ideas as to what is best. Introducing layers of subclassing allows the groups to hone their designs with minimal impact on each other. HierarchyOfFactories [BibRef-Berczuk1996] illustrates a specialization of this pattern for the case where the application is a creational system where different subsystems control the format of different types of products. ParserBuilder is an example of providing a single base class interface to variant implementations in derived classes.

✥ ✥ ✥

Beware of over-applying this pattern: excessive levels of inheritance make the system harder to understand and potentially slower. 

The principle would make a wonderful, universal argument mediation technique, except that addition of a new level of subclassing for every disagreement would produce a system difficult to understand. 

This pattern was originally written by Alistair Cockburn in SocialIssuesAndSoftwareArchitecture, published in [BibRef-Cockburn1998].