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.
Bing --- Mike Bresnahan <[EMAIL PROTECTED]> wrote: > 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 > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com =========================================================================== 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".
