Re: Of Java and C#

On Jan 30, 2:02 am, LX-i <lxi0...@xxxxxxxxxxxx> wrote:
andrewmcdonagh wrote:
Doh...oh yes re-reading your post I see that now... Saw the talk
about Java and missed the c# connection to the class.

Not to worry though...whilst I don't know the full c# library yet I
do know OO and c#'s approaches so if you want....

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....




.

Relevant Pages

  • Re: LISP is dead now ! ! !
    ... It seems to me the design pattern stuff is ... > You sound like a HUGE advocate of design patterns then, and also UML. ... then it is probably a design pattern of some kind. ... >> management around that knows when to get involved and when to butt ...
    (comp.lang.lisp)
  • Re: ReaderWriterLockSlim + Dispose?
    ... It's a bad design because it has code that tries to do something, but because you haven't designed the code to be reliable, you wind up having to add a bandage to catch the fact that the code isn't reliable. ... Opening a file and catching a possible failure is nothing like the design pattern you're using. ... the "open file" pattern you describe is just as flawed as the "catch disposed exception" pattern you're promoting. ... of mindset, a real programmer see's a problem, and accoplish's it. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Whats the design pattern here?
    ... > solutions to specific problems like command line parsing so they can be ... I think a lot of people are using the term "design pattern" ...
    (comp.object)
  • Re: perplexed with code reuse and adopt design pattern in C
    ... layers of data abstraction. ... range then you can reuse the peripheral C functions over and over. ... I did read many great books related with design, coding, ... I go through "head first design pattern" again. ...
    (comp.arch.embedded)
  • Re: Fill in fields
    ... >filled in Presenter combo box. ... >I want to put code behind the OnUpdate or OnExit event of the Presenter ... unnecessary, and bad design. ... RowSource query; put textboxes on the form, ...
    (microsoft.public.access.formscoding)