Ultimate Design Patterns - Behavioral Flashcards

Question

**What** are the three **UML relationships**?

Answer 1

**Inheritance** - methods defined in super class **composition** - made of another class **dendency** - use another class

Answer 2

An **arrow from child to parent**

Answer 3

An **arrow with a diamond ending** **Shape** is composed of **size class** In **Shape class**, have field called size **What is it?** ex. **Car class** is composed of **wheel class**, because **every car has four wheels**

Answer 4

Top - name of class middle section - fields (type of field) below - methods (parameter or return type - = private + = public

Answer 5

**Means?** Somewhere in **Shape class**, **reference Document class** r**ender method's parameter** is **dependent on Document class**

Answer 6

Building **undue features**!

Answer 7

An **important principle** in **OOP** **Says:** **every class** should have a **single responsibility** **Ex. Restaurant** **Waitor only takes order, doesn't do taxes, shopping, cooking!**

Answer 8

**Design our claseses such** that **each class** has only a **single responsibility.**

Answer 9

Used to **implement undue** **Originator** - Editor **Memento** - EditorState **Caretaker** - History

Answer 10

**History** - keeps track of changes in editor, stores editorState objects **EditorState** - **Editor** - .**restore(state)** takes **state** object and **resets fields** based on what is **in state**

Answer 11

**A set** of **constants**

Answer 12

It's **not maintainable and** lacks **extensibility**! **Why?** **not** easy to **maintain and extend** = The more **tools we add,** the more **decision making statements** will be **required** and we have to go to **different methods and make changes** ex. change **mouseDown ( )** and **mouseUp ( )** to accomodate a new tool **Soln?** Ploymorphism

Answer 13

**Allows** an object to **behave differently** **depending** on the **state** ## Footnote **always use meaningful names that fit the domain of your application!** **Textbook names are too general.**

Answer 14

Don't **have a long list** of **decision statements** Code is **more maintainable** **Can easily extend**

Answer 15

To implement **behaving differently** depending on the **state of another object**

Answer 16

everytime we **change the internals of the class**, we get **breaking changes!** **Changing** the **internals of a class** shouldn't **affect its consumers!** If we **replace the original datastructure** storing **urls** we will have **breaking changes in our main class** **Ex.** Two breaking changes in main class by replacing an arrayList with a fixed array internally!

Answer 17

everytime we **change the internals of the class**, we get **breaking changes!** Changing the **internals of a class** shouldn't **affect its consumers!** Encapsulating **breaking changes** within **a class** so that **consumers** of our class are **not affected** **Using Iterator Pattern** - don't need to know the internal structure of the class (array, stack, etc.) **hasNext ( )** - returns boolean **next ( )** - returns void **Telling history item** - give me another item, give me another item

Answer 18

It **breaks** the **single responsibility criteria** It's **responsible** for **history management** **It's responsible for iteration**

Answer 19

When **createIterator ( )** is called, **Iterator object** is returned ## Footnote **Programmed to an interface!**

Answer 20

1. **breaking changes are localized to one class** - other classes do not break if changes are made to **internal structure of class** **Can change the internal iterator from List to ArrayIterator!**

Answer 21

1. **Single Responsibility Principle Violation** - this class is responsible for **storing an image** AND **compressing** an **image/applying a filter**! As we **support more image processing** algorithms, **if/else if** **statements** will get very long and **hard to maintain!** **2. Difficult to extend number of filters -** Have to make changes in different parts of class. **The more filters we support, the more bulky our class will become!** **OOP SOLN:** **Polymorphism!**

Answer 22

**Context** maintains **reference to strategy object** **Strategy** interface **represents an algorithm** **Different** classes **implements the algorithm** **We use both patterns to change behavior of objects** **Different behaviors are represented by different strategy objects vs. one state object (State Pattern)**

Answer 23

**Strategy pattern** - different behaviors are r**epresented by different strategy objects** **State pattern** - All behaviors are represented by a **subclass of state interface**

Answer 24

This is open-closed principle!

Answer 25

Update the **ImageStorage**.**store** method to take **Compressor and Filter Objects** (code against interface) Can pass **alternative classes** implementing **the Interfaces** to **the method**

Answer 26

Instead of **Filter / Compressor Interfaces** create **Encryptor Interface** w/ **multiple implementing classes** (64-bit encryption, 32-bit encryption)

Answer 27

**Code duplication** Solve How? **OOP Inheritance!** Ex. **Everytime** we **create a new task**, we have to **instantiate a new auditTrail** and call the **.record method**! This is repetative

Answer 28

**Abstract class** with a **Template Method** or **skeleton for an operation** **Hooks** = default method implementation, childClass can override if required (very common in **Java, Javascript, etc**.)

Answer 29

**No - private methods are not inherited by subclasses!** if we **declare** our **abstract method as private** we **won't be able to over-ride it!** **Protected keyword** - hides method but **makes it available** to **subclass**

Answer 30

Create an **Abstract Class** **execute ( ) method** - has **under-the-hood logic** executed everytime + .**doExecute ( )** method call which can be polymorphed by each sub-class

Answer 31

**Coupling** between a **sending class** and a **recieving class**

Answer 32

Decouple a **sender to a reciever** Each request is a **command object**

Answer 33

**Decouple** a **sender to a reciever** **Each reques**t is a **command object** 1. We can **pass them around** our code 2. We can **pass them as arguments t**o our methods 3. We can **add them to a list** to keep track of all commands executed, redo them, undue 4. Can **store in a DB** and run later

Answer 34

**Composite Command** Each task is a command object can combine them into a composite object

Answer 35

**Create Command interface** Create **UndoableCommand** interface (inherits command) Implementing class - **BoldCommand** Ex. Undo bold text, not save

Answer 36

**Commands** - links between GUI and Business logic **HtmlDocument** - implements business logic / makeBold ( ) **History** - keeps track of commands applied

Answer 37

**State** of **object changes** and **we need** to **notify** other **objects of changes!** **Used** in **a lot** of **frameworks!** Ex. **values** in **excell sheet updated**, **pie chart** and second sheet is **automatically updated!**

Answer 38

**aka**"Publish Subscribe Pattern" follows open-closed pattern! Can add more observers! **DataSource** - maintain list of observer objects **update ( )** - polymorphic behavior, different update ( ) method for each concreate implementation **addObserver (obs)** - add observer to list of observers **removeObserver (obs)** - delete observer from list to dynamically add/remove **notifyObservers ( )** - iterate over observers, where polymorphic behavior, depending on type at runtime, single place to notify all observers about changes!

Answer 39

**Changes** are **pushed to observer!** **Challenge:** It is **not extensible** without **violating** the **open-closed principle!** If we introduce a **new ConcreteObserver (future)** may have to go to **Observer interface** to introduce **new fields in class!** **It's not flexible!** Assumes **Observer**s needs **same values but some Observers could take different values!**

Answer 40

**Observers pull data** they need **when changes occur** It's **Flexible** Each **concrete observer** can **get data they need** **There is coupling**, but it's okay! **No zero coupling** in **software**. **Direction** of **coupling/relationship matters!** **Direction** of **coupling makes** it **acceptable**

Answer 41

**Coupling but it's okay!** Introduce a **private field** of **type DataSource** **Initialize** in **Constructor** In **update** method call .**getValue( )** **More Flexible!**

Answer 42

**When** we have a **bunch of objects** that **need to talk to eachother!**

Answer 43

**Base classes** = ListBox, TextBox, Button **Many dependencies** **Logic** spread all **over the place** (different classes) **understanding** and **maintaining** **becomes difficult** with scale! **Soln:** **DialogBox (abstract class)** - how objects interact will change from one dialogue box to another **ArticlesDialogBox (concrete class)** - where we implement all the logic for how objects interact

Answer 44

**Meditator** controls **interaction between objects!** **Mediator** - like dialogue box **Concrete Mediator** - articles dialogue box **Colleague** - UI Control **ConcreteColleague -** List, textbox, button

Answer 45

**UIControlObjects (TextBox, Button, etc)** = Subject class **ArticleDialogBox** = Observer of changes in UIControlObjects

Answer 46

**.attach ( )** method **requires an implementation** of the **Observer Interface** **Observer Interface i**s a **functional Interface** **(single method)** The **changed ( )** method is **polymorphically i**mplemented by each **Concrete Observer** A **concrete observer** can be **implemented** using an **annonymous inner class** that implements the **Observer Interface** in the anonymous inner classes **@changed ( )** method, we can call **articleSelected ( ) upon change** This can be replaced by a lambda

Answer 47

**When** we need a **pipeline (chain of objects)** to **process a ANY request** **Ex. Web server** that need to **authenticate, log and compress** an HTTP **request** **Solution:** **Build a pipline or chain or objects for process a request without having to make changes to single class**

Answer 48

It would **violate** the **single responsibility principle** **Solution**: **Authentication Class** - logic for authentication **Compressor Class** - logic for compression **Logger Class** - logic for logging

Answer 49

**Webserver.handle ( ) -** logic is very fixed If we want to **change our data processing pipeline** steps, have to change the **.handle ( ) method!** **To add a new step have to change implementation of .handle ( ) method - this violated the Open Closed Principle!** Open for extension, closed for modification! **Soln:** Pipeline of **processing objects** in a chain **Each object** only knows about the **next object in the chain**

Answer 50

**WebServer** - talks to handler interface indirectly has reference to first handler in chain (authenticator)

Answer 51

System is **open to extension**, **closed to modification** Can add **new step** anywhere **in the chain** Ex. add **new Handler** called Encryptor **Can build** data **processing pipelines** that follow the **open closed principle!**

Answer 52

**Allows** us to **add new operations** to an **object structure** without **modifying the item** **Ex. HtmlNode interface** - if we **add new methods** to this **interface**, will then **have to go to every concrete implementation** and **implement the new method**! Additionally, in HtmlDocument (dependency on HtmlNode) have to iterate **over all objects** and call the **.newMethod**! This violates **Open-Closed Principle!** **Also, logic is spread over multiple classes!** Why? Everytime we want to **introduce a new operation,** have to make changes to **every object in our structure**

Answer 53

1. All **logic** for **an operation** is in **a single place** 2. Follows **Open-Closed Principle** **Beware!** **Only** use if **object structure** is stable! Why? Everytime we **create a new opeartion**, have to **update the Operation interface** and all **implementing classes**

Answer 54

**Names are Abstract** **Key principle:** Allows us to add new operations without changing our object structure **How?** Create new class that implements Operation Interface

Answer 55

Account Creation - Template Method Pattern Match History - State Pattern Matching - Observer Pattern Messaging - Data Structure - graph Prediction - getKthNode Geolocation - traverse, shortest Path Algorithm