ECS 160 Design Pattern

Encapsulation

internal details of a class are hidden, access is controlled using public, private, protected

Abstraction

a simplified representation of something more complex. Abstractions allow you to hide details to help you manage complexity, focus on relevant concepts, and reason about problems at a higher level.

Inheritence

allows the reuse of code, this would be a child that extends of a parent

Abstract Class

a class that cannot be instantiated, only single inheritance allowed, can choose to override any methods already written but needs to implement any methods not yet implemented, must be extended, "is-a"

Abstraction via Interface

defines a contract for what a class must do but not how, multiple inheritances allowed, is a contract you must follow, must be implemented, "can do"

Runtime Polymorphism

The compiler cannot make the determination but instead the determination is made while the program is running

Static Class Member

single copy of the field is created, belongs to the class

What are the three types of design pattern categories and what are the differences?

creational (how objects are created), structural (how objects and classes are composed and deal with the relationships between objects), behavioural (control how objects distribute responsibilities)

Singleton DP, what situation you'd use, explain how to implement, the category, the pros and cons

this is when you want one object of a class to exist and accessed

case study is logger

creational DP

to implement we need a private constructor + private static object + getter,

pro: include controlled access to the instance

con: are potential bottlenecks and difficulty in testing and can create hidden dependencies

Abstract Factory DP, what situation you'd use, explain how to implement, the category, the pros and cons

creates a family of related objects without the client having to know the exact classes being created

case study is UI toolkit

creational DP

we would have the abstract family class, an application class that contains the fields of the children, and the children will extend the application class and implement what is needed, the application class has a private object that tells us which child we should go to

pro: promotes consistency, catches error at compile time

con: more classes = more complexity

Adapter DP, what situation you'd use, explain how to implement, the category, the pros and cons

adapter converts the interface of a class to another interface the client expects

case study is payment with app and stripe

structural DP

we will create an adapter wrapper (stripeAdapter) that implements our interface (payProc) and in this will let us know what interface to go to, we wrap our third party in it (stripeProc), anytime we called our regular payProc it can check if it is the stripe

pro: don’t modify app logic, remove “if” logic

con: overcomplicated with many layers + wrappers

Proxy DP, what situation you'd use, explain how to implement, the category, the pros and cons

mediated by intercepting a call, user accesses the proxy instead of the real object, and some additional logic can be added

case is adding logging functionality

structural DP

we have our proxy object that extends our person class and overrides the functions, has the same API as the inner object but with some extra functionality

pro: adds additional functionality without changing class

con: additional classes = additional complexity, may need to override many objects

Bridge DP, what situation you'd use, explain how to implement, the category, the pros and cons

splits one hierarchy into two separate ones that are connected, helps prevent class exploision

case study is vehicle and energy source

structural DP
our vehicle class will have a private energy object, our energy class will have multiple types of energy children, our vehicle class will have multiple vehicle children

pro: decouples abstraction and implementation, improves extensibility

con: it is still more classes, can have combos we don’t want

Facade DP, what situation you'd use, explain how to implement, the category, the pros and cons

a simple front door to a complex subsystem

case study is translation

structural DP

our client will have access to a class in which that contains all of the background stuff

pro: shields client from subsystem components, provides a unified interface, weak coupling between subsystem and client (client does’t need to know)

con: many tasks can mean a lot of orchestration in the background

Decorator DP, what situation you'd use, explain how to implement, the category, the pros and cons

dynamically attaches additional functionality by wrapping objects inside another object

case study is fraud detection

structural DP

create an wrapper abstract class decorator (PayProcDecor) that wraps the inner object which extends the interface (payProc), create the method decorator and extend to our wrapper decorator (fraudDetectDecor) and this will contain the additional functionality, you can stack decorators

pro: avoids feature-laden classes high up in the hierarchy and instead have subclasses, pay as you go approach

con: can be hard to debug

Observer DP, what situation you'd use, explain how to implement, the category, the pros and cons

when an object changes, all interested objects in that change are automatically notified, coupling between subject and observer

case study is the graphs

behavioural DP

we will have an overall class (dataModel) that contains a list of the observers, adding observers, removing, notifying graph loop, and setting the data which calls notifying, while we also have our observer interface with an update method, and our different subclass of graphs will implement the observer interface with its specific update functionality
pro: supports broadcast communication

con: can cause cascading updates without knowing, one trigger update can cause many others to update

State DP, what situation you'd use, explain how to implement, the category, the pros and cons

lets objects behave differently depending on its current state without filling the main class with lots of i else

case study is music player

behavioural DP

we will have an interface mediaPlayerState that contains subclasses for the different state (stop, play, pause), and then the different states are classes that extend the interface and overrides the methods, our main class will keep track of the current state with this

pro: can’t miss a state due to the interface, avoid large if-else, extensible in adding new states

con: more classes

Template DP, what situation you'd use, explain how to implement, the category, the pros and cons

defines the overall steps of an algorithm but allows subclasses to change certain steps

case study is traversing source to dest note

behavioural DP

in our abstract class, we will have concrete methods that is shared between algorithm, and a protected abstract method that is different from class to class, in these separate class, we will override that protected method, we can have a template where subclasses can optionally implement the methods (hook) or they must implement the abstract methods (abstract operations)

pro: allows code reuse, we have an “inverted” structure where parents call the operation of the child class

con: lots of override and more subclasses

Visitor DP, what situation you'd use, explain how to implement, the category, the pros and cons

all logic for one op should be kept together, “all in one place”

case study is shapes

behavioural DP

our abstract class visitor will contain the visits for all shapes and a visit method that loops thorough our shape have an abstract shape class that our shapes will extend

pro: keep logic all together

con: can get complicated

Single Dispatch

we only check the runtime of the object being called on

Z w = new W()

X x = new Y()

w.p(x)

we will check the runtime of argument w which is object W, and we will go to the method p that takes in an argument X of the compile time which is object X

Double Dispatch

we check the runtime type of the objects

Z w = new W()

X x = new Y()

w.p(x)

we will check the run time of both, so we will go to object W’s, find the method p that takes in an object Y

because of this, we do not need an accept