156 lines
5.7 KiB
Markdown
Executable File
156 lines
5.7 KiB
Markdown
Executable File
**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.
|
||
|
||
![[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.
|
||
|
||
![[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:
|
||
|
||
![[decorator-problem.png]]
|
||
|
||
![[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.
|
||
|
||
![[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.
|
||
|
||
![[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.
|
||
|
||
![[command-pattern.png]]
|
||
## Adapter Pattern
|
||
|
||
Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate.
|
||
|
||
![[adapter-pattern.png]]
|
||
|
||
Another approach:
|
||
|
||
![[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.
|
||
|
||
![[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.
|
||
|
||
![[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.).
|
||
|
||
![[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.
|
||
|
||
![[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.
|
||
|
||
![[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.
|
||
|
||
![[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
|
||
|
||
1. 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.
|
||
|
||
2. 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
|