aspose file tools*
The moose likes Beginning Java and the fly likes Encapsulation Justification Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Encapsulation Justification" Watch "Encapsulation Justification" New topic
Author

Encapsulation Justification

Pavan Kumar Dittakavi
Ranch Hand

Joined: Feb 12, 2011
Posts: 104

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
Sheriff

Joined: Sep 28, 2004
Posts: 18825
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Pavan Kumar Dittakavi
Ranch Hand

Joined: Feb 12, 2011
Posts: 104

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

Joined: Jan 10, 2002
Posts: 61190
    
  66

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.

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18825
    
  40

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

Joined: Mar 17, 2011
Posts: 7773
    
  21

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

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Encapsulation Justification