Object-oriented design patterns Flashcards
creational design patterns
- how objects can be created
- maintainability
- control
- extensibility
singleton
factory method
structural design patterns
- how to form larger structures
- management of complexity
- efficiency
decorator
behavioural design patterns
- how responsibilities can be assigned to
objects- objects decoupling
- flexibility
- better communication
iterator
observer
design pattern
a reusable form of a solution to a common design problem
essential parts of a design pattern
pattern name
intent (what does it do?, what issue does it address?)
solution (basic elements providing a solution)
consequences (results and trade offs)
singleton
intent: ensure that only one instance of a class is allowed within a system; controlled access to a single object if necessary
consequences: controlled access to sole instance; reduces name space -> less global variables; permit also a variable number of instances
factory method
intent: abstract the process of object creation so that the type of the created object can be determined at run-time
- make a design more customisable in terms of which objects can be created
- want to avoid new operator because you don’t want to hard code which class you want to instantiate
consequences: you have a dedicated class for creating instances of objects
- you can pass arguments to that class for controlling the features of the objects you want to create
problem: The creation of subtype instances is hard-coded,
resulting in poor maintainability
decorator
intent: attach additional responsibilities to an object dynamically
- a flexible alternative to subclassing for extending functionality
- the number of classes within a hierarchy tree may explode
consequences: you can add responsibilities to individual objects, not to an entire class
- you can add. and combine responsibilities to individual objects, not to an entire class
- you can add and combine responsibilities transparently -> without affecting other objects
- you can also remove responsibilities at run-time
iterator
intent: need to abstract the traversal of wildly different data structures from client code
- provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation
- polymorphic traversal of collections
consequences: you have encapsulated the internal representation of your attributes with cardinality > 1
- if you change their internal representation, you do not need to change client code
- you can use for each construct over them
observer
intent: to let one or more objects be notified of state changes in other objects within the system
-state changes in one or more objects should trigger behaviour in other objects
consequences: support for broadcast communication
- when one object changes state, all its dependents are notified and updated automatically
- you can add or remove observers without modifying the subjects
iterator interface
- formally defines what “iterating” means
- once you implement such interface, your client can iterate over your elements in the same way
+hasNext()
+next()
…
iterrable interface
Now, to iterate over an object (polymorphically) we can
simply iterate over its returned iterator
+ Iterator<T> iterator()</T>
observer design decisions
inheritance vs. interface
scope of callbacks: multiple vs. single
control flow: internal vs. external calls to Notify()
data flow: push vs. pull
