Object orientation is all about treating features of a system as little interconnecting black boxes. We have no idea what goes on inside a black box, but each black box can be described in three ways:

Also, in fact, our little black boxes are objects and each object has a state, exhibits certain behaviors, and every object is uniquely identifiable as each has its own identity.

Objects themselves are of a particular type, called a class. Your pet cat shares some of the features of a mountain lion because they are both feline, and felines are types of mammals, so all mammals share similar characteristics, and so on. It is the same way with objects in Moodle:

If there is a specific programming task you need to perform in Moodle, you need to look for the correct API with which to carry out that task. Visit https://docs.moodle.org/dev/Core_APIs for a list of all of Moodle's internal APIs. For example, do you need to display a string on the screen? If so, use the String API. Why? It is because the String API automatically handles issues such as formatting and internationalization.

Each one of these APIs is accessed via an object. For example, use the global $DB object to access Moodle's database. This is an instance of the Data Manipulation Language (DML) API. Again and as with using the String API to display text on the screen, don't try to access the database other than through the interface Moodle provides. Why? It is because issues such as SQL injection hacks and verifying data integrity are already handled in the $DB object interface, so you don't have to worry about it.

However, what if there is a behavior that a particular interface doesn't support? This is solved by the notion of inheritance--see https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming). If, for example, the String API is missing a behavior our project requires, or we need to modify a behavior in order for it to fit our needs, we can declare a new class and base it on the String API. The new class is called a child class and the class upon which we have based the child is called the parent class. Certainly, in the case of the String API, we can reconfigure Moodle to use our new API. We will be learning how to modify an API (using the String API specifically) later in this chapter.

This section is merely a brief overview of the object-oriented philosophy, intended to be just enough of an explanation before you start Moodle plugin development. For more details on the object-oriented philosophy in general, check out the Wikipedia page on object-oriented Programming at https://en.wikipedia.org/wiki/Object-oriented_programming.

For a complete list of Moodle's core internal APIs, take a look at https://docs.moodle.org/dev/Core_APIs. The first set of APIs are listed as General APIs. They are the interfaces upon which most plugins are built, for example, the Data Manipulation API for reading and writing to the Moodle database or the Form API that displays web forms and handles their form data. In the next section, we will create a simple plugin that overrides (in the object-oriented sense) and calls on the String API to change the way language strings are displayed in Moodle's user interface.

The "Other General APIs", listed next, are the ones that are still fundamental and likely to be used in any type of plugin but, that said, are much less likely to be called upon, for example, the Calendar API or the Competency API.

Then, there are the APIs that are specific to certain plugin types, such as the Activity Completion and Plagiarism APIs, which will only be employed by a Moodle activity module.