Share it now!

Sometimes when we are programming OO we are facing some situations when we are tempted to put a value into an attribute in the fastest way. It happens because we have to deliver the code soon, or because we are doing a big change and don’t have a lot of time to expend in little details. So, it’s easier to be dominated by circumstances than analysing what we are doing.

Suppose we have a Door class and we want to know when it’s open or not but we want more, we want to change its state when it’s open we might close it and vice-versa. An easy way it would be to create a class and put a boolean attribute:

 public class Door {  
     private boolean doorIsOpen = false;  
}

So far we are ok, but now we can feel some danger. How are we going to make this attribute change its value? Shall we choose to let this attribute changing be handled by the Door class or by the object that is calling this Door Object? The most usual solution we can see in the market: is to make a get/set as the first programmers did a lot:

public void setDoorIsOpen(boolean doorIsOpen) {  
	this.doorIsOpen = doorIsOpen;  
}

public boolean getDoorIsOpen() {  
	return doorIsOpen;  
}  

// To close the Door  
if (door.getDoorIsOpen() == true)  
	door.setDoorIsOpen(false);  

// To open the Door
if (door.getDoorIsOpen() == false)  
	porta.setDoorIsOpen(true); 

Think with me, what if, this condition of questioning (if + get) and the set attribute value were in more than 30 places of your project, and the customer asks for a new business rule. How should it look? How would it be coded? Let’s supose that, the user wants the door closed. The Doors Alarm must be active:

  public class Door {  
       private boolean doorIsOpen = false;  
       private boolean alarmIsActive = true;  
       public boolean getAlarmIsActive() {  
            return alarmIsActive;  
       }  
  }  
  // To close the Door  
  if (door.doorIsOpen() && door.getAlarmIsActive ())  
       door.setDoorIsOpen(false); 

With this type of code, it would be necessary to change all project method that is using this code. Imagine all the hard work to change this code overall project…

To avoid all this hard work, just tell the object Door what to do, do not ask its attribute state and then changing it.

By applying this concept, this code change would happen only in one part of the project and the other 30 places would remain the same. The start code before the new customer request (activated alarm), would be like this:

  public class Door {  
      private boolean doorIsOpen = false;  
      private boolean alarmIsActive = true;  
      public boolean getAlarmIsActive() {  
           return alarmIsActive;  
      }  
      public boolean isOpen() {  
           return doorIsOpen;  
      }  
       public void closeDoor(){  
          doorIsOpen = false;  
       }  
       public void openDoor(){  
            doorIsOpen = true;  
       }  
  }   

The code to close the Door it would be simpler:

  // Closes the Door
  if (door.isOpen())  
       door.closeDoor();  
  // Opens the Door
  if (!door.isOpen())  
       door.openDoor();   

After this refactoring we just have to put the alarm condition inside the method that closes the Door; changing one line in one class and all the rest of the project will remain the same:

  public void closeDoor(){  
       if (alarmIsActive)  
            doorIsClose = false;
  }   

Now, every time that the business rule changes (like close the Door), we just have to change the method of a specific class and, all the project classes, will be intact.

By this principle, we lose coupling between the classes, and your code is ready to be used by all your project.

It’s a good tip!

Inspired by: “The pragmatic Bookshelf – Alec Sharp”

Edit: Refactor at last code. Tip by H. Fernandes (at porguese post)