Re: Objects and Relations

On Feb 18, 1:05 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Jan 29, 1:42 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> <snip>
>
>
>
> > 1. OO is good for string, deque, front ends, simulations, games
> > 2. RM is good for storing information about Employees, Students,
> > University courses, Inventory systems, Invoices.
>
> > These predictions are borne out in practice.
>
> David -- I just hit me that perhaps this entry where I show that the
> RM is not sufficient would make clear why one needs to model such
> thing as Employees in OO (if using an OO language to write an app).
> An OO class of Employee need not just be used to model an 'entity' for
> persistence (for use with a DBMS), but also models such an entity for
> use in a UI. And I think you will agree that the RM is not sufficient
> for all such modeling.
>
> http://www.tincat-group.com/mewsings/2006/02/model-behind-interface.html
>
> If your response is that it is OK to model Employee in OO for
> potential use in a UI, just not for storage, then I misunderstood your
> comments about how we should not model "external entities" in OO. So,
> is this relevant or am I still not understanding your original point?
> Thanks. -dawn

To me it comes down to whether an object of class Employee actually looks and feels. like an employee with its own independent identity in the context of the abstract machine. I ignore everything outside the machine and ask whether the object is what it claims to be. Employees do things like do work, get paid and go on holidays. If those behaviors don't make sense for the object in the context of the machine then it has no right to be thought of as an Employee.

OO focuses attention on objects and their *behaviour*. A well named class reflects its behaviour. If a class is merely used to store some information then make that clear. More importantly, be prepared to consider using RM because it seems far better suited to that purpose.

Consider the following two examples

struct CDPlayer1
{

    Colour m_colour;
    float m_price;
    int m_modelNumber;
    int serialNumber;
    Date m_purchaseDate;
};

class CDPlayer2
{
public:

    void Play();
    void Stop();
    void PrevTrack();
    void NextTrack();
    void Eject();

private:

    ...
};

An instance of CDPlayer1 is not a CD player at all. It is merely some info about a CDPlayer.

By contrast CDPlayer2 represents a device that can indeed be called a CDPlayer. This could be very real to the extent that calling Eject() actually causes the CD Player in the computer to eject. Alternatively Eject() may only affect an animation of a CDPlayer on the screen. Even more abstractly, it may only represent a CD player that exists in the sense of a simulation.

My suggestion is not simply renaming CDPlayer1 as CDPlayerInfo. Rather, I suggest using RM to represent the information recorded by CDPlayer1 and stop misusing OO. Received on Mon Feb 19 2007 - 03:34:19 CET