Creational Patterns  «Prev  Next»
Lesson 3 How do creational patterns help programmers?
Objective Example of how Creational Patterns are Used.

Example of how Creational Patterns are Used

How is the concept of abstraction used in creational design patterns? Abstraction is a core principle in object-oriented programming and design patterns, including creational design patterns. It's like an artist's sketch, capturing the essential details while ignoring the less important nuances. In the context of creational design patterns, abstraction is utilized to separate the specifics of object creation from the general application structure.
  1. Abstract Factory Pattern: This creational design pattern takes abstraction to another level. It provides an interface for creating families of related or dependent objects without specifying their concrete classes. Here, the abstraction lies in creating an overarching factory that creates other factories. These factories, in turn, produce objects, thereby abstracting away the direct instantiation process. Hence, the client interacts only with the abstract elements, not needing to know which factory it's dealing with or how objects are being instantiated.
  2. Factory Method Pattern: In the Factory Method pattern, the creator class is abstracted with an interface or abstract class. This abstract class defines a method, the factory method, for creating objects, but it leaves the implementation of this method to its subclasses. This means the client code interacts with the abstract class, not knowing which concrete class it's dealing with. The concrete classes decide what objects to instantiate, providing a layer of abstraction over object creation.
  3. Builder Pattern: The Builder pattern abstracts the process of creating complex objects. Instead of a monolithic constructor that requires numerous parameters, the Builder pattern breaks down the creation process into a series of steps. The client code doesn't see the complexity of object creation and interacts only with the builder interface, allowing for different types and representations of an object.
  4. Prototype Pattern: The Prototype pattern uses abstraction by working on a prototypical instance and creating new objects by copying this prototype. Here, the system is abstracted from the concrete prototypical object classes, as these objects are cloned to create new instances.
  5. Singleton Pattern: Although the Singleton pattern is less about abstraction and more about restricting object creation, it still uses a form of abstraction where the code does not need to understand whether or not an instance of the class already exists.

Through the lens of abstraction, creational design patterns provide a clear, clean, and efficient way to instantiate objects, keeping the system flexible, maintainable, and scalable. By limiting dependencies and promoting loose coupling, abstraction within these patterns allows the system to focus on what is being done, not on how it's being done, thus ensuring a more elegant software design.

Factory Method Pattern: URLConnection

Creational patterns hide many details from programmers. For example, the Java core API[1] uses the Factory Method pattern to create URLConnection objects. This specific Factory Method is openConnection() in the class.

public URLConnection openConnection() 
throws IOException

URLConnection is an Abstract Class[2]
Concrete subclasses represent connections to many different kinds of servers including HTTP, FTP, SMTP, NNTP, and other protocols. Each of these concrete subclasses has to speak a different protocol and behave a little differently. However, client programmers (the people who use this class) do not care about these details. They just need to read from input streams and write to output streams.
The interface a client programmer sees is the same generic URLConnection interface whether or not they are talking to a Web server, an FTP server, or a news server. Since the subclass names are not hard coded into the program, additional subclasses that handle additional protocols can be added at later times without even recompiling any code. Indeed this design pattern lies at the foundation of Java's much-hyped protocol handler mechanism.

In the seminal work "Design Patterns: Elements of Reusable Object-Oriented Software," often referred to as the Gang of Four (GoF) book, creational patterns occupy a distinct and foundational role in software design. Authored by
  1. Erich Gamma,
  2. Richard Helm,
  3. Ralph Johnson, and
  4. John Vlissides,
the book classifies design patterns into three principal categories: Creational, Structural, and Behavioral. Within this trichotomy, creational patterns serve as the scaffolding that allows for the robust and efficient instantiation of objects.

Contextual Relevance of Creational Patterns

Creational patterns are not mere ad-hoc solutions but a distillation of proven strategies for object creation, optimized for scalability, maintainability, and modularity. They resolve the intricacies associated with the direct use of constructors, offering a level of abstraction that isolates the specifics of object creation and initialization. This isolation is vital in complex systems where objects are interdependent or where the construction logic itself is subject to change.

Creational Patterns Defined by GoF

The Gang of Four identifies five creational patterns:
  1. Singleton: Ensures that a class has only one instance and provides a global point of access to it. Singleton is quintessential for scenarios where single-point access to resources like database connections or logging services is essential.
  2. Factory Method: Defines an interface for creating an object but allows subclasses to alter the type of objects that will be created. This pattern is pivotal when a class cannot anticipate the class of objects it must create.
  3. Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. This pattern is often employed in GUI libraries where each OS provides a different implementation of graphical elements.
  4. Builder: Separates the construction of a complex object from its representation, enabling the same construction process to create various representations. This is commonly used for building complex documents, such as XML or HTML files.
  5. Prototype: Creates new objects by copying an existing object, known as the prototype. This is useful when the cost of creating an object is more expensive or complex than copying an existing one.

Analytical Insights

In a nuanced analysis of the Gang of Four’s framework, one observes that creational patterns bring more than just object instantiation strategies; they introduce principles that align with broader object-oriented design philosophies. For instance, the Factory Method and Abstract Factory patterns align closely with the Open/Closed Principle by allowing classes to be open for extension but closed for modification. The Builder pattern is an embodiment of the Single Responsibility Principle, isolating the complexity of object creation from the object's actual business logic.
Moreover, creational patterns often complement structural and behavioral patterns. For example, Singleton patterns are frequently used in conjunction with other patterns like Facades, Observers, or Decorators to maintain single instances of control objects or shared resources. In the context of the Gang of Four's framework, creational patterns are not merely recipes for object instantiation; they are archetypal solutions that address various challenges in object-oriented design. By adopting creational patterns, developers gain a robust toolset for handling object creation complexities in a scalable and maintainable way, thereby adhering to established principles and best practices in software engineering. This makes creational patterns not just elemental but pivotal in the architecture of object-oriented systems.
This is an excellent use of a creational design pattern to enhance flexibility about what gets created. Creational design patterns can also be used
  1. to increase the flexibility with respect to who creates an object,
  2. how the client creates the object, and
  3. when the object is created.

Abstract classes are defined so that other classes can extend them and make them concrete by implementing the abstract methods.

[1]Application Programming Interface: The API specifies the method used by a programmer when writing an application to access the behavior and state of classes and objects.
[2]Abstract Class: A class that contains one or more abstract methods, and therefore can never be instantiated.