The SOLID Principles of OO Design and Object Calisthenics

Chances are, if you are using test driven development, or regularly dabble with OOP design, you have implemented one or more of the SOLID principles, possibly without even knowing it. The SOLID principles are by no means a new concept, but it’s gaining traction within the PHP community. If you have a look at the Zend Framework v2.0 or Symfony 2 projects, you will see many of the principles applied.

The SOLID principles are:

  • S – Single Responsibility Principle
  • O – Open/Closed Principle
  • L – Liskov Substitution Principle
  • I – Interface Segregation Principle
  • D – Dependency Inversion Principle

I’ve found a strong correlation between the SOLID principles and a practice called Object Calisthenics, an idea from Jeff Bay detailed in the book, The ThoughtWorks Anthology. Some of the rules in Object Calisthenics compliment the SOLID principles very well, I will refer to the rules when this is the case. In short, without going in too much detail, here are the 9 rules of Object Calisthenics:

  1. Use only one level of indentation per method
  2. Don’t use the else keyword
  3. Wrap all primitives and strings
  4. Use only one dot per line
  5. Don’t abbreviate
  6. Keep all entities small
  7. Don’t use any classes with more than two instance variables
  8. Use first-class collections
  9. Don’t use any getters/setters/properties

The SOLID principles focus on Dependency Management. I’m sure as developers, we’ve all been victims of projects with poor dependency management – changing code in one part of the system breaks code in another part; Re-using code is difficult or impossible; Classes and methods are huge and often it’s hard to tell what they’re supposed to be doing. The SOLID principles are ways to reduce the likelihood of this of happening. Unlike design patterns which guide you to a solution, the SOLID principles can be used as a guide to prevent problems.

In this article, I will cover the first of the SOLID principles, the Single Responsibility Principle – “A class should have one, and only one, reason to change”. This is basically the same as “cohesion”, or writing classes with “high cohesion”. So, why is this important? If a class has more than one responsibility, there is more than one reason for it to change. This leads to very volatile classes which of course could affect any other classes that depend on it. See also Object Calisthenics, rules 6 and 7.

It is often easy to spot classes that fail this principle as they often contain words like “Manager”, or “Handler”. When implementing SRP, classes become more specific and focussed and the class names reflect the single responsibility of the class, e.g. EmployeePayrolCalculator.

So how do you go about refactoring your code to implement this principle? Begin by implementing the principle in your methods – refactor your methods to 5-7 lines, one block of indentation and a single responsibility per method (see rule 1 and 2 of Object Calisthenics). Once you have refactored your methods, ask yourself how many reasons does your class have to change? If the database schema changes, does it affect your class? And if the business rules change? How about a user interface change? If you establish more than one reason for change, refactor the class into two or more classes until you are happy that all your classes only have one responsibility.

In the next article – The Open Closed Principle.

ZendCon 2011 – Introducing Zend Developer Cloud, Zend Studio 9 and Zend Framework 2

ZendCon kicked off on 17 October in Santa Clara, California. The surprise of the conference was the announcement of the launch of Zend Developer Cloud during Zend’s CEO Andi Gutmans’ opening keynote speech.

Zend Developer Cloud is a free, cloud based environment for developing and deploying PHP applications. It has tools to quickly set up PHP application stacks, including Zend Framework, Joomla, Drupal and WordPress. It includes a code tracing tool and debugging features. Once the application is ready, it can be deployed to any cloud provider supporting the “Zend Application Fabric”, including Amazon and Rackspace. Zend Developer Cloud also supports the ability to take snapshots of instances at any given time that can be shared with other developers. This could be useful for developer collaboration. It is currently available as a “technology preview release”, you can request an early access key here.

The keynote also featured a live demonstration and one of the tools featured during the demonstration was the new Zend Studio 9 beta. It features tight integration with the Zend Developer Cloud, allowing developers to deploy to the cloud instances from within the IDE. Other noteworthy features include Git and Github support build into the IDE which should make a lot of developers very happy. Emphasis was also placed on how the new IDE can be configured to only include modules that developers need, cutting down a lot of the bulk that is a common complaint with Eclipse IDEs.

During the week before the conference, the beta 1 release of Zend Framework was announced. ZendCon 2011 had several talks detailing the internal workings of the new framework. One of the major changes includes extensive use of dependency injection throughout to make it truly extensible. Most of the framework was rewritten to ensure consistency throughout and to harness the full capabilities of PHP 5.3. The architecture was also simplified greatly by introducing event driven programming to the framework. To find out more about ZF2, have a look at the community wiki. Take note that the API will change while still in Beta.

Python VS PHP

Aah, the old programming language debate, much akin to comparing religions or political parties – bound to end up in a fist fight. Some will argue that as long as you choose the right tool for the job, it doesn’t matter, but I’ve found it’s always the little things that break the camel’s (or in this case, the programmer’s) back.

I wrote a little Python pet project (mind the pun) this week after years of web development using only PHP. As a matter of fact, my first job was a Python position. Eventually, as I started doing GUI development in Delphi, Python was relegated to odd jobs and hacks. When I started doing PHP development, Python became redundant and eventually my skills became rusty as old nails. Until now.

Even after just one week using Python, I remember why I’ll always prefer it – it empowers me as a programmer. In the Python community, they refer to it as the “batteries included” philosophy – with the mere inclusion of a library, anything becomes possible. Combine that with clean and readable syntax, fluent interfaces, powerful list comprehensions, list slicing, an interactive console, and too many other features to mention, it’s clear to see why.

I’ll illustrate using a Python example (Yes, it’s a bad example):

date = details[1].split("<td>")[1].split("</td>")[0].strip()

This line takes the second element of a list (the Python equivalent of an array) and parses a date string out of an HTML table cell. Whether or not it is advisable to do this is a topic for another day, but it illustrates quite handily how the combination of “everything is an object”, great list operators and string functions makes a hack like this effortless. Here is the equivalent PHP code:

$parts = explode('<td>', $details[1]);
$otherParts = explode('</td>', $parts[1]);
$date = trim($otherParts[0]);

If you’re a PHP developer and haven’t worked with Python before, do yourself a big favour and head over to the Python tutorial or check out any of the multitude of hacks, projects and frameworks written in Python and see how it’s the little things that make programming enjoyable.