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.

Our first patter - Singleton

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