Re: Of Java and C#

On Jan 30, 2:02 am, LX-i <lxi0...@netscape.net> wrote:
> andrewmcdonagh wrote: 
> 
>
> Well, I forgot to e-mail the source to myself...  :(  But in the mean
> time, I have a question for you seasoned OO folks...
>
> Say, for example, that there is a library application where there is a
> "book" object with a method of checkMeOut(), that takes a patron object,
> and modifies it to indicate that it is now checked out by the given patron
.
>
> Assuming that this is a persistent application, at what point is the
> information stored off?  Does checkMeOut() do the work of updating the
> database *and* updating the object in memory, or should there be a
> separate commitChanges() method that would update a data store with the
> information contained in the current instance of that object?
>

Like all good things ...it depends......


:)

Its common for Classes like this to also do the data persistence, or
at latest, call a method on their base class to do so.

However, its usually a better (aka looser coupled, high cohesive
design) for another class to be responsible for the persisting.

A standard OO Design Pattern for this example does exist called: Model
View Presenter (googleable)

Simplistically this pattern is designed to break up the handling of
Seeing(View) interacting with (Presenter) and changing the database
(model)

So for a Book class, I'd say the Model (aka Library?) knows who's got
what Book and the Presenter decides what/how to show the book and its
check out history and finally the View translates that info into
events and API calls that the platforms UI library understands.

but like I say, it depends...  there's always multiple ways of doing
this... and a Book knowing it checkout history is one of them....