| andrewmcdonagh 2007-01-30, 6:55 pm |
| 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....
|