Friday, October 30, 2009

Object-oriented terminology

This morning I was teaching to a naive php programmer how to use a Facade class I have prepared to decoupling his php scripts from the database. After having exlained many object-oriented programming terms, I think sharing a glossary would be useful for the programmer who is starting to exploring php objects.
This article implements the beginner pattern.

State is what is stored in a set of variables and behavior is a bunch of functions. One of the main innovation of object-oriented programming was striving for keeping state and behavior together in a code construct called class. In a pure object-oriented language like Java, no code goes out of classes; php is an hybrid language and you can still write procedural code which makes use of classes and objects.

A class is a blueprint for constructing objects. The entities in your domain should be modelled with classes: User, Group, Post, but also FormHelper, AuthenticatorService and similar service classes. The construct should include definitions of internal variables alias properties alias fields (state) and methods (behavior). Methods are simply functions that are tied to an object, and can refer to other members of the class like variables, as class members are always in the same scope. In a function, you have parameters and local variables available; in a method, you have parameters, members and local variables.
The act of creating an object is called instantiation and involves the new operator:
$john = new User();
As you have guessed, an object is an instance of its own class.
The creation process can take arguments, which will be passed to a special method of the class called constructor. This method commonly stores the parameters passed in object members, for future use by the other methods.
Think of a class as a car blueprint and of an instance as a real car. You can create many different cars from the class, that share the same structure but can tune the members (changing the color, the model). The methods remain the same: throttle(), brake(), turn($direction) and so on. The member variables are the same, but they are hidden under the hood as ideally we want to interact with objects only by calling their methods.

A class can inherit from (one) parent class. $john = new AuthenticatedUser() is still an instance of User if AuthenticatedUser extends User. This class automatically implements all visible methods and variables by borrowing the code from its superclass.
Multiple inheritance can be achieved with interfaces: a class can extend only one parent class, but can implement as many interfaces as you want. Though, no code other than method signatures can be inherited from interfaces, as they define a contract the implementor should respect.
The act of passing around references of subclasses and different implementations as they were references to the base class or interface is called polymorphism.
Expanding on the previous car-based example, the class Car can be extended by Ferrari, which adds more luxury methods such as openMiniBar(). I still can pass a Ferrari to the car wash methods as it is still a Car.
Maybe the Ferrari class implements also the interface LuxuryItem, that includes the method getTaxRate(). So if I buy a Ferrari, I can pass all my LuxuryItem instances to the Accountant object which will calculate the total taxes for this year, without even worrying about what kind of items he is dealing with.

The visibility of class members can be altered making them public, protected or private (in some languages there is also package visibility available). Public members can be accessed by anyone; protected members by subclasses and private members only by the code that resides in the class. This encapsulation hides the details of a class and provides abstraction, reducing coupling between classes.
Imagine coupling as strings attached between objects: the more coupling is present in an application, the less the classes are reusable and maintainable. Private members for instance reduce coupling because when you change their name and type you do not have to check any code but the original class source file. The Accountant class has low coupling towards the Ferrari object thanks to the interface that sits in the middle.
Another qualitative metric is cohesion, which is the measure of how well the lines of source code within a module (or a class) work together to provide a specific piece of functionality: a class should have only one responsibility, which is covered by cohesive methods and variables. A class with low cohesion it's like an object that does too much, and not very well: think of a stereo that prepares coffee.

You are confused? If you are learning object-oriented programming I guess you are. The learning curve is not steep but it is very longer and you will spend many months and lines of code before mastering "the classes". Though, this article is a reference to clarify terms you will certainly encounter during your journey: many words have a specific meaning in the computer science field, like the ones bolded here.

2 comments:

Saulo Silva said...

Very good recap of the OOP terms. I've subscribed to your blog--I'm looking forward to your future posts!

Giorgio said...

Thanks Saulo. I'm currently offline because of ISP problems and I connect from the university, but I will prepare the articles at home and post from here.

ShareThis