Se 350 Part 2

Front 1

Design Pattern:

Flyweight

Back 1

-used to reduce the memory and resource usage for complex applications containing many hundreds, thousands, or millions of duplicate objects

-only one object holding a specific value is ever created (immutable objects)

Front 2

Pros of Flyweight

Back 2

-reduce resource load

-easy to make an efficient API

Front 3

Cons of Flyweight

Back 3

-Only optimizes code, should not be used everywhere

-Adds complexity to code, harder to maintain and debug

Front 4

Design Pattern:

Memento

Back 4

-Permits the current state of an object to be "externally" stored without breaking the rules of Encapsulation or the SRP principle

-Domain object can be modified but can be restored to the saved state at any time

-Supports an "undo" option!

Front 5

Operation Reversal

Back 5

Storing a list of executed operations, each associated with a reverse operation

Front 6

State Storage

Back 6

Storing the state of something after each "move"

Used in checkers or chess, too complex for operation reversal.

Front 7

Memento Components

Back 7

Originator - domain object w/ internal state

Caretaker - responsible for saving memento objects and returning them. caretaker doesn't know what's inside the mementos.

Memento - used to hold information from an originator's state. a snapshot!

Front 8

Design Pattern:

Composite

Back 8

-partitioning design pattern

-allows a group of objects to be treated the same way as a single instance of an object

-composes objects into structures that represent part-whole hierarchies. composite lets objects treat individual objects and compositions uniformly

Front 9

Single Responsibility Principle

Back 9

-there should never be more than one reason for a class to change

-having more than one responsibility couples the responsibilities :\

Front 10

Open-Closed Principle

Back 10

-open for extension and closed for modification

-don't change old code but free to add new code

Front 11

Liskov Substitution Principle

Back 11

-Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

-if a program module is using the reference of a Base class, then it should be able to replace the Base class with a Derived class without affecting the functionality of the program

Front 12

Dependency Inversion Principle

Back 12

-high-level modules should not depend upon low-level modules. both should depend upon abstractions

-abstractions should not depend upon details. details should depend upon abstractions.

Front 13

Interface Segregation Principle

Back 13

- Clients should not be forced to depend upon interfaces they do not use

Front 14

Design Pattern:

NullObject

Back 14

An object with a defined null behavior.

Used to handle situations where a behavior is absent.

Front 15

Design Pattern:

Monostate

Back 15

"Conceptual Singleton"

Multiple instances can be created, instances of variables are static. You can create a thousand instances of the class, but they will see and share the same values.

Front 16

Design Pattern:

PowerType

Back 16

Removing unchanging "type" data from classes representing individual objects.

This pattern splits the "TheClass" into 2 classes. "TheClass" with changing data and "TheClassType" with unchanging data

Front 17

Design Pattern:

Observer

Back 17

Allows one object (or more) to watch another (the subject). Publish-Subscribe relationship.

Behavioral design pattern.

Front 18

Design Pattern:

Decorator

Back 18

A pattern that allows behavior to be added to an individual object either statically or dynamically without affecting the behavior of other objects from the same class.

Employee investigator01 = new PrincipleInvestigator();
investigator01 = new SafetyCaptain(investigator01);