In this new articles series I’ll try to explain, all useful instruments and good practices to develop well structured PHP applications. The main aim is to obtain more stable, clean and maintainable code, giving an improvement to our PHP projects

I am in the “Damn I’m so noob, everything I’ve done is wrong phase” as described in this fun article So you want to be a Web Developer

This article is for all PHP developers that every day have problems with their code design and structure. It’s nice to have minimum familiarity with PHP development, to better understanding of all scenarios that will be shown and getting a better understanding of solutions illustrated here

OOP & Problem solving

The Object Oriented Programming is something old, (so to speak), its first implementation date back to ‘70s. However, today, we’re dealing with a lot of PHP developers that don’t know how to use all potentials of OOP (Object Oriented Programming). There are a lot of potentials and shortly we discover why and how we can implement them in our projects realization

Before coding, there is always problem and scenario analysis process. The biggest stumbling is ever how to organize everything in our scenario

Exactly, the more or less complex problem’s solution is often found in modularization of the problem itself in more simple parts. This approach is defined as Dynamic Programming technique used to decompose complex problems, in others of more easy to understand and to solve.

So coming back to initial point, this is a demonstration of how OOP can make easy several development processes’ implementation. This is because our small modules that have interaction among them, could be represented with OOP Classes

Our Class is an organized collection of datas (properties) and actions (methods) that it (o some other class) can do on properties itself. Usually datas are typed, but in PHP language, we have dynamic typing, so there isn’t difference among data types.

Single Responsibility Principle

That’s quite easy, but how can we structure and design our classes in a good way ?

As we mentioned before, our Classes represent all tiny modules of our complex problem, it will be a good practice how design and define our classes in a smart way. We can find some help in the SOLID principles (on that we’ll talk in a new article), more specifically the Single Responsibility Principle

A class should have only a single responsibility (i.e. only one potential change in the software’s specification should be able to affect the specification of the class)

More easily, we have to define a class that must have one single responsibility, this one must be handled and incapsulated inside the class itself. All Class’ business logic have to refer to the single responsibility that the Class was defined and designed.

This means that the Class, defined according to this simple principle, could have one and only one principle for changing its behaviour and not more than one.

Let’s touch a basic example, to have a better understanding of the concept. We have to build a new mail service, as below we define Email class and as you can see all seems to respect the Single Responsibility Principle. If you keep attention, you can find two different reasons for which Email Class could change.

• Adding new email protocol handling will cause new code modification inside our Class because we need to handle and serialize all extra email’s filed
• Adding new content type (as html) will cause adding extra code for each implemented content type handling

The same example that respect the Single Responsibility Principle introduces the new Class Content, for each class will be so, one single responsibility

• Adding new email protocol handling, will cause changes only in Email Class
• Adding new email content type handling, will cause changes only in Content Class

But, classes are not the unique awesome tool provided by Object Oriented Programming

Interfaces & Abstract Classes

In Object Oriented Programming there are new concepts as Abstract Classes. Abstract Classes cannot be instantiated, but can be extended by other concrete classes (that can be instantiated). Concrete classes inherit from abstract classes the interface and the abstract properties.

Meanwhile, we can define the interface: that is a collection of all signatures of a class. Signature is the description of a class’ function (method), composed by name, parameters and returned type (remember that in PHP we don’t have typing)

So, the interface is a class that contains all unimplemented methods and doesn’t contain properties. An Abstract Class is a standard class that contains at least one unimplemented method (one abstract method)

Let’s see a simple example

The interface definition, by contrast, contains only unimplemented abstract methods. In this way we can define a common behaviour to more classes but that will be implemented in different ways depending to the situation.

Let’s take a step back…

Now, go back at the previous example (with Email service) and let’s see how get a better code, using interfaces

In this way, will be implemented the methods depending on real needs thanks to IEmail interface that describes a common behaviour to all possible implementations

In the next article, we’re going to talk about SOLID principles and how them could be very helpful during our projects design and development