Re: Simple question

Responding to Dbcuser...

I have a question on what should be a class and what should not be a
class.
I have customer class, employee class [Employee who provides service to
customer]. In this both the class has address in it. Do you think it is
correct to create a address class and use the address class in both
customer and employee class?


The answer is a definite Maybe.  B-)

In this case it /seems/ like Customer is a quite different entity than Employee. In fact, when they interact, one would expect them to have different identities and, consequently, different addresses. So semantically the address of a Customer is not the same as the address of an Employee in the contexts where they interact.

In fact this is quite common. One has a Porche automobile and a Roulette chip that both have a 'color' attribute and both may have a 'blue' value of that attribute. But the notion of color context is semantically distinct. In fact, in such cases it is often useful to think of the attribute as 'color of' rather than 'color'. (Though one is not going to tediously clutter one's Class Model with such suffixes.)

However, there may be contexts where the same entity can be either a Customer or an Employee. In that case the semantics of address may be the same (e.g., the place where the <single> entity lives). In that case there may be a need to break out an Address class that is related to both.

However, there are alternatives, usually involving subclassing. One is direct subclassing:

                    [Person]
                    + Name
                    + Address
                        A
                        | R1
      +-----------------+-------------------+
      |                                     |
 [Customer] -------------------------- [Employee]
            * serves      R2           1

This is fine as long as a Person is always either a Customer or an Employee in the problem context. But is is awkward (requiring deletion and re-instantiation of instances) if the Person can migrate between roles during the problem solution.

Another variation is through delegation of a role (e.g., via the GoF State pattern):

      R2
+--------------+
|              |
|  serves *    | 1   *     R3       plays 1
+---------- [Person] ---------------------- [Role]
            + Name                            A
            + Address                         | R1
                                     +--------+-------+
                                     |                |
                                 [Customer]       [Employee]

This works well when the same Person can play either role during the solution. One just has to make sure that the R3 relationship is instantiated properly for the /particular/ participants on either end of the R2 collaboration. That is, when the context of the collaboration changes for a particular Person, then R3 has to be updated.

Bottom line: it all depends on what semantics one must capture from the problem space to solve the problem.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: move data from list box or combo box to another list
    ... employees is because each employee gets paid commission on the service they ... The customer and dates are ... Lets address your problem with your report which seems to be your main ... Oh yeah and also you should/could have a filter in your query so that your ...
    (microsoft.public.access.forms)
  • Re: Databinding - Best Practice (object-oriented)
    ... > Because it does not expose individual objects like Employee or Customer, ... OO is not for data management. ...
    (microsoft.public.dotnet.framework.windowsforms.databinding)
  • Re: Databinding - Best Practice (object-oriented)
    ... > Because it does not expose individual objects like Employee or Customer, ... OO is not for data management. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: adding existing parent object to extended child object?
    ... customers, employee and suppliers. ... a customer may be either an individual or a company ... a supplier may be either an individual or a company ... and delegate every 'human' specific message to it (you can ...
    (comp.lang.php)
  • Re: Design problem and suggestions...
    ... A "context" table can hold person & role. ... > the both employee and customer. ... please post details of your proposed schema e.g. the new ...
    (microsoft.public.access.tablesdbdesign)