views:

163

answers:

5

I have a scenario at hand which has some design discussion going on. To break it down in simple words, think about a hierarchy as such Company -----> Customer ------> Orders (ignore the details of how the orders have products etc) if I was to expose an API to work with this, what would be a better design.

a)

Dim comp As New Company
comp.GetInfo(123)
Dim cust As New Customer
cust.Name= "CustomerName"
comp.Add( cust)

b)

Dim custhand As Customerhandler
Dim cust As New Customer
cust.Name= "CustomerName"
custhand.AddCustomer(cust,123)  ''123 is CompanyID
+1  A: 

A. Using an ID when you should use an object is a bad idea.

Andrew Clark
+1  A: 

Choosing between the two, I'd choose A, adding a CustomerHandler seems like overcomplicating: either the Company or the Customer should know how to add a Customer to a Company.

Lennaert
A: 

I prefer the first method as it is most directly to the point. You create a company object and add a customer to it. Makes sense.

The second method introduces an "er" object which just makes things more difficult to understand and more procedural.

Boden
A: 

A. The cust object should contain the ID within it, not separate from it.

You might be interested in an Customer.AddCustomer(string, int) overload that makes a new customer with a given name and ID though, but that depends on how you're storing information.

lc
+8  A: 

I'd go with (A) but I'd be inclined to change...

Dim comp As New Company
comp.GetInfo(123)

into...

Dim comp As Company = Company.Get(123)

(so add a new shared method to the Company class to return a specific instance of Company)

Chris Simpson
ah, you beat me to it :P +1
rmeador
the advantage here, in case it isn't obvious, is you never have an invalid (i.e. unloaded) Company object kicking around. You can't ever forget to call the GetInfo() function on it, etc.
rmeador
+1 for Factory Pattern usage
Gavin Miller