• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Encapsulation Justification

 
Pavan Kumar Dittakavi
Ranch Hand
Posts: 106
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

If I have a class , say FuelManagementSystemand if I have a private variable fuelQuantity, then from another class SoundManagementSystem I can't access 'fuelQuantity'.

But what happens if I expose a public method say, 'setFuelQuantity()'?. If I have an instance of FuelManagementSystem, I could easily say fMSInstance.setFuelQuantity(INSANE_AMOUNT); from within the SoundManagementSystem isnt it?.

So, how can we justify encapsulation [ modification of fuelQuantity using the API provided by FuleManagementSystem alone ].

Please share your thoughts on the same..

Thanks,
Pavan.
 
Henry Wong
author
Marshal
Pie
Posts: 21226
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pavan Kumar Dittakavi wrote:
If I have a class , say FuelManagementSystemand if I have a private variable fuelQuantity, then from another class SoundManagementSystem I can't access 'fuelQuantity'.

But what happens if I expose a public method say, 'setFuelQuantity()'?. If I have an instance of FuelManagementSystem, I could easily say fMSInstance.setFuelQuantity(INSANE_AMOUNT); from within the SoundManagementSystem isnt it?.

So, how can we justify encapsulation [ modification of fuelQuantity using the API provided by FuleManagementSystem alone ].

Please share your thoughts on the same..


Not sure what you are trying to say... are you saying that if you provided a public setter method, and this public setter method doesn't do range checking for something that needs range checking, that it is a bad thing?

Henry
 
Pavan Kumar Dittakavi
Ranch Hand
Posts: 106
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nope. To put it in simple terms, if I have a FuelManagementSystem instance available in a method of AudioManagementSystem, then I can always do a setCurrentFuelReading() to any value that I want. So, what is the use of providing a setter method here?. Generally would one be providing a setter method in the first place for all private data?. If not how does one determine for which pprivate variable a setter method would be provided?

Thanks,
Pavan.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64992
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pavan Kumar Dittakavi wrote:So, what is the use of providing a setter method here?

To allow controlled access. Even if all the setter does is to set the value, what if in the future you need to ensure that the value fits within a specified range? If external code has free access to the variable, you're up the creek without a paddle.

Generally would one be providing a setter method in the first place for all private data?

No.

If not how does one determine for which pprivate variable a setter method would be provided?

Is it a value that other code has any business setting? If not, no setter.
 
Henry Wong
author
Marshal
Pie
Posts: 21226
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pavan Kumar Dittakavi wrote:Nope. To put it in simple terms, if I have a FuelManagementSystem instance available in a method of AudioManagementSystem, then I can always do a setCurrentFuelReading() to any value that I want. So, what is the use of providing a setter method here?. Generally would one be providing a setter method in the first place for all private data?. If not how does one determine for which pprivate variable a setter method would be provided?


Sorry. I still don't get the point. What's wrong with preventing what you don't want done?



Henry
 
Winston Gutkowski
Bartender
Pie
Posts: 10430
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pavan Kumar Dittakavi wrote:So, how can we justify encapsulation [ modification of fuelQuantity using the API provided by FuleManagementSystem alone ].
Please share your thoughts on the same.

Encapsulation gives you, the designer, control. Nobody gets access to anything in your class except via methods written by you - and, even then, only if you allow it.

Personally, I'm not a big fan of setters. They smack to me of lazy thinking: "Hey, I've got this field. Let's write something so people can update it."

That's not the way it should work. An object should move from one predictable state to another in a manner dictated by business or application rules, not just by saying "oh sure, go ahead and change this field if you want". To be honest, I don't know what that would be for an FMS; but I'd be darn sure I did before I let anyone change stuff in my class.

Have a look at this article, it says what I'm trying to a lot better than me.

Winston
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic