phparchitect-2019-08

http://www.phparch.com \ August 2019 \ 31

Education Station

Writing DRY, SOLID FOSS OOP CRUD Code

Let’s say we have a block of code that
prints out the number of legs an animal
has. We can call $animal->getNumLegs()
and get back an integer, and we can
output the string “This animal as %d
legs.” This implementation works for a
large number of animals.

Fish, however, do not have legs but
have fins. If we add a check (Listing 4)
that changes the string to say, “This fish
has %d fins,” we are adding complexity
to our code and breaking this principle.
It’s another reason why many devel-
opers like composition as opposed to
inheritance.

This principle is one of the easiest to
break, as it is sometimes very easy to
add a single flow change to our code.
Breaking this principle makes code
much harder to maintain over time.

Interface Segregation Principle

The Interface Segregation Principle
states that an object should not rely on
methods that do not impact it. If we go
back to our last example of a fish, a fish
has no legs, so why should it have to
implement a getNumLegs() method?

Interfaces and abstract classes should
be broken down into their smallest
parts. ISP suggests it is better to have
multiple, smaller interfaces, than fewer
more generic ones. It allows us to struc-
ture our code better and have smaller,
clearer contracts.

There is a delicate balancing act,
however, as you do not want to end
up with a bunch of tiny single-method
interfaces. By using Test-Driven Devel-
opment and YAGNI/KISS, you can try
and reduce code down to just what is
needed. Use the virtues of WET and
DRY to figure out the commonalities
between interfaces.

Dependency Inversion Principle

Dependency Inversion Principle is
another excellent subject brought up
when discussing composition versus

inheritance. DIP states objects should

rely on abstractions, not on concrete

implementations. This lends credence

that classes (concrete implementations

with business logic) should never rely

on other classes, but instead of inter-

faces.

By focusing dependencies on

more abstract implementations, the

code becomes easier to extend and

more accepting of changes. In our

fish example, we are better served

depending on a hasLegs dependency

versus an actual concrete Fish class. In

the 10,000 foot view, it’s much easier

to ask if something has legs than if

something is a fish. Jellyfish are not fish

but have no legs, so our getNumLegs()

function is broken because of that

dependency on Animal and check for a

Fish class.

Following this principle can be hard,

as ideas like KISS tell us to keep the

amount of code to a minimum. At the

same time, ISP tells us to create inter-

faces for the smallest logic contracts.

This is a critical principle to keep in

mind, though, since it forces us to

consider our dependencies and the

breadth of those dependencies.

So Many Letters

I have thrown a lot of acronyms at

you, and I apologize. Keep in mind that

many of these are things we need to

keep in mind as we design and build out

our applications. They are all important

in their own ways and force us to ask

questions about what we are building.

You don’t need to use all of these all

of the time, but I hope these principles

spark some questions you can ask the

next time you need to write code. Look

at your legacy code and see where you’re

breaking these principles, and see what

you can do to clean the code up.

Keep these all in mind with new code.

I have mentioned it a few times, but

using Test-Driven Development can

help answer these questions and keep

you on track for following these best

practices. Now go out, and build some

SOLID DRY code!

Chris Tankersley is a husband, father, author, speaker,

podcast host, and PHP developer. He works for Nexmo as a

PHP Developer Advocate for their API platform and lives in

Northwest Ohio. Chris has worked with many different

frameworks and languages throughout his twelve years of

programming but spends most of his day working in PHP. He

is the author of Docker for Developers and works with

companies and developers for integrating containers into their

workflows. @dragonmantank

Related Reading

• The Life-Changing Magic of Tidying Your Code by Bryce Embry, May 2018.
  https://phpa.me/embry-tidying-code


• Building Software that Lasts by Susanne Moog, October 2017.
  http://phparch.com/magazine/2017-2/october


• Leveling Up: Building Better Objects by David Stockton, February 2017.
  http://phparch.com/magazine/2017-2/february