Re: Design Question

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 04/24/04

  • Next message: Robert C. Martin: "Re: ASCII Text notation of UML diagram"
    Date: Sat, 24 Apr 2004 08:20:29 -0500
    
    

    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


  • Next message: Robert C. Martin: "Re: ASCII Text notation of UML diagram"

    Relevant Pages

    • 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)
    • Re: Design Question
      ... The customer object has business rules that allow ... >>the salesrepid prior to adding a new salesrep to a customer. ... The structure of the database are details ...
      (comp.object)