Developing solid applications

Developing SOLID Applications by Brandon Savage

Table of Contents
The practice of object oriented design ....................................................................................... 3
So, what is SOLID? .................................................................................................................... 5
Why does this matter, anyway? ................................................................................................. 6
S - The Single Responsibility Principle ....................................................................................... 8
The definition of a “responsibility” .......................................................................................................9
One class, one job. .............................................................................................................................. 12
An example from PHP core.................................................................................................................. 12

O – The Open/Closed Principle .................................................................................................16
The polymorphic open/closed principle .............................................................................................. 17
Interfaces in PHP ................................................................................................................................ 18
An interface example .......................................................................................................................... 19

L - Liskov substitution principle ................................................................................................20
Effective code comments .................................................................................................................... 21
Type hints and PHP ............................................................................................................................. 22

I – Interface Segregation .........................................................................................................23
Too many methods.............................................................................................................................. 24

1


Unnecessary methods in an interface ................................................................................................. 25

D – Dependency Inversion ........................................................................................................26
Dependency injection made easy ........................................................................................................ 27
If I’m supposed to inject dependencies, where do I instantiate objects? ............................................ 28
The model – where dependencies are injected ....................................................................................... 28
The controller – where we create objects .............................................................................................. 29
The view – display logic only! .............................................................................................................. 30
Dependency injection makes unit testing possible .............................................................................. 30

2


The practice of object
oriented design
In the very beginning of software development,
programming langauges were simple: developers wrote in
languages like Assembly, and then moved onto more
advanced (for the time) languages like C. There was no
such thing as “object oriented development”, nor was
there really a need in the early seventies.
But as programming became more complex, the memory
in computers became larger and the need to express ideas
developed further, the concept of object oriented
programming was born.
Design Patterns was written in 1994, and is by far one of
the most famous object oriented design books in the

The “Gang of Four” was made up of

modern era. More than half a million copies have been

Erich Gamma, Richard Helm, Ralph

sold: a testament to the overwhelming interest by

Johnson and John Vlissides.

programmers in the object oriented development world.
3

Of course, object oriented programming is widespread

If you don’t have “Design Patterns:

today; in fact, unless you’re still writing in low-level

Elements of Reusable Object-Oriented

languages like C and Assembly, object oriented

Software”, pick up a copy now.

development is probably going to be the stuff you do on a

Really, go here now:

regular basis.

http://amzn.to/13UeZem. I’ll wait.

The problem is that object oriented programming is hard.
It’s not hard from a syntax point of view, but from a
theoretical point of view. To complicate matters, many of
us in the PHP world don’t have the “formal” background in
computer science that other developers do; this makes
concepts in object oriented development even harder to
grasp and understand.
But there’s hope: object oriented programming is
something that can be learned, can be taught, and can be
understood even without a classical computer science
education.
This guide focuses on one aspect of the object oriented
development world: a practice known as SOLID. While
4

there are dozens of concepts, acronyms and behaviors in
the object oriented programming world, understanding
and working with SOLID will help you be a better
programmer, and equip you to work within the modern
object oriented development world.

So, what is SOLID?
Great question! Let’s define what SOLID stands for. SOLID
is an acronym that comprises five basic, core principles in
object oriented development:
• The Single Responsibility Principle, which states
that classes and objects should have only one job.
• The Open/Closed Principle, which states that

These formal definitions really suck.

objects should be open to extension, but closed to

But don’t worry: I’ll explain what each

modification.

of these means (and how you can use

• The Liskov Substitution Principle, which states

them to your advantage) shortly.

that objects of the same type should be
interchangeable.
5

• The Interface Segregation Principle, which states
that small, compact interfaces are preferable to
large, God objects.
• The Dependency Inversion Principle, which
states that applications should depend upon
abstractions, not concrete instances of an object.
Many of these principles relate and interact with one
another. What this means for the developer is that as they
grasp certain principles others become easier to
understand as well; also, it means that employing a few of
the principles will make it easier to implement all the
principles later on.

Why does this matter,
anyway?
A lot of times it can seem easier to avoid object oriented
programming, focusing instead on functional programming
6

or just writing classes that do what we need them to do.
But there are several advantages to SOLID development
practices:
• Code is reusable. Reusing code makes it easier to
move on to new projects, especially if you are
careful in how you design your libraries.
• SOLID code is easier to maintain. Because the code
is in pieces and you’ve implemented the strategies
here, you don’t have to have full domain knowledge
to make small improvements in parts of the code
you’re unfamiliar with.
• Object oriented code is easier to test. And the SOLID
principles make testing easy to accomplish through

Did I mention that most employers

the possibility of using mock objects, etc. More on

these days want their employees to

this later.

understand and use SOLID?

• Most frameworks are object oriented in PHP. You’ll
need a good understanding of OO in order to work

That’s right. And when I learned

with them.

object oriented programming it
earned me a $12,000 raise. These

Whatever your reason for developing object oriented

skills are valuable!
7

applications, using the principles in the SOLID arsenal will
improve your code, and strengthen the resulting
applications that you develop.
Let’s dive right in…

S - The Single Responsibility
Principle

Every class should have a single
responsibility, and that
responsibility should be entirely

The first principle in SOLID is the Single Responsibility

encapsulated by that class. All its

Principle. This principle states that each concrete object

services should be narrowly aligned

should have one job, and only one job. Objects with more

with that responsibility.

than one job are discouraged, and should be abstracted.
This seemingly simple principle creates confusion for
many developers, because they overanalyze what
constitutes a job. For example, is validation of inputs a
separate job from assigning those inputs? Let’s take a
look.
8


The definition of a “responsibility”
A responsibility is nothing more than a discrete behavior
or group of behaviors that cannot be separated. For
example, validating data before assigning it in an object is
a single responsibility. A group of validation functions in
the same object are not different responsibilities because
they cannot stand alone.
In contrast, connecting to a database is a different
responsibility from using data that comes out of a
database. This is where many developers struggle: they’ll
include their connection code in the object, when really it
belongs elsewhere.

The Single Responsibility Principle is
really all about abstraction.
Abstraction is the process by which
data and programs are defined with a
representation similar in form to its
meaning (semantics), while hiding
away the implementation details.
Abstraction tries to reduce and factor
out details so that the programmer
can focus on a few concepts at a
time.

9

For example, let’s review the following code snippet:
<?php
class PostTweet
{
protected function connect()
{
return mysql_connect(‘localhost’,
‘user’, ‘pass’);
}
public function postTweet($tweet)
{
$conn = $this->connect();
return $this->processTweet($tweet,
$conn);
}
/...
}

This object has two jobs: (1)
connecting to a database, and (2)
posting a tweet on Twitter.

In this example, we’re doing two jobs in the same object:
connecting to the database, and posting a tweet.
It therefore becomes impossible for us to effectively test
this code, since we can’t effectively mock the database
connection.

10

In addition, if we ever switch databases we’ll have to
come in here and change everything. An abstraction
would allow us to do this more easily.
If we correctly abstract this code in accordance with the
single responsibility principle, it ends up looking like this:
<?php
class PostTweet
{
protected function getConnection()
{
return DatabaseLayer::getConnection();
}
public function postTweet($tweet)
{
$conn = $this->getConnection();
return $this->processTweet($tweet,
$conn);
}
/...
}

This object now has one job: posting
a tweet on Twitter. The connection to
the database is handled elsewhere by
another object.

With the database connection abstracted to another
object, we are more able to test this object, and abstract
different database types (and this could be further
11

improved with dependency injection, which we’ll discuss
later).

One class, one job.
Each object that you create should have a single
responsibility or a single job. When developing your
classes, carefully consider whether or not their
responsibilities are in line with the single responsibility
principle.
In doing this, it’s also important not to over-abstract your
code. Remembering that a “job” is something that is
discrete, stands alone and might be reused elsewhere in
your application will help you understand the difference
between a reasonable abstraction for reuse and an
unreasonably complicated abstraction.

A single responsibility stands alone
and may have reuse potential in your
code.

An example from PHP core

12

The PDO extension is a great representation of the single
responsibility principle at work. Let’s take a look at the
interface of this class:
PDO {
public __construct ( string $dsn [, string
$username [, string $password [, array
$driver_options ]]] )
public bool beginTransaction ( void )
public bool commit ( void )
public mixed errorCode ( void )
public array errorInfo ( void )
public int exec ( string $statement )
public mixed getAttribute ( int $attribute )
public static array getAvailableDrivers ( void )
public bool inTransaction ( void )
public string lastInsertId ([ string $name = NULL
] )
public PDOStatement prepare ( string $statement
[, array $driver_options = array() ] )
public PDOStatement query ( string $statement )
public string quote ( string $string [, int
$parameter_type = PDO::PARAM_STR ] )
public bool rollBack ( void )
public bool setAttribute ( int $attribute , mixed
$value )
}

This documentation si straight from
the online PHP manual; it’s pseudo
code.

This is the interface documentation for the PDO object;
the PDO object is the starting point for PDO connections to
13

a database. In this documentation, se can see that the
PDO object has essentially one job: to connect to the
database and manage that connection.
The PDO object also is responsible for preparing SQL
queries but it is not responsible for executing them.
Instead, it returns a PDOStatement object. The reason the
PDO object is responsible for preparing SQL queries is
because this is a crucial component of the connection
object.
The connection object is responsible
There are also convenience methods for beginning and

for preparing the statement because

managing transactions, as well as a method for executing

it is based on the encoding of the

simple queries.

database.

The PDOStatement object is chiefly responsible for

Also, transaction management

managing the query process for individual queries to the

happens at the connection level, not

database, including returning a result to the application:

the query level (since multiple queries
can take place inside a single

PDOStatement implements Traversable {

transaction).

/* Properties */
14

readonly string $queryString;
/* Methods */
public bool bindColumn ( mixed $column ,
mixed &$param [, int $type [, int $maxlen [,
mixed $driverdata ]]] )
public bool bindParam ( mixed $parameter ,
mixed &$variable [, int $data_type =
PDO::PARAM_STR [, int $length [, mixed
$driver_options ]]] )
public bool bindValue ( mixed $parameter ,
mixed $value [, int $data_type = PDO::PARAM_STR ]
)
public bool closeCursor ( void )
public int columnCount ( void )
public void debugDumpParams ( void )
public string errorCode ( void )
public array errorInfo ( void )
public bool execute ([ array
$input_parameters ] )
public mixed fetch ([ int $fetch_style [, int
$cursor_orientation = PDO::FETCH_ORI_NEXT [, int
$cursor_offset = 0 ]]] )
public array fetchAll ([ int $fetch_style [,
mixed $fetch_argument [, array $ctor_args =
array() ]]] )
public string fetchColumn ([ int
$column_number = 0 ] )
public mixed fetchObject ([ string
$class_name = "stdClass" [, array $ctor_args ]] )
public mixed getAttribute ( int $attribute )
public array getColumnMeta ( int $column )
15

public bool nextRowset ( void )
public int rowCount ( void )
public bool setAttribute ( int $attribute ,
mixed $value )
public bool setFetchMode ( int $mode )
}
It’s easy to see here the division of responsibility between
the PDO object and the PDOStatement object. They have
very different responsibilities, and yet they work together
to provide a seamless and comprehensive access point to
the database.

O – The Open/Closed
Principle
Many develoeprs have an inherent understanding of the
single responsibility principle: after all, they use it every
time they write discrete functions. In fact, single

Objects should be open for extension
but closed for modification.

responsibility is probably the easiest of the five concepts
to grasp.

16

And then, we get to the Open/Closed Principle and
developers go “huh?” and wander off, never to be seen
again.
Let’s keep that from happening here, shall we?

The polymorphic open/closed principle
One of the methodologies for the open/closed principle is
the polymorphic open/closed principle.
Polymorphism is a big long word for a very simple
concept: same behavior, different methodologies. For
example, take spiders: they all look different and they
may catch prey in different ways, but they all act in very
similar manners. They are polymorphic.

In nature, polymorphism means the
natural occurrence of a thing in
different forms.
In computer science, it means that an
object works in different ways, but
implements a common interface or
behavior.

What does this mean for object oriented programming in
PHP? It means making use of solidified and defined
interfaces for creating objects where those objects have

17

similar behaviors but different internals.

Interfaces in PHP
PHP natively supports the creation of interfaces. These
items provide a public API for use by the classes that
implement them and are of the type that is defined by the
interface (e.g. an interface of type MyInterface will
provide that same type to all objects that implement it).
PHP’s interface methodology is perhaps the most

PHP has a ton of documentation on
interfaces at http://bit.ly/4nYL7n

misunderstood bit in the PHP object model. Interfaces are
seen as not useful because they can’t contain any code; in
fact, they are not useless, they are most useful for this
reason.
An interface provides a shell, a framework of sorts for an
object. The internals are entirely available for
implementation based on your specific needs or desires.
The interface gives the developer maximum flexibility in
developing an object while still having a standard interface

18

that can be used in other objects, allowing developers the
best of both worlds.

An interface example
Below is an example of an interface that might be defined
for a caching library:
<?php
interface CachingI {

Wondering about the difference

public function get($key);

between interfaces and abstract

public function set($key, $value);

classes?

public function delete($key);
// Purge the whole cache
public function purge();
}
Note that this interface allows the developer to implement
a whole host of different cache types, from a Memcache
cache to an APC cache. But because the interface is
consistent, the objects that implement this interface are

An interface defines none of the
internals; it provides a public API
only.
An abstract class provides a public
interface and defines some of the
internals of an object.

19

effectively interchangeable in the application.

L - Liskov substitution
principle

The Liskov substitution principle
states that objects in a program
should be replaceable with instances

Interfaces allow us to create objects that are polymorphic

of their subtypes without altering the

because we can implement the same inputs for all the

correctness of that program.

objects of a particular type. But what about outputs?
E.g. if A is a type of D, then A can
Our outputs are not controlled, and in fact in PHP there is

replace instances of D.

no standard way to say “you’ll get this kind of output from
this method” and enforce that in code.
That’s why the Liskov substitution principle is important.
It states that we should be able to swap objects of the
same type without altering the correctness of the
program. This means the outputs must be as predictable
as the inputs.

20

In PHP, this means two things: effective code comments,
combined with type hints that tell us what objects to
expect.

Effective code comments
It’s generally become accepted in the PHP world to
comment methods and functions with both expected input
parameters and expected output parameters. It is crucial
that to employ this principle, developers use this
technique (which is often interpreted by IDEs and other
code documentation components).

This is a crucial part of design by
contract, which states that
developers should establish
expectations for their objects through
specific interfaces.

The most effective way is with the docblock style
comment:
/**
* Get a random element from an array based on
* weighted array values.
* @param array $array array of val => weight
*
pairings
* @param int $sum total of added weightings
* @return bool value of randomly selected
* element
*/

PEAR has a great set of coding
standards for this. Check them out at
http://bit.ly/c7vAEO

21

By documenting in this way, the expected inputs and the
expected outputs are established beforehand, avoiding
confusion.

Type hints and PHP
The second way we can enforce this principle is by using
type hints which indicate to developers which objects a
program expects (and also forces developers to use these
objects).
Type hints in PHP allow us to anticipate the API, and when
used in conjunction with comments like the ones

The PHP manual has tons of
documentation on how type hinting
works, including on how to type hint
arrays; check it out at
http://bit.ly/a4uQ0N

described above, give us the opportunity to fully honor the
Liskov substitution principle.
Type hinting in PHP is easy. For example:
function myFunction(myObject $object) {
// …
}

In PHP 5.4, you can use the “callable”

The myObject type hint tells PHP that an object of type

implementing __invoke() are

type hint to specify that objects
provided, regardless of specific type.
22

myObject must be passed into this function definition. If
this is not provided, PHP will raise a fatal error until the
developer corrects the problem.

I – Interface Segregation
When first approaching object oriented programming, its
common for developers to start thinking about objects as

The interface segregation principle

groups of functions, and grouping similar functions

states that no object should be forced

together (or grouping all their functions together in a

to depend upon or implement

single class).

methods that it doesn’t use.

These large, “god” objects make refactoring and testing a

This principle exists to make

nightmare. This is why there exists a principle of

refactoring easier.

“interface segregation”, which specifies that interfaces
should be as small as necessary and that objects shouldn’t
rely on methods they don’t use or need.

23


Too many methods
Too often, developers use too many methods when they
are developing their applications. A good rule of thumb is
that more than five to seven methods indicates a refactor
is necessary.

Rule of thumb: more than 5-7
methods indicates a refactor.

This isn’t always true, but many times it is. Having more
than five to seven public methods means that your object
has a lot of responsibility; it is probably an object that has
more than one job, and that is something that violates the
Single Responsibility Principle, too.
Just because you refactor a single object into a few
smaller objects doesn’t mean they can’t work together or
communicate; they can in fact form a library, and you can
have a mediator object that handles the interfaces
between them.

24


Unnecessary methods in an interface
Another common mistake that I see pretty frequently is
the inclusion of unnecessary methods in an object
interface.
What this means is that developers will include methods

Rule of thumb: if you’re defining
empty methods in a concrete class to
satisfy an interface, refactor.

that apply to some objects, but not all objects of the same
type. And then, because the methods are defined in the
interface, they must also be defined in the concrete
object, but are left blank or empty.
PHP allows the implementation of multiple interfaces in a
single object, so it’s still possible to require all the
methods you need but allow objects that don’t need them
to not implement them.
For example:

25

class myClass implements myInterfaceA,
myInterfaceB {
// ...
}
PHP will automatically require that all the methods in
myInterfaceA and myInterfaceB are included and defined.
Meanwhile, you can drop myInterfaceB for objects that
don’t require that specific type.
Another possible solution to this issue is to include traits.
Traits do not change the type of the object (so you cannot
type hint on a trait), but they do provide additional
methods (and those methods can be defined. For more,
see the documentation on traits (available in PHP 5.4)
here.

D – Dependency Inversion
It seems the inventors of SOLID saved the hardest
principle for last. The concept of dependency inversion has
been frustrating developers ever since it was coined (and
26

probably before they had a way to describe it).
Objects should depend upon
There are many different ways to practice dependency

abstractions, not concrete methods.

inversion. Two methods have risen to the top of that pack,
and of those we will discuss the one that applies best to

Which is a really complicated way of

PHP development: dependency injection.

saying “don’t type hint for concrete
objects; type hint for abstractions or

Dependency injection made easy

interfaces.”

Dependency injection is not as hard as the name makes it
sound, or as many blog posts do too. Dependency
injection is something that every developer is already
familiar with, in fact: we do it all the time with function
definitions.
Every argument that is passed into a function is a
dependency. But in the context of object oriented
development and software design, dependencies are other
objects that our object expects and relies upon.

27

When we type hint, we are expecting that a dependency
will be injected into the method or object we’re using. This
object will be acted upon. The type hint guarantees us

Don’t need a specific concrete object?

that the API will be consistent, and allows us to rely upon

Type hint on the interface or abstract

an abstraction of the object.

class.

If I’m supposed to inject dependencies,
where do I instantiate objects?
Many developers struggle with object oriented design in
PHP because we have to create objects somewhere. When
using dependency injection, there’s a fairly common
structure for applications: model, view, controller or MVC.

Most modern frameworks in PHP are
model-view-controller in some way or

The m odel – where dependencies are

another.

injected
Many developers link models with a single table and leave
it at that. But models are far more complex.

28

Models encapsulate the business logic of your application.
They interface with the data storage layer, validate inputs,
handle the creation of new objects and new data, and
return data to the controller (which is ultimately returned
to the view).
Because the business and validation logic lives in the
model, this is where dependency injection really shines.
Objects (other than value objects which represent specific

The model is for business logic.

components of the application) should never be
instantiated here. They should be injected as
dependencies.

The controller – where we create objects
Controllers are usually where people think they should put
their business logic, but controllers should actually be very
small and control only the flow of a program based on

The controller is for control and

predetermined inputs.

program flow logic.

The controller is a great place to instantiate objects.
29

Because instantiating objects here makes this layer
difficult (if not impossible) to test, we focus on putting as
little code as possible in the controller.
Well designed controllers will closely resemble the unit
tests, because they will contain only the code minimally
necessary to interface with the model and view layers.

The view – display logic only!
There should be no validation, business or control logic in
the view. The view is for display only. No object

The view is for display logic. No

instantiation, no manipulation of data (beyond

phone number formatting in the

manipulating it for display purposes). The view is pretty

model – that goes here!

much static.

Dependency injection makes unit testing
possible
With dependency injection, it’s possible to create mock
30

objects (either with a library or by hand) and write true
unit tests on your model units. Without dependency

Not writing tests? You’re missing out

injection, this becomes much more difficult (if not

on an easy way to validate your work!

impossible). Instead, you resort to functional tests.

Write a test today.

Unit tests are a crucial part of object oriented
development. For more details on how you can write
testable applications, see The Grumpy Programmer’s
Guide To Building Testable Applications; for more on using Get both of these great books for $40
PHPUnit see The Grumpy Programmer's PHPUnit

by visiting http://bit.ly/1biePCT (and

Cookbook.

I highyl recommend them!)

31

Want to learn more?
Write better object oriented PHP today!
Object oriented programming always leaves you with a headache.
What if you could master it instead? Stop struggling with object
oriented PHP. Mastering Object Oriented PHP is the answer!
Use coupon code SOLIDGUIDE to get 10% off now!
Visit http://masteringobjectorientedphp.com/ today!

Take your career to the next level!
A unique, two week class that will take your object oriented skills from mediocre to master.
Hands on instruction that will give you not only the theoretical parts of OO PHP, but the
practical applications as well!
NOW ACCEPTING APPLICATIONS for September 2013. Apply now at
http://www.objectorientedphpmasterclass.com

Developing solid applications

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Developing solid applications (20)

Recently uploaded (20)

Developing solid applications