>From Mike Bresnahan:
> .... But the
> audience crys out, "But your data is not encapsulated! How can this be
good
> object oriented design?". I answer this with a question, "How is the data
> less encapulated in a Tuple class than in a class where every data member
is
> accessable by a getter and setter function?" The crux of the issue is
that
> the data in a data processing application is NECESSARILY unencapsulated.
> For if the data was truely encapsulated, the application would perform no
> useful work because noone could see the data! The data is not something
> internal to the application, rather it is something public that the
> application is performing operations on.
>
I think this highlights the important difference between the *PROPERTIES* of
a component, and it's internal *STATE*. The two are not necessarily one and
the same, yet we tend to think of them as just "private fields, therefore
public get/set". If a component's properties can be maintained as state
handled elsewhere (as in the case of the Tuple or Row), then why not?
>From Bing Zheng:
> The getter/setter can enforce the integrity of the
> data, such as not allowing withdrawl if it will render
> account balance to be negative. If there is no data
> encapsulation, you have to proliferate this logic
> allow over wherever you want to touch that data.
>
Not if these rules are hidden inside of his Tuple or Row class. Merely
making them "public" doesn't inherently mean you've violated
encapsulation--and in many cases, encapsulation for no good reason leads to
unnecessary performance hits: high expense for no payout.
That stated, this is quickly degenerating into an "OO purism" thread, so I'm
bailing out; I have no desire to participate in religious discussion. For
those in the audience crying out, I recommend reading Scott Meyers "More
Effective C++", where he actually advocates the use of public data members
in certain cases, as well as some of James Coplien's writings, who was the
first to point out that private data members directly accessible via get/set
method pairs isn't really encapsulation at all--it's just extra work.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
http://www.clrgeeks.com/tneward
----- Original Message -----
From: "Mike Bresnahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 15, 2002 5:53 PM
Subject: Re: [EJB-INT] Off Topic: Architecture, Service-Based vs Classic OO
[was Re: date service]
> > Classic OO Approach:
> > Place the get/set methods for name, address, etc. AND the
> > getCustomersInRegion method in the Customer class.
>
> > Service-Based Approach:
> > ONLY place the get/set methods for name, address, etc. in a
> > CustomerBean class, and place the getCustomersInRegion method - and all
> > other non get/set data methods - in a seperate CustomerService class.
>
> I believe both these approaches are actually at odds with good object
> oriented design. I think it is bad design because it results in multiple
> classes with the same basic responsibilities: hold data, present data.
> Whether it is a Customer class with a bunch of getters and setters or an
> Account class with a bunch of getters and setters, the basic
> responsibilities are the same and thus the functionality is the same.
This
> redundancy leads to software bloat: often hundreds of boring classes. As
a
> band-aid for the management problems associated with this code bloat,
people
> have developed all sorts of fancy and complex "tools", e.g. code
generators.
>
> I believe that good object oriented design applied to this problem begs
for
> more abstraction. All of the boring getter-setter classes can be replaced
> by one data holding-presenting class, e.g. class Tuple or class Row. The
> business logic is kept in separate business processing classes. But the
> audience crys out, "But your data is not encapsulated! How can this be
good
> object oriented design?". I answer this with a question, "How is the data
> less encapulated in a Tuple class than in a class where every data member
is
> accessable by a getter and setter function?" The crux of the issue is
that
> the data in a data processing application is NECESSARILY unencapsulated.
> For if the data was truely encapsulated, the application would perform no
> useful work because noone could see the data! The data is not something
> internal to the application, rather it is something public that the
> application is performing operations on.
>
> Mike Bresnahan
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
