Why use OOP

Posted under » Methodology on 30 October 2012

Procedural programming-works fine for short, simple scripts, but once you get beyond more than a few hundred lines of code, it becomes increasingly difficult to spot mistakes. If you make a change to part of the program's logic, you need to ensure that the same change is reflected throughout.

The answer was to break up long, procedural code into discrete units of programming logic. In many ways, this is similar to creating custom functions. However, OOP takes things a step further by removing all functions from the main script, and grouping them in specialized units called classes. The code inside the class does all the dirty work-the actual manipulation of data-leaving the main script like a set of high-level instructions.

To take a common example, before using input from an online form, you need to make sure it doesn't contain anything that could be used to sabotage your database or relay spam. The procedural approach looks at the specific project, and writes tailor-made code, usually a series of conditional statements designed to check each input field in turn. For instance, this sort of code is commonly used to make sure a username is the right length:

if (strlen($username) < 6 || strlen($username) > 12) {
$error['username'] = 'Username must be between 6 and 12 characters';
}

OOP looks at programming in a more generic way. Instead of asking "How do I validate this form?" the object-oriented approach is to ask "How do I validate any form?" It does so by identifying common tasks and creating generic functions (or methods, as they're called in OOP) to handle them. Checking the length of text is one such task, so it makes sense to have a method that checks the length of any input field and automatically generates the error message. The method definition is tucked away inside the class file, leaving something like this in the main script:

$val->checkTextLength('username', 6, 12);

The approach taken by OOP has two distinct advantages, namely:

Code reusability: Breaking down complex tasks into generic modules makes it much easier to reuse code. Class files are normally separate from the main script, so they can be quickly deployed in different projects.

Easier maintenance and reliability: Concentrating on generic tasks means each method defined in a class normally handles a single task. This makes it easier to identify and eliminate errors. The modular nature of code stored outside the main script means that, if a problem does arise, you fix it in just one place. Once a class has been thoroughly tried and tested, you can treat it like a black box, and rely on it to produce consistent results.

However, building classes takes time and effort, so OOP isn't necessarily the best approach for simple, one-off tasks. OOP lines of codes is always longer than the procedural way. Unless you know the code is going to be reused in other projects, it can feel like building a steam hammer to crack open a hazelnut.