Design Patterns quiz A

Open/Close

"open for extension, but closed for modification" It states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.

Single Responsibility Principle

A class should do one thing and one thing only

Inheritance

A white box approach to building a child class from an existing class (parent). The new class (child) can have additional attributes and behaviors. The child can also modify (override) the behaviors of the parent. Characterised as an "is a" relationship.

Bridge Pattern

Abstraction and implementation are not related in the sense that the implementation is a concrete version of the abstraction ●What a class can do is the abstraction, what a class itself can be thought of is the implementation ●The Bridge Pattern allows both to change independently (thus loose coupling is in place) ●Think of this pattern as two layers of abstraction

Pillars of OO

Abstraction, Polymorphism, Encapsulation, Inheritance

State Pattern

Allows an object to alter its behavior when its internal state changes. The object will appear to change its class (to the client). ●A behavioral pattern used to represent the state of an object ●A clean way for an object to partially change its type at runtime ●Typically involves an interface to represent state behaviors ●Concrete state classes implement interface (or extend abstract class) ●These classes usually are in charge of modifying state (sometimes context can do this) ●Context class *typically* contains references to all the different types of state objects as well as state object that represents current state

Composite Pattern

Allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and composition of objects uniformly. ●Provides a structure to hold both individual objects and composites (think tree data structure) ●Allows clients to treat composites and individual objects uniformly (decoupling) ●A Component is any object in a Composite structures that may be other composites or leaf nodes

Decorator Pattern

Attaches additional responsibilities to an object dynamically. Provides a flexible alternative to sub-classing for extending functionality.

Abstraction

Classes represent this. A set of behaviors that describe what a given entity can do and how that entity can be interacted with. Note: We do not worry about underlying details. We don't care about what attributes there are or how behaviors are implemented.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don't use.

Encapsulation

Combines attributes and behaviors to represent a single entity (class). Attributes are hidden from the outside world. A class should do one and only one thing (single responsibility principle).

Adapter Pattern

Convert the interface of a class into another interface that the client(s) expect. Lets classes work together that could not otherwise due to incompatible interfaces

Flyweight Pattern

Creational pattern that describes how to support a large number of fine grained objects efficiently, by sharing commonalities in state ● Minimizes memory use by sharing as much data as possible with other similar objects ● If parts of object state can be shared, you can put them in external data structures and pass them to the flyweight objects temporarily (when the flyweight objects are used) *Yes, Flyweight is named after the lightest general category in boxing. It lightens the way a set of related objects is represented in memory via shared state *Flyweight is often combined with Composite to implement a logically hierarchical structure in terms of a directedacyclic graph with shared leaf nodes ● State and Strategy objects are many times best represented as flyweights ● Often times are created using a Factory of some form and a Singleton is applied so that for each type of category of flyweights, a single instance is returned ● Any time you have numerous objects that are essentially the same, and thus can have shared state, are candidates for Flyweight. Games with massive numbers of creatures can really use this to great advantage.

Observer Pattern

Defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

Factory Pattern

Defines an interface for creating an object, but let subclasses decide which class to instantiate.

Dependency Inversion Principle

Depend on Abstractions, do not depend on Concrete Classes High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Liskov Substitution Principle

Derived types must be completely substitutable for their base types.

Law of Demeter

Each thing should only know about it's immediate neighbors.

Command Pattern

Encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations Move the code for each individual action into its own class Each of these classes implement the same interface, allowing the code that uses them to interact solely with the interface and not know or care about the individual classes

Singleton Pattern

Ensures a class has one and only one instance, and provides a global point of access to it. Uses static constructor/get methods in Singleton class.

Strategy Pattern

Family of algorithms, encapsulates each one, and makes them interchangeable.

Polymorphism

Many forms We can have many versions of a given abstraction. We can treat objects as if they were instances of an abstract class but get the behavior that is required for their specific subclass.

Composition over inheritence

Principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class

Proxy Pattern

Provide a surrogate or placeholder for another object control access to the other object A proxy in its most common form is a class functioning as an interface to something else: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. ●Proxy, like any wrapper, increases the number of classes and objects in your designs ●There are many ways a proxy can manage access to subject (as evidenced by the many different versions of proxy) ●Similar to Decorator but it controls access where Decorator adds behavior. Because of this, Proxy is considered a Structural Pattern

Iterator Pattern

Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation

Facade Pattern

Simplify the interface the client needs to work with to communicate with complex sub-systems

S.O.L.I.D

Single responsibility principle Open/Close Liskov substitution principle Interface segregation principle Dependency inversion principle

Memento Pattern

The intent of this pattern is to capture the internal state of an object without violating encapsulation and thus providing a means for restoring the object into initial state when needed. It provides an undo via rollback. ●Use when you: ● Need to save all or part of the state of an object ● Do not wish to expose the saved state to the outside world ●Consequences ● Simplifies Originator (It does not need to provide all the code to manage the saved state) ● Copying state takes time and space, thus sometimes Memento is not appropriate

Builder Pattern

The steps of construction are abstracted so that different implementations of these steps can construct different representing objects. Often used to build products in accordance with the Composite Pattern. Sometimes creational patterns are complementory: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations. ● Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately. ● Builder often builds a Composite. ● Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

Mock Object

They are simulated objects that mimic the behavior of real objects in controlled ways ● 'Mocks' are typically used to test the behavior of some other object, much like a crash test dummy is used to simulate the dynamic behavior of a human in vehicle impacts ● They contain enough state and/or behavior to subsitute for the real object ● They are extremely useful in unit testing ● Used primarily for testing other objects in a system ● Can provide pre-determined behavior so outcome of tests can be easily evaluated ● Mocks feel like a fancier version of Null Object ● Good use of abstraction in your code makes it (very) easy to plugin a Mock Object in the place of a real one ● Use Mock Objects liberally to test your code. They are lightweight and easy to inject into your existing OO framework

Visitor Pattern

Used to traverse a Composite structure whose items may be completely different types and have completely different behaviors. It can add new functionality to the Composite without requiring behavior changes to the Composite itself. This is a direct application of the Open/Closed Principle. ●Visitor does violate encapsulation principles, so you must be ok with allowing an external entity to work 'directly' with the underlying components (which are usually hidden from the outside world) of a Composite. ●If the Composite is updated to include another element, the Visitor interface and all ConcreteVisitor classes need updated. This shows there is coupling with this pattern. It is somewhat similar in nature to the coupling you have in the Bridge Pattern (if the abstraction changes, the implementations must be updated). ●Visitor helps enforce Single Responsibility Principle and allows Composite object it visits to just worry about its true purpose. ●Visitor applies the Open/Closed principle because the Composite does not have to be modified (other than during initial design accepting a Visitor). ●Visitors are objects so can have state. This is very useful in cases where the action performed on a given part of the Composite depends on previous actions which may have modified state.

Attributes

fields/data/properties/variables

Behaviors

methods

Model View Controller (MVC)

●A compound pattern consisting of Observer, Strategy, and Composite patterns ●Widely used in GUI and web applications (Model 2) ●Decouples view from model ● View is there for users to see and interact with ● Model contains application logic and data ● Controller passes user input from view to model as necessary - model changes its state and notifies view

Prototype Pattern

●Creational pattern that should be used when the type of objects to create is determined by a 'prototypical instance', which is cloned to produce new objects ●Avoids sub-classes of an object creator in the clien application (like abstract factory does) ●Biggest reason for using it (in Tom's opinion) - it avoids inherent cost of creating a new object in the standard way (via new) in cases where producing initial values for the fields of the object is costly ●Use when ● Prototype Pattern when a system should be independent of how its products are created, composed, and represented ● Classes to be instantiated are specified at runtime ● Avoiding the creation of a factory hierarchy is needed/desired (hierarchy can lead to explosion of classes) ● It is more convenient to copy an existing instance than to create a new one.

Mediator Pattern

●Define an object that encapsulates how a set of objects interact ●Promotes loose coupling by keeping objects from referring to each other explicitly ●Lets you vary their interaction independently ●Considered behavioral because it defines simplified communication between classes (communication is done via methods which constitute behavior) ●The mediator pattern is used to take the role of a hub or router and facilitates the communication between many classes. ●A similarity can be made with database systems. The mediator transforms a hard to implement relation of many to many, where each call has to communicate with other classes - into 2 relations: many to one and one to many, where the communication is handled by the mediator class.

Template Pattern

●Defines the skeleton of an algorithm in a method, deferring some steps to subclasses ●Lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure ●Note the method itself is typically declared final so that it cannot be modified by subclasses ●This pattern may be the most common pattern used! *Can add hooks that you can use later for extraneous methods you need to add.

Dependency Injection

●Do not instantiate the dependencies explicitly in your class. ●Instead, declaratively express dependencies in your class definition. ●Use a Builder object to obtain valid instances of your object's dependencies and pass them to your object during the object's creation and/or initialization. ●Typically, you express dependencies on interfaces instead of concrete classes. This enables easy replacement of the dependency concrete implementation without modifying your classes' source code.

Chain of Responsibility Pattern

●Utilizes the Single Responsibility Principle of OO ●Can have a linked list feel to it, where one object in the chain has a reference to another object in the chain. ●The chain can even be represented in tree form, when commands can take a variety of 'directions', thus a 'tree of responsibility' ●More than one object can handle a command ●The handler is not known in advance ●The handler should be determined automatically ●It's wished that the request is addressed to a group of objects without explicitly specifying its receiver ●The group of objects that may handle the command must be specified in a dynamic way ●The pattern is easily broken if programmer forgets to call the next handler in the chain - happens most often when adding a new handler to the chain ●If request object is not designed properly, handlers in the chain may have more work to do or difficulty doing what they need to do ●Requests may go unhandled if implementation in concrete handler is incorrect (logic errors) ●Careful thought must be placed into how to decide to handle each request within each handler