Getter/Setter Question

[Avogodro Morelli]

First, it has been a while since I have gotten to program using java. At work I have just recently had the chance to dust of the java brain cells. I'm finding some of the dust will not come off.

I recently read an article that was suggesting that getters and setters are bad and to avaid them if at all possible. However, in school we were taught to use getters and setters. Not a problem the article made sense.

My problem. I'm modifing a class in an MRP system to generate a specific kind of report. I'm using the Object Id(oid) of say a part to get the readable name of that part. This name needs to be used in one method of the whole class and I can get the name in only one method of the whole class, which of course is not the same method. So that leaves me with using a getter/setter, a global, or passing the variable four times to get to the method that needs it. This functionality is not used outside of this class so implementation would not be visible even if getters and setters were used.

I'm not sure which is the best spproach to take. Any advice would be very help.

Thanks,

Animaul

[Kareem Qureshi]

Hi,

From the way I am understanding your problem. You have to set the part name to get it where ever you need it.

More information would be helpful in giving a better answer.

Thanks
Kareem

[Ernest Friedman-Hill]

Hi,

Welcome to JavaRanch!

I know the article you're talking about. It's really quite sensationalist. Its merits have been debated here and elsewhere so I won't go into great detail, but basically, it describes a nice ideal which is worth striving for... sometimes, and sometimes not. Nothing in software design is so cut and dried as Alan tried to make it seem in that particular screed.

The main problem with that article, actually, is that people look at it quickly and decide "Oh, accessor methods are bad -- therefore I should make my member variables public." The article actually starts from the unstated proposition that member variables should never be public, but not everybody realizes that!

What's bad is the practice of automatically defining getX/setX methods for every X. If you don't really, truly need getX and/or setX, don't define them. Many, if not most, member variables should be "behind the scenes" in this way. But if some other class needs access to a value, the limited access offered by getX() and setX() methods is far superior to exposing the member variable directly.

Now, I'm not 100% sure I followed your precise question, so I'm hoping you can use the preceding to start trying to answer it for yourself. Note that if the choice is between passing a Part object around, putting the Part in a member variable, or passing a String around, the last one is actually best even if it makes the code a little more verbose, because it isolates more of the code from the details of the Part class. If you write all your methods so they just deal with the name as a String, rather than fetching the name themselves from a Part, then this makes it much easier to change how the code works in the future if, say, Parts suddenly have two different names, or names need to be localized, or some other change.

[Avogodro Morelli]

My apologies. I guess i thought it sounded clear then it does. I have an OID for a Part e.g. Part # 1223-001 has and OID of 12a.45.8. The OID makes that part unique in the database. The OID gets passed to a java class from a JSP. So the main in the java class has the OID when it is instantiated. So I can then created another object and pass in the OID e.g Thing thgPart = New Thing(OID); and then use String PartName = thgPart.getName to get the legable name of that Part. To get the name of the part to the method that needs it I can use getters and setters, a global, or pass PartName 4 times until it get to the method that needs to use it. I unfortunatly cannot pass it directly to the method that needs it.

Hope it is clear.

Thanks for the reply.

Animaul

[Avogodro Morelli]

Thanks for the help, and the welcome. Went with passing it as a parm until the method that needed it got it.

My apolgies. My alias on other forums is Animaul.

Thanks Again,

Avogodro

[Jeroen Wenting]

In your scenario I'd probably have a mechanism by which the class can set the product code itself from some other information you pass in (possibly doing validation on it first), and not give it a setter.

The class would then have a getter only, showing that the value is really read-only except for initialisation purposes.

As EFH points out, Allan Holub's views are not shared by many and his OO theories are not generally shared (in fact, a recent discussion on TSS pretty much concluded that he doesn't know what he's talking about and should stick to plain old C which he is an expert in).

[Ben Wood]

First off, I certainly do not profess to being an expert in OOD. I think some teaching courses probably do take the approach that every instance variable in a Java class should have accessor/mutator methods by default. In fact I was recently shown a CASE tool which follows these principles from a structure/class diagram when carrying out code generation.

I too thought this way for a while (after an initial phase of making every variable public, of course ...I'm not a CS graduate, and largely self-taught)

I think there is a happy, pragmatic medium to be found here. Relevance and practicality should be the guideline IMO. Don't provide getter/setter method pairs for variables by default before you even know how useful they will be. On the other hand, don't kill yourself trying to avoid using them if they work for the situation; I live in the real world, I'm not an OO guru, sometimes you just need to get stuff done without being too purist.

Generally, though, I agree that providing getters/setters for every variable as a matter of course is really not much better than just making them public!

[Stan James]

I have to jump in to Holub's defense a bit. I like about 85% of that article. The thing to take away is not that getters are evil which I assume was a deliberately provocative exaggeration, but any time you get data from an object and do something with it, ask yourself why the object that owns the data isn't doing the work. The number of acceptable reasons is not zero, but your definition of "acceptable" may vary.

Objects defined only by the things they can do for you have all private data and can play in some very cool designs. Try it now & then.

I'll try not to go on any longer ... the OO, UML etc. Forum is a better place for this stuff.

[Ernest Friedman-Hill]

Originally posted by Stan James:
any time you get data from an object and do something with it, ask yourself why the object that owns the data isn't doing the work.

That's why I said that this is a good goal to strive for... unless it's not. Depending on the kind of class you're writing, this either makes sense, or it doesn't.

If you're writing "component-like" classes: GUI components, EJBs, JavaBeans, DAOs -- it most decidedly doesn't, because all uses of those components can't be anticipated, and being "a bag of properties" is a big part of their purpose. The fact is that classes in this category may outnumber all other kinds, in terms of sheer workaday crank-it-out coding.

If you're writing heavily-used public classes, it also doesn't make a lot of sense. If you follow this advice blindly, you end up with "God classes" -- enormous classes that contain most of the code for a system, and have methods that do everything under the sun. This is no better than the coupling you were trying to avoid, as every class in a system gets intertwined with this big, ugly, nonportable monster God class.

But if you're writing classes with well-defined collaborations, especially groups of non-public classes that work together on a complex task, then what Holub says is true. This is the most fun kind of programming, and it's also the kind you should be doing in most academic settings. Unfortunately, for most working programmers, it's the kind you don't get to write too much of.

[Stan James]

There is no "right" answer, so I'm not going for Ernest's throat on this. I'm sure he's written and supported a ton more production Java than I have. But just for balance ...

I find the kinds of places where rigorously hidden data doesn't work to be "not very object oriented". (I have to wonder how much that matters in delivering function per dollar to my customer, tho.) I use these "anemic model" architectures, there are whole J2EE patterns based on it, but that doesn't make me think they are lovely to look at.

IOC is an interesting way to use composition to avoid "god objects" and nasty coupling. I have run into them before and they are their own kind of horror for sure. We used a PowerBuilder library called APOL that was based on putting everything anybody could ever possibly want in a superclass. Ouch!

So I don't disagree with anything Ernest said, but will urge us all not to give in too easily.
[ March 30, 2005: Message edited by: Stan James ]