An object family is a compatible group of related object types. A Ford engine, for example, uses one family of parts, while a GM engine uses another; family members must not be mixed. section 9.2
Keeping sports objects together
A sports application treats players and venues as families. Varsity players belong with varsity venues, while intramural players belong with intramural venues. Without this separation, factories can accidentally combine incompatible objects. VarsityFactory creates varsity players and venues; IntramuralFactory creates intramural players and venues. section 9.2.1 section 9.2.2
The Abstract Factory Design Pattern provides an interface for creating related or dependent objects without specifying their concrete classes. A Sport receives a factory, which creates its player and venue objects, keeping family selection out of the department subclasses. section 9.2.2
Figure 9.4 This version of the application is modeled from the Abstract Factory Design Pattern. Interface ProvisionsFactory is the abstract factory whose implementor classes are used by the Sport subclasses. Implementor class VarsityFactory creates the varsity family of player and venue objects, and therefore, VarsityDept uses VarsityFactory. Implementor class IntramuralFactory creates the intramural family of player and venue objects, and therefore, IntramuralDept uses IntramuralFactory. The grayed-out portions of the diagram have not changed logically from figure 9.2.
Trace how ProvisionsFactory connects VarsityFactory and IntramuralFactory to the corresponding departments and object families. section 9.2.2
