> 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.
and also making defensive copies of data in accessor methods. cheers dim > > 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". > =========================================================================== 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".
