Design Patterns Workshop Brandon Savage

Who am I? •

Former Mozillian; teacher, writer, speaker.

•

Author of Mastering Object Oriented PHP and Practical Design Patterns in PHP.

•

Instrument rated private pilot.

What is a design pattern?

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

That doesn't seem so hard, right?

...general[ly] reusable solution...

...commonly occurring problem...

Design patterns are abstract!

You're probably using design patterns without knowing it.

What is NOT a design pattern?

A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

One pattern can have 1,000 implementations!

Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns are often expressed in diagrams, not code.

Code Sample Warning!!! Code is provided to ILLUSTRATE possible solutions, not to show all possible solutions.

Developing a SOLID understanding

Design patterns often implement OO best practices.

S ingle Responsibility O pen/Closed L iskov substitution I nterface Segregation D ependency injection

SOLID helps us develop good object oriented applications.

Single responsibility

The single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

One class, one job.

Examples of a job • Database connection handling

• Caching

• Object instantiation

• Routing

• Context management

• Data modeling

...entirely encapsulated...

The object should be able to do the job completely.

Open/Closed

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Two kinds of open/ closed principle

Meyer's open/closed principle

Meyer's open/closed principle • Classes, once complete, should not be modified.

• Errors can be fixed, but the API and internals are set

• Inheritance allows for future modifications and extensions

• Subclasses CAN change the interface.

Polymorphic Open/ Closed Principle

Polymorphism is the natural occurrence of a thing in different forms. !

In computer science, this means an object that works in different ways, but implements a common interface and behavior.

Polymorphic Open/ Closed Principle • The INTERFACE defines the object.

• The internals are open for extension, but the interface closed for modification.

• Changing the interface in subclasses changes the object type.

Most developers use the Polymorphic Open/ Closed Principle.

A Caching Interface