Getter/Setter vs Private

[A Kumar]

Hi,

Suppose in a class i have a private..variable..A

and corresponding to that we have getter setter methods...

In such a case..are we really encapsulating...the variable A..

bcoz through an intermediate set of methods we still can manipulate the

value of the varibale A...Then is this OO concep violation???

Tx

[Baiju Varugese]

the idea behind providing the set and get method id to control the assignment of values for the variables, in the set method we can provide some pre condition for the variable

[Ilja Preuss]

Accessors provide for better encapsulation than direct field access, but you are right that they are still rather weak. It's often much better to provide methods that *do* something instead of just getters/setters.

See http://c2.com/cgi/wiki?TellDontAsk

If you have an example in mind, we could discuss that in more detail...

[A Kumar]

Tx for the answers....

I was reading something about polymorphism....
and so had a thought about this.

Thx

[Mikee Warren]

Theres an interesting/controvesial article here "Why getters and setters are evil", which I think highlights the problem you mention.

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

[Thomas Taeger]

Originally posted by Ilja Preuss:
TellDontAsk ... (link)

I liked that link because it also concerns the case of more than one object, and according to it I would say:
"Ask only if you can't tell".

It is a bad practice to allways provide getters / setters for each attribute. This should be the exception.

Sadly the Swing and "bean" scope of providing as many attributes publicly as possible has misled Java starters to a "bean vendor" scope that normal programmers do not need and should not intend.

Where the object (class) can do it, tell it to do it itself.
Provide getters and setters closefisted.

But still even more important remains not to provide public attributes.
I declare all attributes private first and start thinking about
a) getters and setters or
b) refactoring (preferably!)
as soon as it seems to become necessary.

Thomas.

[Ilja Preuss]

Thomas, very well said!

[vu lee]

Using reflection, a private variable can be modified. Is private variable really encapsulated?

[Ilja Preuss]

Originally posted by vu lee:
Using reflection, a private variable can be modified. Is private variable really encapsulated?

I would say so. Reflection can be used as a "nutcracker" to break existing encapsulation. But that doesn't mean that the encapsulation never existed.

To me, the point of the private modifier is mostly one of *communication*, less one of enforcement.

A public field is part of the public interface of the class - it's like a promise that the field will be available in the future to guarantee compatibility. A private field doesn't have that property - you can access it by using reflection, but you do so at your own risk.

[sever oon]

You are correct, and very perceptive at that. Just because you've made a variable private and provided getters and setters does not mean your class provides good encapsulation.

*Good* encapsulation has to do with whether the API of your class, as a whole, is consistent. Consistent with itself and with the system as a whole. This gets at the fundamentals of why the class exists. What was it intended to do? Does the API provide those core capabilities? Does it provide capabilities beyond what it makes sense for it to do?

The simple mechanical answer to your question is that providing method-based access to a private variable does give you some level of encapsulation. But it really depends on the variable. Should that variable be accessible through the public API in the first place? If not, then providing a getter breaks encapsulation. Is the object supposed to be immutable? If so, then providing a setter breaks encapsulation. Furthermore, if the method performs a sequence of operations that are not intended to be overridden, and the method is not marked final, that breaks encapsulation. In other words: providing other objects the capability to alter the state of your object in any way your object is not prepared for breaks encapsulation.

In my estimation, blithely providing getters and setters for every variable is a horrible way to program in OO.

[Tim Holloway]

Maybe I drifted off into the Twilight Zone and didn't realize it, but experiences with ORM have made me divide the concept of JavaBeans into two types: Data Beans, which hold values, and Logic Beans, which have functionality. Whenever I've attempted to mix the two concepts in a single JavaBean, I've usually regretted it.

Pure logic Beans shouldn't have setters and getters for the simple reason that they should do not be. Any setting and getting would thus be for environmental considerations and not actual internal attributes.

Data Beans, on the other hand, could be simple fields. But. There are good reasons why I prefer not. Back in C++, I preferred using setters and getters because in that day, it was possible to set breakpoints on code, but variable-watch breakpoints weren't always available. That's generally not the case today, but other considerations (such as when you're using an ORM framework such as JDO or Hibernate) mean that it's still useful/essential to hide the fields and use the accessor functions instead. Plus, there's the advantage of being able to insulate the data access layer from changes in the low-level data transfer/persistency strucure, add logging functionality to important field references, etc.

This isn't to mean I mindlessly do the above at all costs, but I do find it useful as a "best practice".

BTW, one argument against using accessor functions is the extra overhead of a function call vs. straight variable access. This is specious, as modern-day compilers are fully capable of detecting and optimizing for this condition if they so desire.

[Ilja Preuss]

Originally posted by Tim Holloway:
Maybe I drifted off into the Twilight Zone and didn't realize it, but experiences with ORM have made me divide the concept of JavaBeans into two types: Data Beans, which hold values, and Logic Beans, which have functionality. Whenever I've attempted to mix the two concepts in a single JavaBean, I've usually regretted it.

Interesting. Can you give us examples of problems you encountered? Thanks!

[Tim Holloway]

Well, mercifully, I've managed to banish specific horrors from my mind, but there are two general cases I can cite:

1. Entity EJBs, which can have business methods in them, but if they do, start confusing the persisted data with how its internals can be manipulated.

I note that apparently EJB3 is dropping the finder methods - or if not, at least I didn't, um, "find" mention of them in the stuff I've been reading. Finders do suffer from the idea that no one will ever come up with a different location need.

2. Generic JavaBeans. Problem here if I start exposing internal fields in a logic component, I get sucked into a situation where as the guts of the system churn, external callers get impacted. I do a lot more heavy refactoring in the development and maintenance of software than most people do. So I prefer to push the properties off to a data JavaBean and use the logic JavaBean for logic and, secondarily as a facade for the properties. YMMV, but it seems to keep me more honest.

[Ilja Preuss]

Originally posted by Tim Holloway:
1. Entity EJBs, which can have business methods in them, but if they do, start confusing the persisted data with how its internals can be manipulated.

I don't have any experience with EJBs, so I can hardly comment...

2. Generic JavaBeans. Problem here if I start exposing internal fields in a logic component, I get sucked into a situation where as the guts of the system churn, external callers get impacted. I do a lot more heavy refactoring in the development and maintenance of software than most people do. So I prefer to push the properties off to a data JavaBean and use the logic JavaBean for logic and, secondarily as a facade for the properties. YMMV, but it seems to keep me more honest.

So if I understand correctly, the problem arises when you have to expose fields for the persistence framework that would otherwise be hidden?

[Tim Holloway]

Originally posted by Ilja Preuss:


So if I understand correctly, the problem arises when you have to expose fields for the persistence framework that would otherwise be hidden?

Well, it has little to do with persistence frameworks. In general, like I said, I find it best to separate things which "are" from things which "do".

Sonething which "does", of course, can be stateless or stateful. If stateless, then there likely going to be properties anyway, since by definitionion, stateless processes aren't keeping information from one call to the next.

Stateful action objects are another matter. I suppose that one of the things that placing the state information in a data-only bean does is encourage me to set up everything in advance, then do it, rather than bop willy-nilly back and forth between actions and settings. That gives me a clearer progression of events and states.

Plus, if the methods in a logic bean have to make an explicit trip to a separate data bean for properties, it seems to make me a little more careful about how the properties relate to each other. Perhaps it's got something to do with isolating external properties from internal properties and vice versa.

Maybe I'm just wierd that way.

[Vladas Razas]

Can you really access privates using reflection? I think it will pop an exception. Unless some very smart byte code thing does that.

Anyways. I went using protected mostly. Why? Because I am tired to go back and make private -> protected when I want to derrive something. Of course this violates "open/closed" principle, i.e. thou shall write a code and not modify it. I think I am just too dumb to think of everything in advance. My cheers to people who write things that can not change often, like JDK. I wonder how they do that

Regards

[Vladas Razas]

Oh I remembered someone said in this forum: "code that is not changing is probably not being used at all" . Still how they design JDK?

[Vladas Razas]

I have a problem with "setters/getter gives you control". In my class getters do create instance of fields if they are not created already (lazy instantiation). Suppose I want to override this getter to create another type of field.. Failed. Because I can not do that unless I have access to the field itself.

[Thomas Taeger]

Originally posted by Tim Holloway:
I prefer to push the properties off to a data JavaBean and use the logic JavaBean for logic and, secondarily as a facade for the properties.

My impression is that dividing into two JavaBeans, one for data and one for its logic, leads to more procedural than oo design.

What could the reasons be?:
- A facade (in particular I am thinking of the J2EE pattern Session Facade) usually offers behaviour / methods for more than one data / bean behind. Indead also extracting the methods to a facade may decouple behaviour and data, but for this purpose I would think of an ordinary interface, not necessarily a Facade.
- Designing along the Model View Controller strategy may be another reason for data / logic separation, typically for relationships
controller : model : view = M : 1 : N. But not all JavaBeans need to follow MVC (M : 1 : N).
- Passing a Command object to a server and let the server decide which behaviour to assign to the Command's action could be another reason for separating into Command (data and generic action) and Controller (logic).
- Several more design patterns may be reasons as well.

Is your "logic JavaBean" reguralyly a candidate to be replaced by an interface?
In general I would prefere one single object along with its interface being responsible for its data _and_ behaviour.

Thomas.

[Tim Holloway]

Originally posted by Thomas Taeger:

In general I would prefere one single object along with its interface being responsible for its data _and_ behaviour.

Thomas.

It was EJBs that turned me off on that idea. EJB properties are forbidden by the spec to be coderanch, and mixing in business logic reduced their reusability as utility components. Either the bean later came up short on a vitally-needed function or an existing function would collide with something that needed to be added, or both.

[Ilja Preuss]

Originally posted by Tim Holloway:

It was EJBs that turned me off on that idea.

I've often heard people say that mixing EJBs and OO design is really hard. Fortunately, I don't have enough experience with EJBs to comment...

[Ilja Preuss]

Originally posted by Vladas Razas:
Oh I remembered someone said in this forum: "code that is not changing is probably not being used at all" . Still how they design JDK?

With lots of deprecation and suboptimal APIs... :roll:

[Tim Holloway]

Originally posted by Ilja Preuss:


I've often heard people say that mixing EJBs and OO design is really hard. Fortunately, I don't have enough experience with EJBs to comment...

Well, to me, one of the foundations of OOP is separation of concerns, so I'd actually think the other way. Like Palm used to say: "Do one thing. Do it well". I rather suspect that they'd be in better financial shape today if they'd remembered that instead of adding in advanced cell phones capabilities, power-sucking color displays and other bells and whistles.

[Stan James]

Originally posted by Vladas Razas:
Oh I remembered someone said in this forum: "code that is not changing is probably not being used at all" .

The more abstract code is, the more stable it can and should be. You might be able to design an interface that stands unchanged for years, while various implementations come and go all the time based on changing customer requirements. Robert Martin draws a graph with stability on one axis and abstractness on another. The most abstract and stable classes are high on the Y axis, the most dynamic and concrete are far off the right on the X axis. He suggests that all classes should fall on the straight line between the two extremes. So abstract and unstable would be bad, concrete and stable would be unlikely.

[Ilja Preuss]

Originally posted by Tim Holloway:

Well, to me, one of the foundations of OOP is separation of concerns

Another one is encapsulation: putting operations and the data they operate on together.

As I said, I don't know how this translates to EJBs, as I don't have much experience using them, let alone lately.

[Tim Holloway]

Originally posted by Ilja Preuss:


Another one is encapsulation: putting operations and the data they operate on together.

Wow. Bounce me back to 1986. You're right, but I guess these days I make more of a distinction between the macro-level objects and actions (which are contracted to be fairly stable) and the micro-level ones (which I tend to change rather unpredictably). So I frequently set up facades to hide the volatility of the micro-components. It helps me if I keep a distinction between the forest and the trees.

But, as I said way upstream. YMMV.

[Vladas Razas]

I've put a lot of thinking past few days. Here is what I came up with. Back to C++ days you remember there were clear distiction of what HAS what. This distinction became not so obvious with garbage collector. Now we can have multiple classes referencing same object which does not have to be deleted so ownership is not so obvious. I think getters are good example what it is still here. I think only class that is considered Owner of an object should ever return it with it's true type (i.e. ArrayList, not List) if and only if it is not bound to do otherwise by interface it implements. That means, we do not write getter for every reference we have in our class, but only those that are really owned by class plus those that are not supposed to be hidden. As you can see it is some violation of "coding to interface", since in perfect world all classes should have implement some interface, still that would be impractical. It follows then that programmer must think of how class should be used and code accordingly.
Sometimes we find some code that can easily be changed by inheritance. However was that way of altering behavior intended by one who wrote original class? This is why we can make constructors private, write singletons, make classes and methods abstract. At first glance we don't have to do that. It's not required by Java. But this is how we let know what we had in mind to ones that will use it.
Now I have a question. What about I write class that can be inherited just I didn't think anyone would do that. Should I mark such class final?

[Ilja Preuss]

Originally posted by Vladas Razas:
Back to C++ days you remember there were clear distiction of what HAS what. This distinction became not so obvious with garbage collector. Now we can have multiple classes referencing same object which does not have to be deleted so ownership is not so obvious.

Wasn't the same already true with C++ pointers?

I think only class that is considered Owner of an object should ever return it with it's true type (i.e. ArrayList, not List) if and only if it is not bound to do otherwise by interface it implements.

Why should you want to do that? Doesn't that unnecessarily expose an implementation detail?

That means, we do not write getter for every reference we have in our class, but only those that are really owned by class plus those that are not supposed to be hidden.

What is the reasoning for writing getters for references that are "owned" by the class? Wouldn't it be even better to not have getters for those either?

Now I have a question. What about I write class that can be inherited just I didn't think anyone would do that. Should I mark such class final?

I guess it depends on your attitude. Marking the class final will prevent others from inheriting it, for either good or evil. So what are you more afraid of: that others will be misusing your class by inheriting for it, or that you might also prevent valid uses by making it final? (I'd typically - but not always - be more concerned about the latter, and like to use other means for the former.)
[ September 11, 2005: Message edited by: Lasse Koskela ]

[Vladas Razas]

Wasn't the same already true with C++ pointers?

Huh. I wanted to say in C++ there were distinction between having pointer and actually owning pointer. Not in the language itself, but someone has to delete that object. Usually the one that is considered real Owner.

Why should you want to do that? Doesn't that unnecessarily expose an implementation detail?

That is the case of concrete class that does not implement interface. In case of interface or abstract method, my words do not make sense. I skip writing interface if I have a class that I do not need to switch with any other implementation. If I have such class returning something not through interface, I would return it by real type.

What is the reasoning for writing getters for references that are "owned" by the class? Wouldn't it be even better to not have getters for those either?

I do not say one shall write getters for every Owned reference. I did say that one shall write getters only for fields that are wanted to be exposed. My idea was that there shall not be shortcut getters. Let's say I have: A has B has C. A shouldn't have shortcut getter for C, because the real owner of C is B. Again, this is not a call that A must expose B!

So what are you more afraid of: that others will be misusing your class by inheriting for it, or that you might also prevent valid uses by making it final?

But aren't private constructors and singletons alike to "final" class? Is their purpose to limit use of class, isn't it? Investigations wherever class can be derrived or not take time. Final would be a statement "this class is not supposed to be derrived, because I did not have to check if that is usefull/work". If user has access to source and can freely modify it, he could remove "final" if he decides its safe. If he got it as library from vendor then it's bad
I see this question highly related to use of visibility modifiers (private, protected).
It's so easier to write code when you know how your class is going to be used. If there wouldn't be extensive JDK documentation I would be lost in Java API. I really appreciate people wrote not only descriptions for their classes but often with samples and ideas how to use them.

What do you think?

[Vladas Razas]

I am not for strict rules. Everything depend on situation. I don't think I am type of guy who says:

- "You need 5 spaces before every indentation!"
- "look my code here is special. Its getting unreadable..."
- "I don't care! I know it must be good style".

The idea was to let user know how we suggest our class will be used. If there is a conflict it can always be resolved in creative and civil manner

[Ilja Preuss]

Originally posted by Vladas Razas:
I wanted to say in C++ there were distinction between having pointer and actually owning pointer. Not in the language itself, but someone has to delete that object. Usually the one that is considered real Owner.

I see. In garbage collected languages, the responsibility of the owner changes to "keep the object alive by maintaining a reference to it". A lot less eay-catching than having to call a destructor, for sure.

I skip writing interface if I have a class that I do not need to switch with any other implementation. If I have such class returning something not through interface, I would return it by real type.

Why? What do you gain by doing so?

Let's say I have: A has B has C. A shouldn't have shortcut getter for C, because the real owner of C is B.

First let me say that I think getters are often overused. Instead of getting C from B from A to do something with C, you should think about wether telling A to do for you what you want to be done is a valid option.

Second, if you use a getter, having A return a C might still be valid - sometimes it is better to not expose to the outside that A *has* a B.

For example, if A has a List in which there are C's stored, it might be better to have a cCount() and a getC(int) method on A, than having a getCList method.

But aren't private constructors and singletons alike to "final" class? Is their purpose to limit use of class, isn't it?

Yes. That's why I don't use Singeltons or private constructors very often. I don't like Singletons very much, for a bunch of reasons; and I mostly use private constructors for all-static utility classes and constructor chaining (where the other constructors aren't private).

Investigations wherever class can be derrived or not take time. Final would be a statement "this class is not supposed to be derrived, because I did not have to check if that is usefull/work".

If you checked that it could be useful/work, you still needed to take the time to understand *how* to make it work, or so it seems to me. So I don't see much value in using final in the above case. I'd only use final to communicate "I'm quite sure that this class never ever should be inherited from - if you want to do so anyway, be very carefull." I don't remember doing this for classes, but I do this for methods from time to time (for example for template methods).

[Vladas Razas]

Ilja, I think we took each other position a bit I say if one don't expect class to be derrived then make it final. Also I say if one is not sure if some field may be used, write getter. You say don't make class final, but if not sure - do not write getter. Isn't that the same? We both limit the user in different way
The choice is between "give user everything he might want to use" and "give him only bare minimum". "Bare minimum" would be ideal. But the problem is I don't know what the bare minimum is.

I have real world example I am thinking about. I have View. View is bunch of UI widgets plus layout. I am not sure how someone will want to use that View. I can either: a) write public getters for all components in View, b) do not write any getters, but make all components protected. In either case, I am giving the user everything, only access method differs.

[Ilja Preuss]

Originally posted by Vladas Razas:
I say if one don't expect class to be derrived then make it final. Also I say if one is not sure if some field may be used, write getter. You say don't make class final, but if not sure - do not write getter. Isn't that the same? We both limit the user in different way

Yes, "in different way", so not "the same"...

The difference to me is: making a class final is something that takes effort. Why invest that effort if I'm not sure it will be needed?

Writing a getter takes effort and complicates the design. Why invest that effort and make the design more complicated if I don't know wether it will be needed? Especially as I think that most often, providing something different from a getter is the better design solution to a requirement?

The choice is between "give user everything he might want to use" and "give him only bare minimum". "Bare minimum" would be ideal. But the problem is I don't know what the bare minimum is.

Find out. One way to find out is to give them less, and wait for them to ask for more. Works better than it might sound.

View is bunch of UI widgets plus layout. I am not sure how someone will want to use that View.

So why did you write it at all?

[Vladas Razas]

So why did you write it at all?

I will use it once. Not sure if anyone would use it again But it is likely might be used.

[Vladas Razas]

Isn't the pattern idea is too make code more reusable and less coupled? I think people would apply pattern if they see they could change something later easily. But that doesn't mean they will necessary need to change something. Let's take MVC. What point of using MVC if you 90% sure that this particular view (and most of them are that kind) will never ever use another controller. We just leave possibility to use one, but we not sure if we really need one.

[Tim Holloway]

Well, I just got whacked good, working with JSF. This is the second or third time.

If you believe the press, JSF works with simple JavaBeans, and, as in the case of EJBs, you must use setters and getters, and not direct member access.

Don't believe the press. These so-called simple JavaBeans have developed a nasty habit of serving simultaneously as both a simple object resource and a collection of said objects, in order to support the common paradigm of working with tables of objects.

However, the more situation more relevant to the main topic of this discussion has to do with internal references. Originally, I was working with simple fields, and when you selected one of the items in the bean's collection for editing, it would internally set the properties of the bean so that fields would be accessible from the selected item detail view.

Well, the data brought in from backing store got a little more complex, and what started out as simple string fields now require looking up through 2 levels of HashMaps. So my internal field accesses now have to be refactored as internal getter calls, whether I like it or not. The alternative would be to hoist the values every time certain items were touched, and I don't want to trust that kind of code not to be fragile.

You can say that the JSF model breaks all sorts of pattern principles and I won't argue. You can say I'm doing it all wrong, and I won't disagree on that, either. But this is one of the real-world reasons why I have become reluctant to do direct property accesses.

[Thomas Taeger]

Hi Vladas, hi Ilja,
first I want to say that your kind of discussion is the one I appreciate so much in forums - not just telling an opinion but also telling the reasons!
Trying to understand each other and then well arguing...

Originally posted by Vladas Razas:

But aren't private constructors and singletons alike to "final" class?

No.
- _Singleton_ along with private constructors ensures that only one _instance_ can exist at runtime.
There is no relationship Class-1--N-InstantiatingObject anymore.

- Declaring a class _final_ cuts off the chance of _polymorphism_ at compiletime [and runtime].
There is no relationship Class-1--N-InheritingClass anymore.

Thomas.
[ September 14, 2005: Message edited by: Thomas Taeger ]

[Vladas Razas]

No.
- _Singleton_ along with private constructors ensures that only one _instance_ can exist at runtime.
There is no relationship Class-1--N-InstantiatingObject anymore.

I admit singletons do not only enforce something but they help to insure that only 1 instance will be used. So they are not just pure restriction.

- Declaring a class _final_ cuts off the chance of _polymorphism_ at compiletime [and runtime].
There is no relationship Class-1--N-InheritingClass anymore.

That's true. But not writing getters for all fields that _might_ be needed is alike. Except for Ilja argument that writing getters takes effort. Later on one will might need getters and can add ones as well as to remove "final".
Setting "final" and getter aside, what is better - to think how the class might be re-used or follow only immediate needs. Making code re-usable takes time and effort (some or most code will never get reused). But making un-reusable code reusable may take even more effort later on (fixing existing code that depends on original code).

[Ilja Preuss]

Originally posted by Vladas Razas:
Making code re-usable takes time and effort (some or most code will never get reused). But making un-reusable code reusable may take even more effort later on (fixing existing code that depends on original code).

Making reusable code *really* reusable also might take considerable effort, as most often before you really *do* reuse something, you can only guess at what makes code reusable.

Making un-reusable code reusable only takes much more effort later if your code isn't well decoupled. So my preferred strategy is to have code that is well decoupled (design patterns help here, too), but doesn't do more than is needed now.

[Vladas Razas]

Making reusable code *really* reusable also might take considerable effort, as most often before you really *do* reuse something, you can only guess at what makes code reusable.

I agree wholeheartly!

Making un-reusable code reusable only takes much more effort later if your code isn't well decoupled. So my preferred strategy is to have code that is well decoupled (design patterns help here, too), but doesn't do more than is needed now.

Maybe it depends on type of the project? When we develop final product with source code open for modification we can save time. But if we develop library then code must be more flexible than average.

I think you're right, there is no point of making everything reusable (since it's only guessing anyways) plus it burns incredible amounts of time.

Thanks for very interesting discussion!