[Newbie] Object Relationships

What would be the standard ways to code a relationship between classes where 
the relationship between instances in 1-to-1 going one way & many-to-1 going

the other way? For example, a Book could be checked out by only one Person &

a Person can check out many Books. Do the objects maintain links to one 
another, both of which must be updated each time a book is checked out or 
returned? Or, do you code an intermediate class to represent the link 
between a Book and Person?

Thanks, as always -- Al 

Thanks for the welcome ... Very impressive--do people always get a response
to their messages ten minutes after posting? :-)

First, have no fear about me trying to do anything the way I would in a
relational database--I don't know anything about them, either.

Next, I have to admit, I only used the book example because I get tired of
authors always talking about customers and invoices--I work in a university.
I got students, not customers :-) Thinking about a library, though, I can
certainly see that people might want to reserve a book, and that this would
be another thing to code. I guess I can picture a Librarian object whose job
was to interact with Book and Person objects, but I have to admit my brain
cells are only a little stirred so far.

Thank you, though! -- Al

----- Original Message ----- 


|
| Hi Alan, welcome to the funny farm :-)
|
| Can I start by giving you a warning about trying to connect classes in
| the same kind of way that you would set up a relational database.
|
| In the scenario that you give, you have to consider, not only the Book
| and the Person but also the idea of a Loan, possibly a Reservation.
|
| Then you have to consider that a Loan may be an item in a list
| maintained by a "Librarian".
|
| Does that start to stir the brain cells ? :-)
|
| Joanna
|
| -- 
| Joanna Carter [TeamB]
| Consultant Software Engineer

"Alan Colburn" wrote
> returned? Or, do you code an intermediate class to represent the link
> between a Book and Person?

No one right way--depends on the specific domain.

In this particular case, a checkout record has important characteristics of
its own that don't belong to either the book or the person:
CheckoutDatetime, returnDueDate, LibraryAgent (who checked it out), possibly
branch, etc., so you'd want a specific CheckoutRecord class.

In general, you usually generally always want a relational class if the
relationship is characterized.

bobD

Alan Colburn a écrit :

> What would be the standard ways to code a relationship between classes
where 
> the relationship between instances in 1-to-1 going one way & many-to-1
going 
> the other way? For example, a Book could be checked out by only one Person
& 
> a Person can check out many Books. Do the objects maintain links to one 
> another, both of which must be updated each time a book is checked out or 
> returned? Or, do you code an intermediate class to represent the link 
> between a Book and Person?

Hi Alan, welcome to the funny farm :-)

Can I start by giving you a warning about trying to connect classes in 
the same kind of way that you would set up a relational database.

In the scenario that you give, you have to consider, not only the Book 
and the Person but also the idea of a Loan, possibly a Reservation.

Then you have to consider that a Loan may be an item in a list 
maintained by a "Librarian".

Does that start to stir the brain cells ? :-)

Joanna

-- 
Joanna Carter [TeamB]

Hi Bob--

Thanks for the response. I smiled at the sentence that started "In general,

you usually generally always want..." I do understand what you're saying, 
though.

Thanks again; I appreciate it -- Al

"Bob Dawson" <bdawson@idtdna.com> wrote in message 
news:47e2cc08$1@newsgroups.borland.com...
> "Alan Colburn" wrote
>> returned? Or, do you code an intermediate class to represent the link
>> between a Book and Person?
>
> No one right way--depends on the specific domain.
>
> In this particular case, a checkout record has important characteristics 
> of
> its own that don't belong to either the book or the person:
> CheckoutDatetime, returnDueDate, LibraryAgent (who checked it out), 
> possibly
> branch, etc., so you'd want a specific CheckoutRecord class.
>
> In general, you usually generally always want a relational class if the
> relationship is characterized.
>
> bobD
>
>