Object Oriented Programming for WordPress Plugin Development

Object oriented programming
for WordPress plugin
development

Mike Toppa
WordCamp NYC
June 9, 2012

www.toppa.com @mtoppa

Mike Toppa
● Director of Development, WebDevStudios
● 17 years of experience in web development,
project management, and team management
● Universities: Georgetown, Stanford, Penn
● Dot coms: E*Trade, Ask Jeeves
● Start-ups: Finexa, Kai's Candy Co
● WordPress development for non-profits


Overview
● Nuts and bolts of classes and objects in PHP
● The single responsibility principle
● The dependency inversion principle
● When to prefer OO to procedural programming


Simple example
class Lamp {
// property declaration
private $maxSafeWatts = 100;

// method declaration
public function getMaxSafeWatts() {
return $this->maxSafeWatts;
}
}
---------------------------------------------------------------

// instantiate and assign
$myLamp = new Lamp();
echo $myLamp->getMaxSafeWatts();

Rule of thumb:
avoid public properties
class Lamp {
public $maxSafeWatts = 100;
}

---------------------------------------------


// dangerous to allow this!
$myLamp->maxSafeWatts = 'a string to wreck your math';

Prefer private properties
class Lamp {

public setMaxSafeWatts($watts) {
if (!is_numeric($watts) || $watts > 125 || $watts < 1) {
throw New Exception('invalid value for watts');
}

$this->maxSafeWatts = $watts;
}
}

-------------------------------------------------------------------

$myLamp->setMaxSafeWatts(75);

Constructors

class Lamp {
private $bulb;

public function __construct($bulb) {
$this->bulb = $bulb;
}
}

---------------------------------------------

$myLamp = new Lamp('3 way');

Type Hinting
class Lamp {
private $bulb;

public function __construct(Bulb $bulb) {
}
}

---------------------------------------------

$myBulb = new Bulb();
$myLamp = new Lamp($bulb);

Organizing your classes


Initializing your OO plugin

// this is the start.php file for a “Lamp” WP plugin...

// require or autoload the “main” class file for your plugin
// and then...

$lamp = new Lamp();
$lamp->run();

// that's it!

Abstract classes and inheritance

Lamp

FloorLamp DeskLamp HangingLamp

Abstract classes and methods
abstract class Lamp {
protected $color;
protected $maxSafeWatts;

public function setColor($color) {
$this->color = $color;
return $this->color;
}

abstract public function setMaxSafeWatts($watts);
}

Implementing abstract classes
class FloorLamp extends Lamp {
public function setMaxSafeWatts($watts) {
/* if numeric and less than 150... */
}
}
------------------------------------------------------------------
class DeskLamp extends Lamp {
public function setMaxSafeWatts($watts) {
/* if numeric and less than 100... */
}
}

Using interfaces: the facade pattern

Functions
A PHP
facade
application
interface

WordPress Drupal Some other
facade facade facade
implementation implementation implementation

Interface Example

interface FunctionsFacade {
public function enqueueStylesheet($handle);
}

------------------------------------------------------------------------

class FunctionsFacadeWp implements FunctionsFacade {
public function enqueueStylesheet($handle) {
return wp_enqueue_style($handle);
}
}

// we'll look at how to actually use the interface in a few minutes...

The SOLID Principles
● Single Responsibility (SRP)
● Open-Closed (OCP)

● Liskov Substitution (LSP)

● Interface Segregation (ISP)

● Dependency Inversion (DIP)


The purpose is to reduce the
complexity and fragility
of a class


But what does it mean to do “one thing”?


Cohesion


Only one reason to change


Classes Example

ShashinDisplayer.php

ShashinAlbumDisplayer.php
ShashinAlbumDisplayerPicasa.php
ShashinAlbumDisplayerTwitpic.php
ShashinAlbumDisplayerFlickr.php

ShashinPhotoDisplayer.php
ShashinPhotoDisplayerPicasa.php
ShashinPhotoDisplayerTwitpic.php
ShashinPhotoDisplayerFlickr.php

Methods Example
class ShashinInstall {

public function run() {
$this->createAlbumTable();
$this->verifyAlbumTable();
$this->createPhotoTable();
$this->verifyPhotoTable();
$this->updateSettings();
return true;
}

// ...
}

Naïve model of a button and lamp
Lamp
Button
+ turnOn()
+ poll()
+ turnOff()

class Button {
private $lamp;

public function __construct(Lamp $lamp) {
$this->lamp = $lamp;
}

public function poll() {
if (/* some condition */) {
$this->lamp->turnOn();
}
} Example from “Agile Software Development”
}

Dependency inversion applied

<<interface>>
Button SwitchableDevice

+ poll() + turnOn()
+ turnOff()

Lamp

This is the Abstract Server pattern

SwitchableDevice and Lamp
interface SwitchableDevice {
public function turnOn();
public function turnOff();
}

--------------------------------------------------------------

class Lamp implements SwitchableDevice {
public function turnOn() {
// code
}

public function turnOff() {
// code
}
}

Button
class Button {
private $switchableDevice;

public function __construct(SwitchableDevice
$switchableDevice) {
$this->switchableDevice = $switchableDevice;
}

$this->switchableDevice->turnOn();
}
}
}

Using the Button

// require or autoload the class files, then...

$lamp = new Lamp();
$buttonForLamp = new Button($lamp);
$buttonforLamp->poll();

$motor = new Motor();
$buttonForMotor = new Button($motor);
$buttonForMotor->poll();

Dependency Chains

If class A depends on class B,
and class B depends on class C,
class A should be blissfully unaware of class C


To do this without going insane,
you need an injection container


A web of collaborating objects
● The SRP and DIP together drive a
“composition” approach to OO design
● From Growing Object Oriented Software,
Guided by Tests:
"An object oriented system is a web of
collaborating objects... The behavior of
the system is an emergent property of
the composition of the objects - the
choice of objects and how they are
connected... Thinking of a system in
terms of its dynamic communication
structure is a significant mental shift from
the static classification that most of us
learn when being introduced to objects."

But don't overdo it:
avoid needless complexity

When to prefer OOP to procedural programming


Object oriented programming
for WordPress plugin
development

Mike Toppa
WordCamp NYC
June 9, 2012


Skill level

Theory and practice

Won't be an expert

We will be looking at code


What I'll cover is not specific to WordPress

When you write a plugin you are writing software

Your software should be organized around its use
cases, it should not be organized around WordPress'
architecture

That is, you should not start with something like a
“plugin” class. Your classes should be organized
around the business problem they are trying to
solved, not around the details of WordPress.

Simple example
class Lamp {
// property declaration

// method declaration
public function getMaxSafeWatts() {
}
}
---------------------------------------------------------------

// instantiate and assign
echo $myLamp->getMaxSafeWatts();

A class consists of properties, and methods which
perform actions, by manipulating those properties

Encapsulation of related methods and properties. This
is what a class really is.

Properties and methods have a visibility (public,
private, or protected)

An object is created by instantiating a class (calling
new). Then you typically, assign it to a variable, and
call its methods as needed

Rule of thumb:
avoid public properties
class Lamp {
public $maxSafeWatts = 100;
}

---------------------------------------------


// dangerous to allow this!
$myLamp->maxSafeWatts = 'a string to wreck your math';

Public properties can be used and abused by external
code at any time.

Prefer private properties
class Lamp {

public setMaxSafeWatts($watts) {
if (!is_numeric($watts) || $watts > 125 || $watts < 1) {
throw New Exception('invalid value for watts');
}

}
}

-------------------------------------------------------------------

$myLamp->setMaxSafeWatts(75);

By requiring them to be set through a method call, you
can control what types of values are valid, and what
ranges are valid.

Constructors

class Lamp {
private $bulb;

public function __construct($bulb) {
}
}

---------------------------------------------

$myLamp = new Lamp('3 way');

The constructor is a special method, used for
initializing a class.

It's optional – is called when you call “new”

A constructor does not return anything

It should be used for getting a class into a valid initial
state

A common design mistake is to put a lot of complex
logic in the constructor, or call it to execute the
object's functionality.

Organizing your classes


One class per file, and the file name should match the
class name
Give the class a meaningful name and its methods
meaningful names
Class names and property names should be nouns or
noun phrases
Method names should be verbs or verb phrases
Get a real IDE that autocompletes variable names and
method names

Abstract classes and methods
abstract class Lamp {
protected $color;
protected $maxSafeWatts;

public function setColor($color) {
$this->color = $color;
return $this->color;
}

abstract public function setMaxSafeWatts($watts);
}

An abstract class cannot be implemented directly

It can also have abstract methods, which must be
implemented by the child class

Protected methods and properties are essentially
private, but can be used by child classes

Interfaces

An electrical outlet is a great example of an interface. It
can power anything designed to plug into it. It doesn't
need to know or care about exactly what it's
connected to.

Interfaces define a set of methods a class must
implement. It's similar to abstract classes in this way,
but there is no inheritance.

Using interfaces: the facade pattern

Functions
A PHP
facade
application
interface

WordPress Drupal Some other
facade facade facade
implementation implementation implementation

A different implementation of the facade would allow
the PHP application to work outside of WordPress,
without touching the application's code

When you write a class to implement an interface, it
can interact with other classes that know how to talk
to that interface, without those other classes having
to know anything about your particular
implementation of the interface

The SOLID Principles
● Single Responsibility (SRP)
● Open-Closed (OCP)

● Liskov Substitution (LSP)

● Interface Segregation (ISP)

● Dependency Inversion (DIP)


Introduced by Bob Martin in his book “Agile Software
Development”

From LosTechies.com

Applied to classes and methods

Do one thing, do it well, do it only

For methods, this typically means changing the value
of only one variable

If you are passing more than 2 or 3 arguments into a
method, you are probably doing more than one thing

For classes, it means having a single conceptual
responsibility

The purpose is to reduce the
complexity and fragility
of a class


We want code that is flexible and easy to understand,
not brittle and mind-numbing to read

When a method is manipulating multiple properties and
invoking lots of other methods, it can be very hard to
test, debug, and change. This is a common reason
why developers feel fear when making a change –
they don't know what might break

When a class has many methods and multiple
responsibilities, it can be hard to understand and
difficult to refactor

Only one reason to change


A typical example is when business logic is entangled
with the user interface. If you want to develop an
RSS feed for a web page, and can't create the feed
without tearing apart or copying-and-pasting code
that's woven into your HTML, then you've got code
that has more than one reason to change.

Classes Example

ShashinDisplayer.php

ShashinAlbumDisplayer.php
ShashinAlbumDisplayerPicasa.php
ShashinAlbumDisplayerTwitpic.php
ShashinAlbumDisplayerFlickr.php

ShashinPhotoDisplayer.php
ShashinPhotoDisplayerPicasa.php
ShashinPhotoDisplayerTwitpic.php
ShashinPhotoDisplayerFlickr.php

You can start to see the power of the OO approach
here

I can add support for a new photos service by creating
a new subclass, instead of having to touch code all
over the place, adding a bunch of “if” statements

From LosTechies.com

It's common to see code that hard-wires together all
the parts, when those connections could be made
more flexible and extensible

Naïve model of a button and lamp
Lamp
Button
+ turnOn()
+ poll()
+ turnOff()

class Button {
private $lamp;

public function __construct(Lamp $lamp) {
$this->lamp = $lamp;
}

$this->lamp->turnOn();
}
} Example from “Agile Software Development”
}

This solution violates the DIP

● Button depends directly on Lamp

● Button is not reusable
● It can't control, for example, a Motor

Dependency inversion applied

<<interface>>
Button SwitchableDevice

+ poll() + turnOn()
+ turnOff()

Lamp

This is the Abstract Server pattern

What it means

Neither Button nor Lamp “own” the interface
Buttons can now control any device that implements
SwitchableDevice
Lamps and other SwitchableDevices can now be
controlled by any object that accepts a
SwitchableDevice

A web of collaborating objects
● The SRP and DIP together drive a
“composition” approach to OO design
● From Growing Object Oriented Software,
Guided by Tests:
"An object oriented system is a web of
collaborating objects... The behavior of
the system is an emergent property of
the composition of the objects - the
choice of objects and how they are
connected... Thinking of a system in
terms of its dynamic communication
structure is a significant mental shift from
the static classification that most of us
learn when being introduced to objects."

Author: Steve Freeman and Nat Pryce

But don't overdo it:
avoid needless complexity

The complexity of having 44 classes in Shashin is
justified by its need for flexibility

You can support a new viewer or a new photo service
simply by creating a new subclass. This is much
more maintainable and extensible than a single huge
file with deeply nested conditionals and unclear
dependencies

But if I knew I would never need that kind of flexibility,
there would be no justification for creating these
layers of abstraction – they would just be needless
complexity

When to prefer OOP to procedural programming


This can be subjective. For me, it hurts my brain to
program procedurally, even for small projects.

For a very small project, OO will usually involve more
code

If you can classify the components of an application
into objects with properties and methods, and you
have an idea of what kind of changes will come in
the future, an OO approach is very powerful.

Also, if you want to do unit testing, you need OO code

Object Oriented Programming for WordPress Plugin Development

More Related Content

What's hot (20)

Similar to Object Oriented Programming for WordPress Plugin Development (20)

More from mtoppa (20)

Recently uploaded (20)

Object Oriented Programming for WordPress Plugin Development