http://www.phparch.com \ August 2019 \ 27Education Station
Writing DRY, SOLID FOSS OOP CRUD Code
Chris Tankersley
It seems like programmers love their acronyms almost as much as the military does.
When someone is just getting started in programming, they can be bombarded
with an endless list of acronyms that people throw out as best practices and things
to follow. Too often, this advice comes with little direction on why or what they are.
Why should we follow SOLID principles if someone does not tell us what they are?In a previous refactoring article, I
brought up one of the acronyms—WET,
or Write Everything Twice. It seems
contradictory to another one, DRY, or
Don’t Repeat Yourself. As with every-
thing in programming, when and where
to use a principle depends on what you
and your code are doing.
This month, I want to talk about
some of the more common acronyms
and where they are appropriate. It is not
an exhaustive list, but it is a list of some
of the common best practice ones web
developers come across.OOP
We should start at the beginning
since many of the ideas center around
a specific paradigm of programming—
object-oriented programming. When it
comes to PHP, we generally write code
in two different ways. The first, and
oldest, is to use functions to organize
and implement the business logic for
the code. The second is to group code
in classes and objects.
PHP is interesting in that it is not
a pure object-oriented language. It
borrows much of the object structure
from other languages like Java, in that
PHP has classes, interfaces, traits, and
visibility. These features are only part
of object-oriented programming. PHP
lacks many of the reactive parts of other
object-oriented languages. PHP is still
a very “do this, then this, then that”
language, just with objects.
At its heart, PHP is a procedural,
imperative language, or one that
describes how a program should
operate from start to finish. PHP allowsa developer to declare this using an
object model, which describes how
to structure a class syntactically and
how to use an object. As I mentioned
above, it shares many of the same ideas
as a true object-oriented programing
but executes the code in a very linear
fashion.
For a web developer, object-oriented
programming is the idea of encap-
sulating code into a class and using
constructs such as interfaces, traits, and
abstract classes to help structure code
and define how they interact. Modern
PHP code concentrates around the idea
of OOP since it tends to lead to cleaner,
easier-to-read code.
Throughout this article, I reference
OOP as it pertains to PHP, not neces-
sarily true object-oriented languages
like Smalltalk. If you are interested
more in the object model of PHP, check
out the PHP Manual on Classes and
Objects^1.WET
WET stands for Write Everything
Tw i c e. In my refactoring article, one of
the points I brought up was sometimes
you may not identify an abstraction
until you have written the same code in
a few different places. Once you have a
few copies of functionality sitting in a
codebase, it can become clearer what
abstraction you need.
When we start to sketch out our code,
we may make wrong assumptions about
what our code needs. These can include
what functionality our classes expose,1 Classes and Objects:
https://php.net/language.oop5how we design our interfaces, and even
how we want objects to interact with
each other. Sometimes, preplanning
can be a hindrance.
WET suggests you don’t worry about
abstracting code until you have two
copies of code. When you go to write
the third copy, that is when you need
to refactor. Three copies of code should,
hopefully, make commonalities much
more identifiable.
Let’s pretend we are writing a web
application for a pet store. We need
some way to represent the animals avail-
able. We want to have not only common
attributes about the types of animals,
but we want to display common infor-
mation about the animals.
We sit down and think to ourselves,
“Well, we need to categorize cats, dogs,
birds, fish, rodents, and lizards. Oh, and
turtles. What do those classes look like?”
We are not really worried about biolog-
ical characteristics like the number of
legs, or the sound the animal makes.
We want to focus purely on the business
aspects associated with an animal.
We might end up with a class like the
following:class Animal {
protected $id;
protected $eatingHabits;
protected $cageType;
protected $price;
protected $faqs = [];
}This class is probably not a bad start.
We have some of our requirements right
out of the gate, but is this extendable?
What will the individual child classes
look like? Should we have actually gone