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:

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:

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.