Newbie: Design Question

[GiJeet]

Hello, I'm new to OOP and C# and I have a design question.

Hypothetically, let's say I have a bookstore business with stores in
several locations. I get a shipment of books into my central
warehouse. I then need to distribute the books to different stores.
When new books get added to a store, I want to fire an event that will
notify people local to that bookstore that a new book in the category
of their interest has arrived so they can come in and look it over -
and hopefully buy.

Now I have a book class and a bookstore class. I want to create a
book instance for each book (title, author, isbn, price, category,
etc.) received and I want to create a bookstore instance of each
location.

So here's the design question:

I was thinking of having an AddToStore method in the book class and an
array list of bookstores as part of each book instance. Then I call
the AddToStore method and the book will loop thru it's array of
bookstores and add itself to each bookstore, since in real life that's
what we do - we add books to bookstores.

However, then I have the same instance reference of the book at each
store right?. This defeats the idea of having an individual
WasNoticeSent flag on the book to indicate that a notice was sent to
the local customers for this book from a specific bookstore. That is,
if I set the flag for bookstore1 to true, then when bookstore2 goes to
check if the notice was sent for the customers of that store the flag
will indicate it was and it really wasn't. Maybe clone each book for
each store?

Or....should I loop thru the bookstores and create a separate instance
of each book for each bookstore. This seems like extra work since
most of the information for a book doesn't change for each bookstore -
same title, isbn, price, etc.


TIA
Gi

 

[Peter Duniho]

[...]
So here's the design question:

I was thinking of having an AddToStore method in the book class and an
array list of bookstores as part of each book instance. Then I call
the AddToStore method and the book will loop thru it's array of
bookstores and add itself to each bookstore, since in real life that's
what we do - we add books to bookstores.

However, then I have the same instance reference of the book at each
store right?.

Yes, if you keep reusing that same instance.

This defeats the idea of having an individual
WasNoticeSent flag on the book to indicate that a notice was sent to
the local customers for this book from a specific bookstore. That is,
if I set the flag for bookstore1 to true, then when bookstore2 goes to
check if the notice was sent for the customers of that store the flag
will indicate it was and it really wasn't. Maybe clone each book for
each store?

Or....should I loop thru the bookstores and create a separate instance
of each book for each bookstore. This seems like extra work since
most of the information for a book doesn't change for each bookstore -
same title, isbn, price, etc.

Your heart is in the right place. Yes, it would be wasteful to create
a new instance of a class that contains non-variant information about the
book for each physical book.

I haven't done any inventory control software, but from what I've seen, it
seems to me that they generally maintain the stock item information
separately from the inventory item information. That is, you'd have a
single "stock item" that represents the archetype of the inventory item,
in which is contained all of the non-variant descriptive stuff. For a
book, this would those things you described: title, author, ISBN,
suggested price, publisher, etc.

Then for each store, you'd have an inventory item that refers to that
stock item. The inventory item would contain at a minimum two things: an
in-store inventory count of the item, and a reference to the stock item
instance. Depending on how the stores work, you might actually have an
actual price field (if different stores are allowed to price items
differently...to support a clearance sale at one store, for example).

Finally, you've said you want to handle things like notices to customers.
One approach would be to skip the "in-store inventory count" I mentioned
above and just create a new instance of the inventory item class for each
actual book a store might receive. However, I think this would probably
be wasteful, since the vast majority of books will never have any
customer-specific data in them. Instead, I think it probably makes more
sense to maintain a list of customers attached to each inventory item
class. The customer-specific class would contain whatever details are
relevant (including, if appropriate, a reference to a global customer data
class)

Of course, if books can be set aside for customers, then in that inventory
item class you'll probably also want to track a separate count related to
the number of customers that have already been promised a book. This
might be as simple as just the length of the list of customers, or
depending on how the business works you might have some customers who have
paid for the book or otherwise made a claim to one, while others only
requested some sort of notification and thus don't represent an actual
claim on a book. How to do this would depend on specifics to your data
management.

The above is just one option. It's not the only one, and alternatives
might be correct as well (maybe better, maybe worse). For example, you
could maintain inventory globally, with a single inventory item class that
keeps a list of all stores where that item is stocked and how many
instances the store has. Or you could link the structures both ways, with
the inventory items having a list of stores and inventory in each store,
while each store has its own list of inventory items and count of items
there. Or you could store the count in just one or the other; since each
has a reference to the other, whichever class doesn't store the count
could just refer to the class that does have the count.

There are numerous variations, and to some extent you just need to decide
for yourself what works best given how the stores operate.

Finally, all of the above assumes a straight in-memory data structure
describing the situation. I think in reality you're probably going to
have a relational database, with tables for stores, books, inventory,
customers, etc. So, as you put everything together, obviously you'll want
to keep in mind how these data structures map into and out of the database.

Pete

 

[Roger Frost]

What you're really needing is a database for your hypothetical bookstore
business, and a nice front end to manage it all...

Hello, I'm new to OOP and C# and I have a design question.

Hypothetically, let's say I have a bookstore business with stores in
several locations. I get a shipment of books into my central
warehouse. I then need to distribute the books to different stores.
When new books get added to a store, I want to fire an event that will
notify people local to that bookstore that a new book in the category
of their interest has arrived so they can come in and look it over -
and hopefully buy.

Your front end application will handle this, when you add new inventory to
your database, you will send a notice to your stores (or whomever) with the
details. If you add several items, you can do it as a single notice rather
than one by one, basically at the end of an "add session" you will send the
notices.

Now I have a book class and a bookstore class. I want to create a
book instance for each book (title, author, isbn, price, category,
etc.) received and I want to create a bookstore instance of each
location.

In the application, you don't need an instance of each object (book or
store) open at all times. When you need to access an object, you create an
instance of it (filled with the data from the db) to perform the updates on.
When your not "using" something, your object's fields such as title, author,
isbn, etc (or name, address, manager's name, etc in the case of a store)
will remain in the database.

So here's the design question:

All ready?

I was thinking of having an AddToStore method in the book class and an
array list of bookstores as part of each book instance. Then I call
the AddToStore method and the book will loop thru it's array of
bookstores and add itself to each bookstore, since in real life that's
what we do - we add books to bookstores.

Yeah, but books don't add themselves to stores in "real life" do they?

However, then I have the same instance reference of the book at each
store right?. This defeats the idea of having an individual
WasNoticeSent flag on the book to indicate that a notice was sent to
the local customers for this book from a specific bookstore. That is,
if I set the flag for bookstore1 to true, then when bookstore2 goes to
check if the notice was sent for the customers of that store the flag
will indicate it was and it really wasn't. Maybe clone each book for
each store?

Hypothetically, rather than having each book keep track of if it's notice
was sent, each store would have a list of books it has (or hasn't yet) sent
notices about....since in real life that's what we do...

Or....should I loop thru the bookstores and create a separate instance
of each book for each bookstore. This seems like extra work since
most of the information for a book doesn't change for each bookstore -
same title, isbn, price, etc.

This is what relational database design is all about.


Just how hypothetical was this question anyway?