Amazon Interview Question
Software Engineer / DevelopersCountry: India
In addition to controlling access, getters and setters can also be used to perform post or pre-processing on variables.
For example, if you have a Rocket::getSpeed() method which returns the speed in km/h, you can switch internally (inside Rocket) between storing the speed in km/h or m/s without affecting clients of Rocket, as long as you do the appropriate conversions inside getSpeed().
In a setter method, you can perform error checking before allowing assignment. For example, checking that a given speed is <= c inside Rocket::setSpeed
data-members are made private and accessed thru getter and setter methods for pre-processing....edsouza is right....
Suppose we are storing age of a person and v declare that as public. Now any body can access that and can write age = -39 ( as age can't be negative) so this is logically incorrect though your code allows it.
There are 2 solution for avoiding this basically validating the value.
1.) use validation code inside constructor and initialize variable in that. But this is not preferred as every time object is created it will check for the validation.
2.) Use getter/setter methods and put validation code there itself.....
when we have integer divisions say in any software designed for Civil Engineers or Architects..where there may integer divisions and if the user enters the Zero for denomination..the it bcoms divide by zero exception..run time error...such validations can be taken care in those accessors and mutators
There can be different reasons why data memebers are private while we can access them through getter/setter. The main reasons to keep data members private comes from Data Abstraction principle.
- sk February 19, 2012- The abstract properties(so called getters/setters here) are those that are visible to client code that makes use of the data members (the interface to the data members) while the concerete implmenetation is kept private and indeed can change.
-- The idea is that such changes are not supposed to have any impact on client code ( called Localization of Change). Code that uses the object in question will not need to be edited if the implementation of the object is chnaged. since any changes to the implmentation must still comply with the interface and since client code using object may only refer to properties and abilities specified in the interface as changes can be made to the implmentation without requiring any changes in code where the object is used.
-- The uses doesn't need to know any technical knowledge of how the implementation works to use an object. The implementation can be complex but will be encapsultaed (Encapsulation) in a simple interface. For e.g. if we talk about a Banking system, there can be Account class which may have complex implementation, how the account balance is changed. User of this class should not be allowed to access the balance (data member) directly and modify; but using the properties (interface to the data members), you may enforce certain rules how balance can be modified)
keeping data members private also makes your object secure from malicious software which may instantiate the object and perform directly some manipulation on data members. If it goes through properties (getters/setters) you may have some control.
Using above Account class example, the malicous software may not be able to set the account balance to large arbitrary value as with getters and setters you may have some validation plus you may never expose setters for such important data members.
They can only be accessed by the operations which will have all those validations/rules which disallows to set a Account balance to a high arbitrary value. Going through properties/operations will also make a log of the activities.