The first step – part three


Last time in part two we looked at:

  • Variables
  • Functions
  • Scope and globals

This time in part three we will conclude with:

  • Classes and methods
  • Class inheritance and overloading

If you’ve not read parts one and two, then please do so before this part so that it will make sense.


Firefox® is a registered trademark of the Mozilla Foundation –

Ubuntu® is a registered trademark of Canonical Ltd –

“Raspberry Pi” is a trademark of the Raspberry Pi Foundation –

Apache and Apache HTTP Server are trademarks of The Apache Software Foundation –

Other names / logos can be trademarks of their respective owners. Please review their website for details.

I am independent from the organisations listed above and am in no way writing for or endorsed by them.

All example ‘code’ presented is written by myself, please feel free to copy for educational purposes only.

A reminder if it does not work

If something goes wrong, then you need to look in the error log file. On the Pi, this will be located in the ‘/var/log/apache2’ folder as ‘error.log’ and you can use the command ‘tail’ to see the most recent events as the file is appended to. In other systems, hunt around for ‘error.log’.

Why ‘Objects’ and ‘Object Orientation’?

In part two we looked at variables, functions and particularly scope. Whilst a machine is happy to perform the commands it is given regardless of the quantity, a human on the other hand understands the greater context of the problem with its solution. They can envisage a concept far beyond that of a single machine instruction or one just about to be in its pipeline. But there is a problem with this, granularity. As we delve deeper into a problem and devise solutions we begin to loose sight of the structure of the solution as a whole. This can lead to similar solutions being used in different parts of the program that do the same thing and can even be coupled to the same data without even realising it, thus causing ‘bugs’ that are difficult to detect and solve. This can be even more obvious when a problem has more than one person working on it in different places.

The solution to this is really a methodology that I think has its origins elsewhere in our technological past. Before computing really took off we built things out of materials we find on this planet, some of them we combine to make other materials as a starting point. Initially lots of people solved the same problem to a similar pattern, but each implementation was not completely compatible with another and when one broke, the fixing it with parts of another would be a hit and miss affair. Then standardisation came along, so think of standard sizes for nuts and bolts as an example. Now solutions were implemented with self contained components that did a specific thing. The components could be tested to a high degree within the functionality they provided and could be moved from one solution to another when breakage occurs.

Now transfer the concept of standardisation to software and you get a methodology whereby you can create self contained components that can contain other components and when lots of them are combined in a planned structure then you have your solution to your problem. You can navigate around the solution at any degree of granularity and each element does the task for which it was designed to solve.

So thus we have the concept of ‘Object Orientation’, please see ‘The ‘OO’ in Moodle’. But as humans are not perfect then there will always be bugs, however we can adapt whereas machines cannot or at least only to situational changes where the solution is already known.

Classes and methods

Think of the class and method as a template that is used to create the actual ‘object’ that will do the work. The class defines what the object is and what data it will store, the methods define what you can do with that object and may change the data it stores.

Both the data and the methods have three levels of access:

  • Private – only the object can see / use / change.
  • Protected – only the object and any objects that ‘inherit’ from it can see / use / change.
  • Public – anything that knows about the object can see / use / change.

So take the code:

Where we define and use a ‘Pencil’ which has two attributes, its length and its grade (i.e. ‘HB’) which are ‘private’ to it and set when the pencil is created, i.e. instantiated. Once this has been done by using its ‘constructor’ to create the actual ‘object’ then we can only do a certain number of things with it, such as ‘write’. This in the greater picture, prevents data being manipulated in an unintentional way by other code, perhaps written by somebody else that does not know the full details of why the code exists in the first place.

When we run this code by visiting the web page, we get:

Where each pencil is created within an array with different attributes. Then they are used and queried on how long they are.

Class inheritance and overloading

Now that we understand a single class which is a ‘writing implement’, that allows us to see that there are many different writing implements in addition to a pencil, like chalk and a pen that share common traits but are also specialisms of the same thing, so if we have:

Then we can see that we have an ‘abstract’ class called ‘writingImplement’ that cannot be made into an object but has the common attribute of ‘length’ and all can ‘write’ but that ‘method’ is abstract because the effect on the implement is different. So now, Pencil, Pen and Chalk can ‘inherit’ from ‘writingImplement’ without having to reimplement the ‘length’ functionality. Now the output is:

Where we can see the objects being created with the common length attribute along with their own specialised attribute. Then when used the effect of the ‘write’ method has a different outcome.

Further reading

To learn more about PHP, you could choose to visit:


In this post we have learnt about:

  • Classes and methods
  • Class inheritance and overloading

I hope you’ve progressed with your learning of PHP, this is the last part for now.

Gareth Barnard
Latest posts by Gareth Barnard (see all)

Gareth Barnard

Gareth is a developer of numerous Moodle Themes including Essential (the most popular Moodle Theme ever), Shoelace, and other modules such as course formats.

One thought on “The first step – part three

  • 16th April 2020 at 8:30 am

    Great analogies used here Gareth – really helped my understanding of these concepts !


Add a reply or comment...