72 lines
2.7 KiB
Org Mode
Executable File
72 lines
2.7 KiB
Org Mode
Executable File
:PROPERTIES:
|
||
:ID: 631b2086-4b8f-4fe3-829d-be1dc014e293
|
||
:END:
|
||
#+title: Design patterns
|
||
#+filetags: :notes:career:technical:
|
||
|
||
* 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
|