Plasticx Blog

OO Basics

Abstraction

Using a generalization to define behavior that concrete classes must implement. Given the level of inheritance a specific behavior is exhibited.

Encapsulation

Hiding the internal details of a class which places outside dependency on its defined interface.

Polymorphism

Treating derived classes as if they are the parent object. Objects of different types can respond to the base interface.

Inheritance

Form new classes using classes that are already defined. Derived classes take over (inherit) attributes or behavior of the parent.

OO Principles

Encapsulate what varies – identify aspects of a application that vary and separate them from stays the same.

Program to an interface and not an implementation

Favor composition over inheritance

Strive for loosely coupled designs between objects that interact

Open/Closed principle – classes should be open for extension but closed for modification.

Dependency inversion principle – depend on abstractions, do not depend on concrete implementations.

Principle of least knowledge (law of Demeter) – talk only to your immediate friends. A class should only work on itself and its object attributes. Coupling a class to objects past these attributes increases the complexity and fragility of a design.

Hollywood principle – don’t call us, we’ll call you. Prevent dependency rot by only allowing a high-level component call low level components. Observer and Template Method patterns exhibit this principle.

Single responsibility principle – a class should have only one reason to change (i.e. one class does one thing). A class has high cohesion if its functions are closely related, and has low cohesion if it is designed around a set of not related functions.

Design Patterns

A design pattern is a solution to a problem in a context.

Context – situation in which the pattern applies, it should be recurring

Problem – the goal, and any constraints getting to the goal

Solution – an applied design that can resolve the goal within its constraints.

Forces in a problem are its goal and its constraints.

Strategy Pattern

Define a family of algorithms, encapsulate each one, and make them interchangeable. Let the algorithm vary independently from the clients that use it.

Observer Pattern

Defines a one to many relationship between a subject class and the objects that observe it. When the subject changes it notifies the observers. If the subject includes its state in the notification that is considered the push version of the pattern. Normally pull is the preferred implementation of the pattern where the observers choose to query the subject for state after being notified of a change.

Decorator Pattern

Attaches additional responsibility to an object dynamically. Provides a flexible alternative to inheritance for extending functionality.

Factory Method Pattern

Define an interface for creating an object but lets a class defer instantiation to subclasses. Applies dependency inversion principle. The base factory has concrete methods that work on an abstract product. Factory method is an abstract method and provides an interface for creating one product.

Abstract Factory Pattern

Provides an interface for creating families of related or dependant objects without specifying their concrete classes. The interface can have many different create methods. Methods of an abstract factory are often factory methods. Concrete factory methods return concrete products.

Singleton Pattern

Ensures a class has only one instance and provides a global point of access to it.

Command Pattern

Encapsulates a request as an object thereby letting you parameterize other objects with different requests, queue or log requests, and support undo operations. Invoker holds reference to command. Command interface has execute method. Receiver is the object that receives the command. Decouples invoker and receiver.

Null Object Pattern

An empty object that implements an expected interface but does no action and contains no attributes. Used to minimize null checks and exception handling in code. Is often a helper used within other patterns.

Adapter Pattern

Converts the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Client expects a certain interface, adapter provides that interface. Adapter maintains a reference to adaptee.

Facade Pattern

Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use. Simplifies and unifies a set of more complex classes that comprise a subsystem.

Template Method Pattern

Defines the skeleton of an algorithm in a method deferring some steps to subclasses. Template method lets classes redefine certain steps of an algorithm without changing the algorithm’s structure.

Iterator Pattern

Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Traversal task is placed on the iterator, other management in the aggregate is left there (one class does one thing).

Composite Pattern

Compose objects into a tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Components – master class, composite – nodes, leafs.

State Pattern

Allows an object to alter its behavior when its internal state changes. The object (state) will appear to change its class. A context interface is given to a client. When context methods are called the state of the context changes. The state class of the context is what appears to have changed itself.

Proxy Pattern

Provide a surrogate or placeholder for another object to control access to it. Need for control might be for security, remote or abstracted access to the true object, or full instantiating of the true object is expensive, etc.

Compound Patterns

Combine two or more patterns into a solution that solves a recurring or general problem.

Model, View, Controller (MVC) compound pattern

Model is encapsulated by the observer pattern. Model is the subject and objects in the view observe the model (and its changes in state). Adapter can also be used to wrap a previously implemented model into the new MVC design. Controller is encapsulated by the strategy pattern encompassing a set of related functions to operate on the model. Controller does the work of changing the model’s state given input from the view. View is encapsulated by the composite pattern

Model 2 (Java web MVC) compound pattern

A Java specific MVC applied to the web. The view portion of Model 2 is a web browser. The web browser doesn’t register with the model in the basic observer pattern but it is notified of changes in the model’s state indirectly by the HTML it is given to render. Also, the controller passes a bean object to the Servlet/JSP that represents the state of the model instead of the model itself.

Other GoF Patterns

Gang of Four (GoF) patterns not covered in detail:
Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Memento, Prototype, Visitor

Design Patterns categorized by Creation, Behavior, Structure

Creational Patterns

Abstract Factory, Factory Method, Single

Behavioral Patterns

State, Command, Iterator, Template Method, Strategy

Structural Patterns

Composite, Proxy, Facade, Decorator, Adapter

Design Patterns categorized by Class and Object

Class

Class relationships are defined by inheritance at compile time:

Template Method, Factory Method, Adapter

Object

Relationships are defined by composition (runtime) and are dynamic:

Abstract Factory, Single, State, Command, Iterator, Strategy, Composite, Proxy, Facade, Decorator

Anti-Pattern

An anti-pattern is deriving a bad solution to a problem.

Golden Hammer is an example anti-pattern. It is using known tools to try to solve a new problem that is probably better handled with other tools.