Basic Concept - Clarification

[Sujatha Kumar]

OOPs concept statest that "an object should contain both data and action"

For instance if we consider a simple java bean with getters setters, it contains only data and it does not exhibit any action

Is that a simple java bean violating the basic concept?

Please Clarify

Regards
[ September 08, 2004: Message edited by: Sujatha Kumar ]

[Alvin chew]

hi, kumar...i think it not violate the oop concept, as you see, setter / getter is actually an action whereas for case of data, that will be the parameters that set or get from the setter/getter method ...

[Alexandru Popescu]

Very interesting. Are there any drawbacks in including the standard Java Beans some more behavior? I think that if the behavior included respects the OO paradigm than it cannot be anything wrong with it.

./pope

[Daniel Mayer]

Not everything in a good OO design must be a fully fledged object. Simple data structures, with only fields and no behaviour have their place, too.

As far as I know, there is nothing holding a bean from having behaviour, though.

[Stan James]

I wouldn't go so far as to call getters and setters behavior. Objects with no behavior are just structs. I did that in COBOL fer cryin out loud. They may be necessary in some architectures, but they're not very good objects and usually indicate some kind of breakdown of OO goodness.

Some of the best objects have behavior and state but completely hide their state. See The Paperboy & The Wallet (half way down) for a neat discussion of command methods vs query methods. And a link at the bottom of that page to Accessors Are Evil, a typical Holub over-the-top rant that has a lot to say if you can get by the outrageous bits.

[Lasse Koskela]

Originally posted by Stan James:
I wouldn't go so far as to call getters and setters behavior.

Unless those getters are named "getXxx()" to comply with the JavaBean naming convention and they really do have behavior hidden behind that seemingly accessorish face

[Stan James]

Originally posted by Lasse Koskela:

Unless those getters are named "getXxx()" to comply with the JavaBean naming convention and they really do have behavior hidden behind that seemingly accessorish face

I guess then they're not getters any more. Hmmmm, was that serious? Idunno yet.

I've done some little data-only objects to hold multi-part parameters and return values. To show that they are DATA ONLY objects I just make everything public, no gets & sets. C# has nice syntactic sugar to let you put get & set methods around a variable later without even telling the clients. They continue to do object.attribute and never know about the change.

[Al Korov]

Allen Holub's article "Why getter and setter methods are evil" addresses this issue a bit.

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

[Ernest Friedman-Hill]

I find these discussions (Is this practice OO? Is Java truly OO? Are JavaBeans OO?) to be quite tedious, because, outside of a computer science pop quiz, they're truly pointless.

Not only does the larger world not give out gold stars for being "really OO", but it's been more than a decade since object orientation was supplanted by component-based development as a major organizing factor. JavaBeans aren't supposed to be objects, per se (although of course they are): JavaBeans are components.

The principles of OO are but one tool in the toolbox. Component-based methods are another. Structured programming is yet another. They're all interrelated. Don't waste time worrying about whether what you're doing is truly OO. Worry about tangible things: simplicity, maintainability, understandability.

</soapbox>

[Al Korov]

Mr. Ernest,

I agree and I might disagree.

I agree that an important thing is to be a good all around developer, using ideas and technologies as appropriate.

I would like to point out, that for me at least, part of understanding when to apply an idea or technology stems from having first made the effort to really drill down into the thing, in order to understand its ins and outs and all of it peculiarities.

As long as conversations and explorations such as this one are done in that light, then it seems to me to be a healthy endeavor.

[Alexandru Popescu]

Originally posted by Ernest Friedman-Hill:
I find these discussions (Is this practice OO? Is Java truly OO? Are JavaBeans OO?) to be quite tedious, because, outside of a computer science pop quiz, they're truly pointless.

Sometimes they are, sometimes they aren't. A question about JavaBeans containing behavior doesn't look so pointless (at least for me). I also think that the beginners must be helped and guided.

Not only does the larger world not give out gold stars for being "really OO",

No, it doesn't, but some gold stars and gold money can be won if your systems will be rock-solid - this involving using the right stuff in the right place.

but it's been more than a decade since object orientation was supplanted by component-based development as a major organizing factor.

Even if the programming field shows many different orientations during the last years (component, soa, aop, etc), still I think we are producing mainly oo solutions.

Worry about tangible things: simplicity, maintainability, understandability.

And finally I do agree with this ;-).

./pope
[ September 11, 2004: Message edited by: Ali Pope ]

[Stan James]

If I don't stop and think about this stuff fairly often I wind up writing really good procedural functional decomposition. I did that for twenty years and it comes easy. I see it in my colleagues every day, too, even some recent CS grads. Making code that delivers the presumed benefits of OO is still high effort. Delightful, but high.

To summarize this question ... data only objects are necessary in some architectures, but they always raise a flag to me that I might be trying to write COBOL in Java. Their presence in a framework may raise a flag about the architecture, too.

The question of "How OO is this?" will never have an answer like "43.5" but some things will make you look twice to see if they really need to be there.

[Sujatha Kumar]

Hi guys,

Thanks for your postings.

Regards

[steve souza]

They may be necessary in some architectures, but they're not very good objects and usually indicate some kind of breakdown of OO goodness.

Although I wouldn't want to base my application on weak objects that have no real behaviour I think they have there use as value objects. I prefer to make them immutable if possible i.e. get rid of the setter methods. These value objects can be used to send data to and from ejb's for example.
[ September 28, 2004: Message edited by: steve souza ]