Protecting data integrity with encapsulation



The idea of encapsulation is to ensure that each part of an application is self-contained and doesn’t interfere with any others, except in a clearly defined manner. OOP (Object-Oriented Programming) breaks down complex tasks into their component parts, so it is necessary to ensure that changing the value of a property doesn’t trigger an unintended chain effect through other parts of the application. When defining a property in a class, you must specify whether it is public, private, or protected. Public properties are accessible to all parts of a PHP script, both inside and outside the class definition, and their values can be changed in the same way as any variable. Protected and private properties, on the other hand, are hidden from external scripts, so they cannot be changed arbitrarily.

Methods can also be public, protected, or private. Since methods allow objects to do things, such as validate input, you frequently require them to be public. However, protected and private methods are useful for hiding the inner workings of a class from the end user. One of the properties of the Pos_Validator class is $_inputType, which determines whether the input being validated comes from the $_POST or $_GET array. To prevent the value of $_inputType from being changed, the class definition declares it protected like this:

protected $_inputType;

The value of $_inputType is set internally by the class at the time of instantiating the object. If you attempt to change it directly, PHP generates a fatal error, bringing everything to a grinding halt. Inconvenient though this may sound, this preserves the integrity of your code by preventing an attacker from tricking a validation routine to handle variables from the wrong type of source. As long as a class is well designed, encapsulation prevents the values of important properties from being changed except by following the rules laid down by the class.

Encapsulation also makes the final code much simpler and easier to understand, and this is where the example of a car as an object starts to make sense. Unless you are a motor mechanic or enthusiast, you don’t need to know the details of the internal combustion engine to get in a car and drive. It doesn’t matter whether it’s an old-fashioned gas guzzler or one that runs on bio-fuel; all you need to do is turn on the ignition and put your foot down on the accelerator. What this means in terms of OOP is that you can create a class with a method called accelerate(), and the user doesn’t need to worry about the internal code. As long as accelerate() method performs the expected task, the user is happy.

This leaves the developer free to make improvements to the method’s internal code without forcing users to make similar changes throughout their own scripts. If you are working on your own, this may not seem all that important, as you are both the developer and end user. However, if you are working in a team, or decide to use a third-party class or framework, knowing what goes on inside the black box of the object is irrelevant. All you want to know is that it works and provides consistent results.

Encapsulation is a great advantage for the end user, but it places an important responsibility on the developer to ensure that changes to the internal code don’t produce unexpected changes in output. If a method is expected to return a string, it shouldn’t suddenly return an array. The black box must work consistently. Otherwise, all dependent code will be affected, defeating the whole purpose of OOP.