Design Patterns  «Prev  Next»
Lesson 7 Pattern scope
ObjectiveDistinguish between Class and Object Patterns

Distinguish between Class and Object Patterns

In the annals of software design, the Gang of Four (GoF) patterns stand as a beacon, illuminating the path for developers with their well-defined design patterns. These patterns, 23 in total, are categorized based on their purpose and the design problems they address. Among these categories, the terms "Class Patterns" and "Object Patterns" emerge, each with its distinct narrative in the realm of object-oriented design.
  1. Class Patterns: The tale of Class Patterns revolves around inheritance. These patterns focus on the establishment of relationships at compile-time through inheritance. By defining interfaces and implementations, Class Patterns provide a mechanism to craft flexible and reusable components. The essence of these patterns is to use inheritance to compose interfaces or to define new ones. In the GoF's narrative, there are only a few patterns that fall under this category:
    • Template Method: This pattern defines the structure of an algorithm, allowing the steps of the algorithm to be implemented by child classes without altering the algorithm's sequence. It's like a recipe where certain steps can be customized by those who inherit it, but the overall process remains unchanged.
    • Factory Method: Within this pattern, a method for creating objects in a super class is defined, but the exact type and nature of the object that will be instantiated is determined by the subclasses. It's akin to a framework that dictates the creation process, but the specifics are left to the inheriting entities.
  2. Object Patterns: The narrative of Object Patterns is one of composition. These patterns are more about objects' relationships, which are typically established at runtime through object composition. The primary focus here is to define ways to create and interrelate objects, ensuring flexibility in both the system's structure and its behavior. The majority of the GoF patterns fall under this category, including:
    • Strategy: Envision a toolbox. Within it, each tool has a specific function. The Strategy pattern is similar; it defines a family of algorithms, encapsulates each one, and makes them interchangeable. Objects can switch the algorithm they use at runtime, just as one might switch tools based on the task at hand.
    • Observer: Picture a newspaper subscription. Whenever there's a new edition, all subscribers receive a copy. The Observer pattern operates on a similar principle. It defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
    • Decorator: Imagine a Christmas tree, adorned with various ornaments. Each ornament adds to the tree's aesthetics without altering its inherent structure. The Decorator pattern allows for the addition of responsibilities to objects dynamically, enhancing their functionality without changing their core.
    • Singleton: Think of a president or monarch. There can be many officials and representatives, but only one supreme leader at a time. The Singleton pattern ensures that a class has just one instance and provides a global point of access to it.
    • Composite: Visualize a hierarchy, like an organizational chart. There are individuals, and there are groups. Each group can contain individuals or other groups. The Composite pattern allows clients to treat individual objects and compositions of objects uniformly.
The narratives of Class and Object Patterns, as portrayed by the Gang of Four, are tales of design that address the challenges of crafting maintainable, scalable, and flexible software architectures. While Class Patterns weave their story around inheritance and compile-time relationships, Object Patterns recount tales of composition and dynamic collaborations. Together, they form the rich tapestry of the GoF design patterns, guiding developers through the intricate dance of object-oriented design.

The Gang of Four (GoF) design patterns are divided into three categories: creational, structural, and behavioral. Class patterns and object patterns are both creational patterns.
A class pattern is a design pattern that uses inheritance to create new classes. The new classes inherit the properties and behaviors of the base class, and can also add their own unique properties and behaviors. Class patterns are static, meaning that the relationships between the classes are fixed at compile time.
An object pattern is a design pattern that creates new objects at runtime. The new objects are created by delegating the instantiation to another object. Object patterns are dynamic, meaning that the relationships between the objects can be changed at runtime.
Here is a table that summarizes the key differences between class patterns and object patterns:
Feature Class Pattern Object Pattern
Type Static Dynamic
Relationship between classes Fixed at compile time Can be changed at runtime
Instantiation Inherited from base class Delegated to another object

Some examples of class patterns include the Abstract Factory pattern, the Factory Method pattern, and the Singleton pattern. Some examples of object patterns include the Prototype pattern and the Builder pattern. In general, class patterns are more suitable for situations where the relationships between the classes are known at compile time. Object patterns are more suitable for situations where the relationships between the objects can change at runtime. Here is an example of a class pattern: the Abstract Factory pattern. The Abstract Factory pattern defines an interface for creating families of related or dependent objects without specifying their concrete classes. This allows the client code to create objects without having to know the concrete classes of the objects. Here is an example of an object pattern: the Prototype pattern. The Prototype pattern creates a new object by cloning an existing object. This allows the client code to create new objects without having to know the concrete class of the objects.
Patterns may be further divided according to their scope. There are two pattern scopes:
  1. Object Patterns

    Object patterns, the more common of the two, specify the relationships between objects.
    In general, the purpose of an object pattern is to allow the instances of different classes to be used in the same place in a pattern. Object patterns avoid fixing the class that accomplishes a given task at compile time. Instead the actual class of the object can be chosen at runtime. Object patterns mostly use object composition to establish relationships between objects.
  2. Gang of Four Patterns

    Class patterns

    Class patterns specify the relationship between classes and their subclasses.
    Thus, class patterns tend to use inheritance to establish relationships. Unlike object patterns and object relationships, class patterns generally fix the relationship at compile time. They are less flexible and dynamic and less suited to polymorphic approaches.

Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labeled class patterns are those that focus on class relationships. Note that most patterns are in the Object scope.
Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Class scope is defined at design time and is built in the structure and relationship of classes where as object scope is defined at runtime and is based on the relationship of objects.