7.3 Class families, class teams, and subsystems

Erich Gamma coined the terms class teams, class families, and (specifically in this context) subsystems in his Ph.D. thesis (1991).

Class families evolve around the principal abstractions of a framework. The members of a class family adhere to the interface defined by the corresponding abstract class or interface. For example, the Component family in the Java Swing framework contains around 50 members they are subclasses of the abstract class Component. The Container family is a subfamily of the Component family and has about 10 members.

If the family crystallization point that is, the abstract class or interface is already identified in the set of aCiRC cards, the families will evolve in a top-down manner. The abstraction is there first; the specific family members follow later. Quite often, families evolve in a bottom-up process when framework developers recognize similarities between several concrete classes. Thus, the abstract class or interface is defined based on the experience incorporated in the specific classes. Thus an aCiRC card should be added if families arise in a bottom-up manner.

Consider an important design hint for class families the root of class families should be lightweight. For example, excessive data representations should be avoided in abstract classes that correspond to key abstractions in the framework domain.

Class teams consist of cooperating families. Thus the relationship between aCiRC cards might provide useful hints as to which class families could form teams. Class teams rely on abstract coupling and are reused as a whole. For example, the two class families in the Java Swing framework form a team. In the ET++ framework (Weinand and Gamma, 1994) the class families Text, TextView, and TextFormatter form a team. The specific text representations (abstract class Text) can be displayed by various views (subclasses of the abstract class TextView). The Text and TextView combination cooperate with any text-formatting algorithm through the abstract coupling of the Text abstraction with the TextFormatter abstraction.

Subsystems explicitly encapsulate a class team by offering an adequate interface. Thus, a subsystem corresponds to the definition of a software component in Chapter 1. The Fa ade pattern (Gamma et al., 1995) also discusses this modularization aspect (see Figure 7.3). In general, the definition of an additional abstraction makes reuse easier for clients and reduces the coupling between specific classes of teams.

Figure 7.3. Packaging a class team in a component (= subsystem, = Fa ade)

The concepts of class families, class teams, and subsystems also help in redesigning framework hierarchies. Gamma (1991) distinguishes between vertical and horizontal reorganizations. The following reorganization steps should be regarded as triggers of framework evolutions:

Vertical reorganizations of framework class hierarchies

The following operations represent vertical reorganizations.
1. Moving common properties/protocols/parameters of classes up the class hierarchy. This usually happens within a class family. Check whether commonalities exist.
2. Splitting up an overly complex class into a class family. This creates a class family. Check whether a class is too complex in terms of number of methods, conditional statements in the methods, and/or data structures.
3. Avoiding the overriding of too many specific methods by adding abstract classes. This also creates a class family. Check whether specific methods are often overridden in adaptations.
Horizontal reorganizations of framework class hierarchies

The following operations represent horizontal reorganizations.
1. Splitting up a class with too many responsibilities into a class team. The class team might be packaged into a component. Check whether a class has too many responsibilities (in terms of CRC responsibilities). Consider ten or more responsibilities as a rule of thumb limit for discovering classes with too many responsibilities.
2. Moving features into strategy classes (according to the Strategy/Bridge patterns, which rely on the Separation construction principle). Check whether compositional adaptation of certain features is required. (See also next section.)
Framelets

There is a close relationship between class families and class teams/subsystems on the one side and what we call framelets on the other. Essentially, they represent views at different levels of abstractions of a framework. The class families and teams look at the framework as a concrete architecture, whereas the framelets describe it as an abstract design. Framelets are discussed in Section 7.6.