Object Calisthenics with PHP (en)
By: Tadeu Barbosa
Tags: Object Calisthenics, Object Oriented, Good Practices, PHP, Programming

Vishnu R Nair @vishnurnair

I want to share in this post my recent studies with PHP, more specifically with Object Calisthenics. It’s nine rules that was created to help us to code better. There’s no secrets with that nine rules, you will see it when you’ll be reading. These rules was introduced by Jeff Bay.

One level of indentation per method.

It means that you don’t must create a class or a method with more than one level of indentation. For example:

Can you see how this code can be confuse for someone else that read it? Of course, maybe that code is not so confuse or complex that codes that we see on the real life. On the past I saw codes that look like “Hadouken”.

If your code looks like this one, there’s something wrong!

An way to start writing something better, is separating your method in an another. The following code is more legible to me.

Don’t use the ELSE keyword.

I love this rule! I don’t know when or where… but some years ago, I heard and I follow this one. It’s something related about functional programming, maybe I write about it after.

We don’t need to ELSEs on our code! If you’re using Object Oriented Programming, it means that you can write codes without any ELSEs. The code gets more clean and readable. On the previous code, for example, if we rewrite removing the first else:

May you can prevent to use a lot of IFs and ELSEs on your code. Two another rules related with this one that is good too is: fail first and early return. It means that you must return your methods soon as possible, even fails.

In case of an throw:

The code gets more legible! Can you see?

Wrap all primitives and strings in classes.

Whenever you can, you may replace primitives and strings of a class to an another. For example, we have a User class with phone number and email properties.

Instead you can do:

First class collections.

The collection classes must be only for an collection and nothing more. If you have a classe to manipulate an collection, then that class can’t have other responsibility.

One dot per line.

I’m writing examples in PHP, but PHP uses arrows and not dots. Then this rule is about how many arrows you can use. Lets do an example.

This rule can be ignored in case of use: Fluent Interfaces. An example:

Don’t abbreviate.

This rule is extraordinary necessary! I saw a lot of code, and write a lot of ones too, that take some minutes to be understood. Did you use: $x, $y, $value, $i, $data, or something related? Maybe if we use something more descriptive, it will take less time to be understood.

Keep all classes less than “50” lines.

Believe it or not I had worked with an Laravel Controller Class, with approximately 4000 lines of code. When I open that one on VScode or PHPStorm, my PC was going mad.

Some people says that fifteen lines is insane, then they prefer to understand this rules as: “Keep all classes less than 100 lines”. What is important here is to take carer with how many lines you’re writing. If your class is taking more than 100 lines, then it is doing more than it must to do. Reread your class or file and separate it in another place.

Methods may take many lines of code too. Sometimes when we are writing some method with an complex logic, it can take many lines. But then when we finally complete what we want, then we must to refactor it, move some lines for an another method, or maybe to an another class.

Sometimes we need to write some codes so fast because of something that the our clients are requesting, or something that our gestor or leader is requesting. We think that we will understood it after, but believe me: We will remember nothing some days after.

No classes with more than two instance variables.

To me, like the last one, this rule can be understood a bit different. May we can use five or six instance variables in our classes. I will share a code that looks like one code that I learn in a course that I did.

No getters or setters.

I sincerely don’t understand this one so clearly. But, the rule is that you should not give access to an class logic. An example is: