Object Orientation with Design Patterns

Amilcar Aponte amilcar@cct.ie

Literature

• Gamma, E., Helm, R., Johnson, R. & Vissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software. United States: Addison-Wesley
• https://refactoring.guru/design-patterns

What are design patterns

• They provide solutions to common software design problems.
• Generally aimed at solving the problems of object generation and interaction, rather than the larger scale problems of overall software architecture
• They give generalised solutions in the form of templates that may be applied to real-world problems.

Why use design patters

• Flexibility: Using design patterns your code becomes more flexible. It helps to provide the correct level of abstraction due to which objects become loosely coupled to each other which makes your code easy to maintain.

• Reusability: Loosely coupled and cohesive objects and classes can make your code more reusable.

• Shared Vocabulary:
  • Shared vocabulary makes it easy to share your code and thought with other team members.
  • It creates more understanding between the team members related to the code.

• Capture best practices (In Amilcar's my opinion, the most important):
  • Design patterns capture solutions that have been successfully applied to problems.
  • By learning these patterns and the related problem, an inexperienced developer learns a lot about software design.
  • These solutions have been tested, used, reused and used again – And they work!

Essential elements

Design patterns essential elements

• Name:
  • Provides a single and meaningful name to the pattern, and defines a problem and a solution for it.
  • Naming a design pattern helps itself to be referred to others easily. It also becomes easy to provide documentation for and the right vocabulary word makes it easier to think about the design.

• The Problem:
  • It explains the problem and its context.
  • It might describe specific design problems.
  • Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.

• The solution:
  • It describes the elements that make up the design, their relationships, responsibilities, and collaborations.
  • The solution is not the complete code, but it works as a template which can be fulfilled with code.
  • The pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.

• Implications:
  • The consequences of a pattern include its impact on a system’s flexibility, extensibility, portability or possible trade-offs.
  • Listing these consequences explicitly helps you understand and evaluate them.

Categories of patterns

• Creational:
  • Creational design patterns are used to design the instantiation process of objects.
  • The creational pattern uses inheritance to vary the object creation.

• Structural:
  • Structural patterns are concerned with how classes and objects are composed to form larger structures.
  • These patterns are particularly useful for making independently developed class libraries work together.
  • Rather than composing interfaces or implementations, structural object patterns describe ways to compose objects to realize new functionality.

• Behavioural:
  • Behavioural patterns are concerned with algorithms and the assignment of responsibilities between objects.
  • Behavioural patterns describe not just patterns of objects or classes but also the patterns of communication between them.
  • Some describe how a group of peer objects cooperate to perform a task that no single object can carry out by itself.

Singleton

https://refactoring.guru/design-patterns/singleton

Singleton is a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance.

Problem:

The Singleton pattern solves two problems at the same time, violating the Single Responsibility Principle:

• Problem 1: Ensure that a class has just a single instance. Why would anyone want to control how many instances a class has? The most common reason for this is to control access to some shared resource—for example, a database or a file.

Here’s how it works: imagine that you created an object, but after a while decided to create a new one. Instead of receiving a fresh object, you’ll get the one you already created.

Note that this behavior is impossible to implement with a regular constructor since a constructor call must always return a new object by design.

• Problem 2: Provide a global access point to that instance. Remember those global variables that you (all right, me) used to store some essential objects? While they’re very handy, they’re also very unsafe since any code can potentially overwrite the contents of those variables and crash the app.

Just like a global variable, the Singleton pattern lets you access some object from anywhere in the program. However, it also protects that instance from being overwritten by other code.

There’s another side to this problem: you don’t want the code that solves problem #1 to be scattered all over your program. It’s much better to have it within one class, especially if the rest of your code already depends on it.

Solution:

All implementations of the Singleton have these two steps in common:

• Make the default constructor private, to prevent other objects from using the new operator with the Singleton

• Create a static creation method that acts as a constructor. Under the hood, this method calls the private constructor to create an object and saves it in a static field. All following calls to this method return the cached object.

If your code has access to the Singleton class, then it’s able to call the Singleton’s static method. So whenever that method is called, the same object is always returned.

Let's think of a particular -very specific- problem:

• Singleton pattern restricts the instantiation of a class and ensures that only one instance of the class exists in the java virtual machine.
• The singleton class must provide a global access point to get the instance of the class.

• Private Constructor
• Private, static reference to itself
• Public, static getter