org_roam/Career Concepts/20251223215636-design_patterns_notes.org

:PROPERTIES:
:ID:       631b2086-4b8f-4fe3-829d-be1dc014e293
:END:
#+title: Design patterns
#+filetags: :notes:career:technical:
#+category: Career Concepts

*WIP*

* Summary of the major patterns:

** The Strategy Pattern
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

[[./assets/design-patterns/structure-pattern.png]]



** Observer pattern
Observer is a behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing.

[[./assets/design-patterns/observer-pattern.png]]


** Decorator pattern

Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

The problem:

[[./assets/design-patterns/decorator-problem.png]]

[[./assets/design-patterns/decorator-pattern.png]]


** Factory Pattern
Factory Method is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.

[[./assets/design-patterns/factory-pattern.png]]


** Singleton Pattern
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.

[[./assets/design-patterns/singleton-pattern.png]]


** Command Pattern
Command is a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you pass requests as a method arguments, delay or queue a request’s execution, and support undoable operations.

[[./assets/design-patterns/command-pattern.png]]


** Adapter Pattern
Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate.

[[./assets/design-patterns/adapter-pattern.png]]

Another approach:

[[./assets/design-patterns/adapter-pattern-2.png]]

** Facade Pattern
Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

[[./assets/design-patterns/facade-pattern.png]]


** Template Method Pattern
Template Method is a behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure.

[[./assets/design-patterns/template-method-pattern.png]]

** Iterator and Composite Pattern
Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.).

[[./assets/design-patterns/iterator-pattern.png]]

Composite is a structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects.

[[./assets/design-patterns/composite-pattern.png]]

** State Pattern
State is a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class.

[[./assets/design-patterns/state-pattern.png]]

** Proxy Pattern
Proxy is a structural design pattern that lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object.

[[./assets/design-patterns/proxy-pattern.png]]

* Design patterns. What are they?

They are reusable solutions to common problems in software design. They help to make code more flexible, maintainable, and scalable.

Patterns allow you to say more with less. When you use a pattern in a description, other developers quickly know precisely the design you have in mind.

** OO concepts:
*** Abstraction:
Focuses on essential features while hiding unnecessary internal details, allowing developers to work with high‑level concepts instead of implementation complexity.
  
Example: A Car class exposes start() and stop() methods without revealing how the engine ignition system works.

*** Inheritance:
Enables one class to derive properties and behaviours from another, promoting code reuse and creating natural parent–child hierarchies.

Example: A Dog class inherits from an Animal class, automatically gaining attributes like age and methods like eat().

*** Encapsulation:
Protects an object’s internal state by restricting direct access to its data and exposing controlled interfaces for interaction.

Example: A BankAccount class keeps its balance private and provides deposit() and withdraw() methods to modify it safely.

*** Polymorphism:
Allows different objects to respond to the same interface or method call in their own unique ways, enabling flexible and extensible system design.

Example: Calling makeSound() on an Animal reference triggers bark() for a Dog and meow() for a Cat.

** OO principles:

- Encapsulate what varies

- Favor composition over inheritance

- Program to interfaces, not implementations

- Strive for loosely coupled designs between objects that interact

** OO Patterns

You have:
- *behavioural* patterns
- *creational* patterns
- *structural* patterns

*** Behavioural patterns
**** Structural:
The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
**** Observer:
The Observer Pattern defines a one-to-many dependency between objects so that when
one object changes state, all of its dependents are notified and updated automatically.

Subjects, or as we also know them, Observables, update Observers using a common
interface

Observers are loosely coupled in that the Observable knows nothing about them,
other than that they implement the Observer interface.

You can push or pull data from the Observable when using the pattern (pull is
considered more “correct”).

Don’t depend on a specific order of notification for your Observers.

Java has several implementations of the Observer Pattern, including the general
purpose java.util.Observable