OOP Design Question

[Scott Stark]

Hello,

I'm just getting started in OOP programming so please forgive the question
if it's a bit basic. I'm trying to wrap my head around the basic principles
of OOP design methodologies and think that if someone can explain the
following, it might help me a bit.

Let's say I have four classes for an e-commerce website: a class named
Customer, which contains a collection of Order objects (the orders they have
placed) which in turn contains a collection of OrderItem objects, which in
turn contains a reference to an individual Product object (or an object that
inherits from the base class Product).

Can someone explain to me how best to design this? My specific questions
are:

1) What is the best way to contain the list of, say, Orders in the Customer
class? A generic collection?
2) Which classes need to implement IEnumerable and IEnumerator in order to
loop through them?
3) Where would I place a function called GetCustomers which returns a list
of all my available Customer objects?
4) What if I wanted customers whose first name was John?
5) If I wanted to be able to do something like

Dim NewCustomer As Customer = New Customer
NewCustomer.FirstName = "John"
NewCustomer.Save()

Where the Save() method persists the data to a database, is that the
appropriate way to do it?

6) What if I wanted a function GetOrderItems(ByVal OrderID As Integer) to
get a collection of OrderItems for a particular order number? Where would
this function be placed? I guess my thought is that it would be a member of
the Order class, but is that the best place for it or is there another
accepted way to do this?

I think you probably get the idea of where my confusion lies. I don't need
code examples of how to actually IMPLEMENT this functionality, I just need
class definitions and the method signatures so I can see where everything
should go, what types should be used (for the collections), etc.

Any help would be very much appreciated.

Thank you,

Scott

 

[Cor Ligthert[MVP]]

Scott,

Forgive me, but your question seems not have to do much with OOP
programming, but more in general with programming.

My advice, just start with a Hello world program. Then you can see how to
use OO for your data classes, although OO gives you direct then problems as
you use SQL type databases (and that are them all at the moment) as those
are build around relations and not arount OO principles as inheriting and
things like that.

Cor
..

 

[Lloyd Sheen]

Hello,

I'm just getting started in OOP programming so please forgive the
question if it's a bit basic. I'm trying to wrap my head around the
basic principles of OOP design methodologies and think that if someone
can explain the following, it might help me a bit.

Let's say I have four classes for an e-commerce website: a class named
Customer, which contains a collection of Order objects (the orders they
have placed) which in turn contains a collection of OrderItem objects,
which in turn contains a reference to an individual Product object (or
an object that inherits from the base class Product).

Can someone explain to me how best to design this? My specific questions
are:

1) What is the best way to contain the list of, say, Orders in the
Customer class? A generic collection?
2) Which classes need to implement IEnumerable and IEnumerator in order
to loop through them?
3) Where would I place a function called GetCustomers which returns a
list of all my available Customer objects?
4) What if I wanted customers whose first name was John?
5) If I wanted to be able to do something like

Dim NewCustomer As Customer = New Customer
NewCustomer.FirstName = "John"
NewCustomer.Save()

Where the Save() method persists the data to a database, is that the
appropriate way to do it?

6) What if I wanted a function GetOrderItems(ByVal OrderID As Integer)
to get a collection of OrderItems for a particular order number? Where
would this function be placed? I guess my thought is that it would be a
member of the Order class, but is that the best place for it or is there
another accepted way to do this?

I think you probably get the idea of where my confusion lies. I don't
need code examples of how to actually IMPLEMENT this functionality, I
just need class definitions and the method signatures so I can see where
everything should go, what types should be used (for the collections), etc.

Any help would be very much appreciated.

Thank you,

Scott

Scott,
Which version of VS are you using? Are you planning on keeping the
data in SQL Server?

Is the application web based or Windows Forms based?

The reason for asking is that in VS 2008 there are new technologies
that may help you in your design.

LS

 

[Mr. Arnold]

Hello,

I'm just getting started in OOP programming so please forgive the question
if it's a bit basic. I'm trying to wrap my head around the basic
principles of OOP design methodologies and think that if someone can
explain the following, it might help me a bit.

Let's say I have four classes for an e-commerce website: a class named
Customer, which contains a collection of Order objects (the orders they
have placed) which in turn contains a collection of OrderItem objects,
which in turn contains a reference to an individual Product object (or an
object that inherits from the base class Product).

Can someone explain to me how best to design this? My specific questions
are:

1) What is the best way to contain the list of, say, Orders in the
Customer class? A generic collection?

A generic or strong typed collection.

2) Which classes need to implement IEnumerable and IEnumerator in order to
loop through them?

For what? You just make a method within the class to loop through the
collection with a For or For each loop the collection is IEnumerable.

3) Where would I place a function called GetCustomers which returns a list
of all my available Customer objects?

In the Customer that deals with all things Customer.

4) What if I wanted customers whose first name was John?

You pass John as a pram to Customer class called GetCustbyFirstName

This is just off the top of my head.

Function GetCustbyFirstName(custs as Collection, fn as String) as ArrayList

dim new arraylist

for each cust as Customer in custs
if cust.fn = fn then
arraylist.add(cust)
endif
next

return arraylist
end function

5) If I wanted to be able to do something like

Dim NewCustomer As Customer = New Customer
NewCustomer.FirstName = "John"
NewCustomer.Save()

Where the Save() method persists the data to a database, is that the
appropriate way to do it?
Yes


6) What if I wanted a function GetOrderItems(ByVal OrderID As Integer) to
get a collection of OrderItems for a particular order number? Where would
this function be placed? I guess my thought is that it would be a member
of the Order class, but is that the best place for it or is there another
accepted way to do this?

It would be in the Order class/object, dealing with Orders.

I think you probably get the idea of where my confusion lies. I don't need
code examples of how to actually IMPLEMENT this functionality, I just need
class definitions and the method signatures so I can see where everything
should go, what types should be used (for the collections), etc.

What you need to know is OOP design concepts. OOP is OOP no matter if it's
Java or .Net. The book is in Java, which is not that hard to read and
understand, but it applies to .Net too and using OOP concepts.

<http://books.google.com/books?id=Lj...=X&oi=book_result&resnum=4&ct=result#PPR10,M1>

 

[James Hahn]

My impression is that you are confusing the OOP principles that you will
apply in building the software with the relationships that will be needed in
your database to maintain your data in the form that you need it.

"a class named Customer, which contains a collection of Order objects" isn't
the way I would describe it. A better way to think of it is "a class named
Customer which includes a mechanism for relating to a subset of items of the
class named Orders, which in turn contains a mechanism for relating to
subset of items of the class named Products" and so on. In other words,
each class includes the methods and properties that enable you to build a
data structure such as a customer, their orders and the products for those
orders, or a data structure such as a product and the orders for that
product and the customers for those orders, and so on. But the classes you
are talking about aren't the data structures. Exactly what those data
structures look like will depend on the database you are using to store the
data records - the database might dictate what they will look like, or you
might build it for yourself, using, for example, collections objects (and
which, of course, you might also build as a class).

For example, for one database I use regularly, the customer class includes a
customer identifier that will be used as a pointer into the database that
will return a linked list of the Order records for that customer. That is,
in facat, a universal id for the customer, so the Customer class actually
has no properties that refer specifically to Orders. To retrieve and process
the list I use another class - the CustomerOrders class. An alternative
design would merge the Customer class and the CustomerOrders class. The
reference to the customer's orders would still be by reference to the linked
list rerieved from the database, but the orders would appear to be a
collection property of the Customer class. In this case it would be fair to
say that an instance of Customer contains a collection of Order objects, but
internally this is implemented as (1) a call to the database to return the
linked list and (2) the linked list itsef, which is actually a list of
pointers into the Orders records in the database. So the class definition
depends heavily on the database design, the methods availble for database
access, and the design decisions made about the class structures used for
managing the database.

Select your database and design your data layout first. Then build the
software to manipulate it according to the customer requirements, using the
methods provided by the database engine.

 

[Terry]

Well after spending 30 minutes typing a responce and hitting the post button,
MS told me the site was too busy and lost my post! So here is a much shorter
version...
Think of an object and a collection of that object as 2 different classes.
So OrderItem is one class and OrderItemList is another class.
I implement my 'list classes' by inheriting from
ComponentModel.BindingList(Of ?)
for example
Public Class OrderItemList
Inherits ComponentModel.BindingList(Of OderItem)

and then use 'factory methods' to actually creat the lists

'Create an empty list'
Public Shared Function Create() as OrderItemList
Return New OrderItemList
End Function

'Create a list for a given Order Id
Public Shared Function Create(ByVal Id as Integer) as OrderItemList
' need to get the data from the datastore, create a new OrderItem for each
record,
'add it to the list and return the list
End Function

 

[sloan]

Take a look here:
http://sholliday.spaces.live.com/blog/cns!A68482B9628A842A!140.entry

This isn't really an OOP question.

.......

I would seperate the Entity classes (Customer Order OrderItem) away from the
class(es) which create them.

CustomerController or CustomerManager would be a good name.

CustomerManager cm = new CustomerManager ();
cm.SaveCustomer(c);

Get the code that does CRUD operations out and away from the Entity classes
themselves.

 

[Man T]

CustomerController or CustomerManager would be a good name.

CustomerManager cm = new CustomerManager ();
cm.SaveCustomer(c);

Yes, this is the way many experts suggest.
ie. Customer should NOT have method to save itself. eg. Customer.Save();
This is not correct.

It should as you suggested
cm.SaveCustomer(c);