Tacet Blue 2004

Encapsulation or Data Hiding as it is sometimes known, is an important advantage of Object-Orientated design and also part of its philosophy. This is the concept that an object should totally separate its interface from its implementation. All data and implementation code should be hidden behind a public interface. This allows the workings and methods to be changed (usually improved) and the class will still interact with the application as before ( as long as the public interface remains consistent ).

By approaching a design from an OO perspective it is almost unavoidable that encapsulation will be part of the system. The idea behind it is to protect the integrity of the data within the program. One advantage is that during the development phase, it is harder for a developer to accidentally alter data, or write a method that bypasses a function needed by directly modifying an object.

The most common type of encapsulation is to make properties of an object private, and then provide public accessors. For example in my Car class there is a mileage property, if this variable was public it would be possible to change it from method main. This may not seem that bad, but in the application, hire status must be set to ‘on service’ after 5000 miles, this is taken care of in the setMileage mutator. If this method was bypassed by changing the mileage directly the car would not go to service when due. Keeping the data of an object private is key in a security model.

In transactions it would not be desirable to be able to manipulate the account number on an existing transaction ( to avoid paying it ) so there would be no mutator to do so, making it impossible. Mutators could also take multiple arguments such as an ID so the data that is protected may still not be allowed to change if one of those arguments had to be a valid Id. By forcing a developer to use the ‘front door’ public interface, an object can be maintained in a consistent state. For example in transactions, if the paid flag were directly set to true, but the active flag was still true, this would mean that the car had been paid for but the customer still had it. This would represent an inconsistent state in our model. In our application we have used encapsulation throughout, most noticeable in the public accessors and mutators and private variables in all objects. Also method main actually has no direct access to any object, a car can only be accessed through its interface CarFleet. Customers can only be accessed through CustomerDB and the same is true for Transactions. This further reduces the chance of data being changed in a careless or unexpected way.