Design Patterns Flashcards
What is a design pattern
A proven solution for a recurring problem
a solution idea, scheme or template
Blackboard
collaborate on common data to get the best solution
have a common data store and let several competing nodes work collaboratively or against each other on that common data the one with the best performance/data wins, will get selected by the client
Scoped resource
make object available in a specifically defined scope, when exiting the scope, the object gets destroyed
create a critical section and requiring resources in that section
client cannot forget to release the resource
e.g. using statement which works as the context manager, or the “with” statement in python
Bridge
- Decoupling abstractions from implementations with adapters
- abstraction interface (client-requirements)
- implementor interface
- Both sides can evolve independently from each other
- client is only allowed to use abstraction interface
- abstraction interface only allowed to use implementor interface, not concrete implementations
- hide implementation side completely from the client
- improves extensibility, both sides can grow
- hiding implementation details from the client
Early aqcuisition
make resources available as early as possible
Eager Aqcuisition
make resource available as early as possible when the context is opened (e.g. a window)
[E] what do scoped lock, scoped resource and scope.. have in common?
all of them use common mechanism to automatically release the scoped resource in the end
[E] What is the difference between lazy and eager loading?
Lazy = load resource as late as possible (on access)
Eager = load resource when needed but also rather early than late
Flyweight
Store away similar values to only have one instance of them
You have only one instance for similar/same attributes
Pooling
You store multiple objects or reserve a bigger block of memory to be reused over and over again
until pool is used up
when more objects are needed, client has to wait until objects are freed again
store the results temporarily to be used again
[E] How does Caching differ from Pooling?
In Pooling: you reuse the already allocated memory instead of freeing/destroying. Only one client should use a resource at a time (exclusive access). Can be predefined or builds up over time.
In Caching: always builds up over time, non exclusive access
both have upper limits
[E] What is better for accessing a Database: Active Object or Active Record? Explain why!
Active record, contains CRUD operations
Active object is not at all about the database
Active Object
asynchronious thread pool
execute the command in a different thread than it was created initially
contains tasks the execution about commands that get executed in other threads
you have to encapsulate the command with its context
What is the purpose of design patterns
Easier knowledge transfer
efficient problem solving by reusing existing ideas
common vocabulary, terminology, or language
usefulness of an idea by generalizing the solution
What types of design patterns are there
Architechtural (fundamental structural patterns, Layers, Pipes-And-Filters, Broker, MVC)
Idioms (fine graned patterns for spec. contexts, Composite, Adapter, Proxy)
Design Patterns (more isolated problems, Counted Pointer, Scoped Locking)
What types of design patterns are there
Architechtural (fundamental structural patterns)
Idioms (fine graned patterns for spec. contexts)
Design Patterns (more isolated problems)
Pattern Format
- *Name**: A catchy name for the pattern
- *Context**: The situation where the problem occurs
- *Problem**: General Problem Description
- *Forces**: Requirements and Constraints - why does problem hurt?
- *Solution**: Generic Description of a proven solution.
- *Consequences** (Rationale, Resulting Context): What are the benefits and drawbacks? Pro and Contra?
- *Known-Uses**: Real Life Examples
How Design Patterns emerge?
Design Patterns are found - not invented!
They emerge out of real use-cases/known-uses
Pattern Languages
coherent systems of patterns
consisting of Patterns, Relations and Principles
SOLID
• Single Responsibility: A class should have one, and
only one, reason to change.
• Open Closed: You should be able to extend a class’s
behavior, without modifying it.
• Liskov Substitution: Derived classes must be
substitutable for their base classes.
• Interface Segregation: Make fine grained
interfaces that are client specific.
• Dependency Inversion: Depend on abstractions,
not on concrete implementations.
Principles of Good Programming
- Decomposition make a problem manageable decompose it into sub-problems
- Abstraction wrap around a problem abstract away the details
- Decoupling reduce dependencies, late binding shift binding time to “later”
- Usability & Simplicity make things easy to use right, hard to use wrong adhere to expectations, make usage intuitive
Decorator
Extend the functionality of an object, while maintaining the same interface.
add responsibilities to individual objects without affecting other
objects
reuse funcionality
disadvantages: hard to learn and debug
Proxy
Provide a placeholder for another object to control it.
Maintain a reference that lets the proxy access
the real subject and provide interface identical
to Subject
Control access to the real subject
Layers
Split your large system into layers based on abstraction levels
Problem: Hard to understand structure, many dependencies
Every layer uses defined services of sublayer
Every layer provides defined services to upper layer
Defined Interfaces between Layers
Dependencies/Changes are kept local
e.g.: Network stack, API’s, Operating Systems
Layers - Properties
Who composes the layers at runtime?
Layers are Black Boxes
Skip layers?
Stateless / Stateful
Interfaces defined
Broker
Manage dynamic communication between clients and servers in distributed systems
complex systems as a set of decoupled and interoperating components
Specify broker API (client side and server side)
addition, exchange, or removal of services shall be supported dynamically
Interoperability between different broker
Broker Pros/Cons
Pros:
Changeability & extensibility of components (with proxies and bridges)
Broker is a server (location transparency)
Reusability
Cons:
Broker is single point of failure
Hard to test and debug
Pipes & Filters
Form a sequence of processing steps using a common interface.
Processing of data streams decomposed into
several processing stages
exchange or reordering of processing steps
push or pull pipes
storage of interim steps, defined data format along each pipe
Multiprocessing
Pipes & Filters Pros
Pros:
exchange and reordering
parallel processing
Master-Slave
Distribute work amongst some helpers
partition identical work and separate concerns
multi-threaded applications maybe
master: coordination instance between clients maintaining slaves
slaves: only communicate with the Master
Master-Slave Pros/Cons
Pros:
Exchangeability and extensibility
Separation of concerns
Efficiency : parallel processing (multi-thread)
Cons:
Partitioning & control can be tricky
Client-Server
Let clients send requests to servers which answers with responses.
Distributed applications.
one dedicated provider (centralized system)
Client might not have processing power
serving a request/response communication over protocol
Server waits for requests, client sends request and waits for responses
Client-Server Pros/Cons
Pros:
Service-Oriented Architectures
Centralization of specific services
Workload gets moved to server
Cons
Single-Point-Of-Failure
Communication overhead
Client rely upon network and servers
Adapter
Wrap around a class to make it compatible to another interface.
Working with multiple different frameworks or libraries.
make incompatible classes work together
reuse the functionality of a class in your own context
Class may be sealed (inheritance is not possible)
Class or Object adapter
an Adapter class which wraps around the Adaptee
Adapter
Wrap around a class to make it compatible to another interface.
Working with multiple different frameworks or libraries.
make incompatible classes work together
reuse the functionality of a class in your own context
Class may be sealed (inheritance is not possible)
Class or Object adapter
an Adapter class which wraps around the Adaptee
Class Adapter cs Object Adapter
Class Adapter
override mechanisms based on inheritance
it is on a different branch of subclasses
Object Adapter
breaks inheritance hierarchy
Explicit implementation approach