The ‘OO’ in Moodle
Introduction
Moodle stands for ‘Modular Object Orientated Dynamic Learning Environment’ (and the first word is ‘Modular’ and not “Martin’s” as has been coined in the past). But what is ‘Object Orientated’ or ‘OO’? The term ‘Object orientated’ is defined generically elsewhere and you’re free to investigate its meaning. But instead of referencing sources, in this post I will describe what I believe it means and within the context of Moodle.
Disclaimers and license
Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.
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.
What is object orientation?
It is a way of thinking about how we interact with the world and the capabilities of the things within it.
Take a pencil, it has a defined primary purpose, as a communication technology. It has properties:
- Length.
- Type, in terms of the hardness of the graphite / writing material.
- Colour.
- Supporting material.
- Cost.
- Manufacturer.
There are certain things that it is designed to do:
- Fit in a hand.
- Write.
- Operate in three dimensions.
- Be sharpened.
Both of these define what a pencil is capable of and critically ‘encapsulate’ it within the bounds of the purpose for which it exists. Of course there are other things you can do with a pencil, for instance (please don’t try them!):
- Small tent poles for your Hamster.
- Carry two shopping bags at the same time.
- Create seed holes for when you’re planting plants.
- Create a model fence.
But they are outside the purpose of the pencil for the problem it has been designed to solve and it may break.
From a computing point of view OO allows software engineers to design and create programs using the same concept. They do this for the primary purpose of reducing the impact of a bug on the rest of the program and improving the capability to maintain and reuse code. In my experience, bugs that do happen are more obvious and easier to fix.
The alternative to OO is ‘functional’ or ‘procedural’ programming. With this in a reasonably sized program then the purpose or ‘functionality’ can be distributed all over the code. This means that when working out where a problem is and then actually solving it can be a tedious and frustrating task that can also lead to the discovery of or the creation of more bugs.
A little bit further
Now that we can understand the beginnings of object orientation, lets take things a little further. Start to think in terms of the things around you being objects with their properties and the ‘functionality’ they are designed to do. Look around now, what do you perceive?
Now think of how they got there and who designed and made them. How were they made? Was there a machine with a template that punched out the components that combine to make the object?
In code / computing OO there is the equivalent of the ‘template’ called the ‘class’. That class defines the properties, called ‘attributes’ and functionality, called ‘methods’. Classes can also ‘inherit’ attributes and methods from their parent class. The parent class can be ‘abstract’ and more generic. So in our pencil example its parent could be a thing called ‘writing implement’. Then you could have templates called ‘pen’ and ‘chalk’ inherit from it. So even though you can do most of the same things with pens and chalk as you can with pencil’s, you can’t really sharpen them. Thus a pencil is different and more ‘specialised’ because it can be ‘sharpened’.
When classes inherit they can also (if allowed to) change the way an existing method works as well as adding new ones, such as ‘sharpen’ in our pencil example. When a class changes the method of the parent it defines its own way of doing that method by using the same name. This is called ‘overriding’.
Because a class defines its attributes and methods in one place and only allows access to certain attributes / methods outside of itself, this is called ‘encapsulation’. It is there to prevent one bit of code using an object in a way that it was not designed to do. There is another concept called ‘scope’ which is used both in functional and OO programming as a containment constraint. Thus in a function or method, only code within a given ‘scope’ can ‘see’ the variables / attributes defined within it.
When an object is created, called ‘instantiated’ then its ‘constructor’ helps to set the values of the attributes to make that object unique in some way. Just like the template for a pencil can make lots of pencils even if the type is different or a unique serial number needs to be added.
Moodle
Think of Moodle as a hybrid. It has both OO and functional code. So there are things that are defined globally and cannot be specialised and other things that can. That is why (at the current time of writing) a theme can ‘override’ the methods already defined in something like the course but not the login page.
Moodle also uses OO outside of the programmatic context. If we consider the course categories, courses, themes, activities and resources (the last two conceptually inheriting from the parent called a ‘module’).
There is also the concept of a ‘plugin’. So something that ‘adds’ to the configuration of Moodle that you start with – even though Moodle ships with its own ‘core’ plugins. Thus you can have additional course formats, like my Collapsed Topics or Foundation theme.
Because of this OO is needed to make Moodle work. So that one or more programmers can create, design and implement a plugin without the need to change the core code in order for it to work. The plugin is ‘encapsulated’ within itself.
Plugins can also be thought of as ‘Modules’, so the ‘M’. Thus what we then have are modular components that are designed and implemented in an object orientated way. As modules can contain one or more objects.
But why?
This all seems very complex and time consuming does it not? There must be reasons for this? Well, think of the consequences of not using OO both from a design and code implementation point of view:
- Potentially harder to maintain and fix bugs.
- Difficult for someone else to add in their idea without changing and potentially breaking the code of others.
- Difficult to translate what actually inherently is an object. So things like a ‘course’, ‘category’ and ‘user’ are conceptually ‘objects’. How else could you envisage them?
Therefore, is it even possible to create and implement a eLearning environment without thinking in an object orientated fashion?
Conclusion
I hope that this post sheds some light on the meaning of a third of the acronym that Moodle is.
Now look around you, what can you perceive? Is the world now just full of objects that have properties and functionality? And that there is a relationship between those objects. And that is why OO as a computing methodology exists, to model the real world in the virtual and thus provide a connected link between the two. If the virtual replicates the real then it should be more understandable to you.
- Debugging SCSS – 16th November 2024
- Settings transfer – 16th October 2024
- Added value – 16th September 2024
Pingback: The first step - part three - ElearningWorld.org
Awesome post Gareth !
As a person with only rudimentary programming skills this type of article helps me see into the minds of developers more clearly.
Although that may in fact be a scary place to look! lol
And you did make me laugh … pencils being used as “small tent poles for your Hamster.” – classic !