Re: Design Question

From: Nunaya (nunaya2004_at_yahoo.com)
Date: 04/25/04 

Date: 24 Apr 2004 19:21:35 -0700

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<q6qk80d8r8jujithgcf8t4lsji475h5gia@4ax.com>...
> On 22 Apr 2004 19:45:03 -0700, nunaya2004@yahoo.com (Nunaya) wrote:
>
> >We have developed two objects called "customer" and "salesrep". For
> >simplicity, assume that these two objects will talk directly to a
> >database. The database has three tables: customers, customersalesreps
> >(allows multiple salesreps to be associated with a customer), and
> >salesreps. The customer object has business rules that allow
> >manipulation of customer information (add,update,delete,select,etc).
> >The salesrep object has business rules that allow manipulation of
> >salesrep information (add,update,delete,select,etc).
> >
> >Question 1: Where is the proper place to put a method called
> >"AddCustomerSalesrep" that adds a new salesrep to the
> >customersalesreps table with the customerid and salesrepid? Is it in
> >the customer or salesrep object? (Or is it in a third object we
> >should create called "customersalesrep"?)
> >
> >Question 2: Assume one of the business rules desired is to validate
> >the salesrepid prior to adding a new salesrep to a customer. Also
> >assume that the salesrep object already has a method called
> >"issalesrepvalid" which takes a salesrepid and makes sure it exists in
> >the salesreps table. If we put AddCustomerSalesrep in the customer
> >object, would we want to validate the salesrepid by having the
> >customer object instantiate the salesrep object and call the method
> >called "issalesrepvalid"? Does this break the principle of
> >encapsulation or is there a better way to design this?
> >
> >Thanks in advance for any insight.
>
> You are allowing the structure of the database to pollute your
> thinking. The structure of the database (i.e. the tables) are details
> that you should ignore for the time being. Instead, build your
> Customer and SelseRep classes without any knowledge of the database at
> all. Don't even admit that there *is* a database. Get your
> application working in RAM first, then add the database as your last
> step.
>
> This will force you to focus on business rules. It will cause the
> structure of your classes and objects to support the business rules
> first. Then, later, as you need persistence, you can shim the
> database behind the business rules in a way that does not warp the
> object model.
>
>
>
> -----
> Robert C. Martin (Uncle Bob)
> Object Mentor Inc.
> unclebob @ objectmentor . com
> 800-338-6716
>
> "Distinguishing between the author
> and the writing is the essence of civilized debate."
> -- Daniel Parker

You are absolutely right in saying to disregard the database. I could
not agree with you more on this. As we work on our object model, we
are trying to ignore the database. My example included references to
the database for the sake of clarity only.

Given the fact that there is a customer and salesrep object, and
interaction is required between the two to ensure a valid salesrep is
being added to a valid customer, should another object be introduced
that uses both objects to perform that function? I have been reading
about a facade layer that perhaps is the key to this issue.

I like your website very much. There is a tremendous amount of very
good information on it. Thank you for your help.

Relevant Pages

  • Re: Design Question
    ... The database has three tables: ... The customer object has business rules that allow ... >salesrep information. ...
    (comp.object)
  • Re: Design Question
    ... The database has three tables: ... The customer object has business rules that allow ... >salesrep information. ...
    (comp.lang.java.programmer)
  • Re: Design Question
    ... The database has three tables: ... The customer object has business rules that allow ... >salesrep information. ...
    (comp.lang.cpp)
  • Re: Design Question
    ... The database has three tables: ... The customer object has business rules that allow ... >salesrep information. ...
    (microsoft.public.dotnet.general)
  • Re: Design Question
    ... >> to attempting to add the salesrep to a customer. ... >> layer do the validation itself. ... > If the user is merely trying to identify a sales rep and one is checking ...
    (comp.object)