Encapsulation and Accessor Methods with the Future in Mind


Always write and design with the future in mind because you never know when you might have to go “BACK”

“Always write your code with the assumption that it will one day need to be extended even if the current specification or business logic does not make that apparent”.

Based on my own experiences, this would be one of my top tips for anyone involved with a project or even just a bit of code from its early stages or latter for that matter. This post looks at how accessor methods and encapsulation can help with regards to putting this idea into practice.

Many a time you will find yourself writing something that works with regards to current requirements then sometime in the future you have to revisit the application in order to extend its functionality in some way but what should normally be an easy task becomes big odessy packaged with the potential for introducing bugs into your code base.

Here is a nice and simple example


class fluxCapcitor {

function timeMachine($name) {
  print "This Capcitor is powering a $name";


$fc = new fluxCapcitor();

 $fc->timeMachine('ford fiesta');

Here we have an instance of our flux capacitor class with an object $fc that lets the user know what kind of car our time machine is running on.

All is well and dandy here until the time comes when we need to extend this functionality. Imagine that it was decided that flux capacitors are only allowed to be used in 1980s style Delorean cars.

Our problem here is that we have not set the visibility of the $name property so it is public by the default which means we do not get to do any kind of data validation when the object is set.

Further more and more important is the fact that (although maybe not so obvious in this example) changing the code of the class could have a knock on affect on the code outside the class because you have allowed the opportunity for something outside your class to change and modify the state of an object built with the class without relevant checks. This could lead to potential future bugs and also extra work with regards to checking and making changes to instances of your class to make sure your new change within the class works.

The best form of practice to avoid this potential future problem would be to encapsulate the class by setting the name properties visibility to private and using accesor methods.

The reworked fluxCapciotor class would look like so

class fluxCapcitor {

private $name;

public function timeMachine() {
 print "This Capcitor is powering a {this->getName()}";

public function getName() {
 return $this->name;

public function setName($name) {
if($name !== 'Delorean') {
 throw new exception("Invalid machine, only a Delorean can handle the 88mph needed for time travel");
 $this->name = $name;

$fc = new fluxCapcitor();


$fc->setName('ford fiesta');// this would now cause an error

Now we have set the visibility of $name to private and made it so that it can only be accessed via the accessor methods getName() and setName(). The setName() method throws an exception if an invalid value is set when using an object of this class.

In our example we needed to extended our initial class so that it did some data validation to ensure that only Delorean cars were being used for time machines. By encapsulating the class in this way we can easily manage what is allowed into it therefore making it easy to extend it further in the future.

Further Reading



Not so important further reading

To help understand the time travel concepts used in this post you may want to check out the links below




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s