NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/19980

Text File | 1993-01-23 | 4.8 KB | 147 lines

Xref: sparky comp.lang.c++:19980 comp.object:5078
Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!hal.com!olivea!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!sgiblab!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: HELP : Array of objects of diff classes ??
Message-ID: <[e-mail]>
Date: 26 Jan 93 21:08:37 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Lines: 133
Nntp-Posting-Host: extro.ucc.su.oz.au

In article <[e-mail]> [e-mail] (John Woods) writes:
>vinay> I have a problem related to programming in an object oriented fashion.
>vinay>    Here`s the problem description :
>vinay>    There is an object class called Holder. The object holder can
>vinay> hold various things : Pencils, Pens, Erasers etc. I`ve declared
>vinay> different classes for these things ( class PENCIL, class PEN,
>vinay> class ERASER etc. ).
>vinay> The user of this program will choose at the runtime what objects to put
>vinay> in the holder. The problem is how do i store this information (i.e the
>vinay> contents ) in class HOLDER. I cannot create a single array of objects
>vinay> because each object is of different class.
>
>maxtal>    Forget Object Oriented Fashions, whatever they are.
>
>I'm not sure that's such a good idea, myself :-)

    I suggest this because people seem to think they can replace
all their concepts and ideas with inheritance. It is perhaps
best to use inheritance when the situation *demands* it,
and not as a matter of course.

    Good programming doesn't come from using inheritance everywhere
you possibly can, and such programming isnt necessarily Object Oriented
either. Nor is OO the only way to write programs.
>
>maxtal>    Use a discriminated union. Oh, C++ doesn't have one,
>maxtal>so emulate one with an idiom.  Below I use pointers for
>maxtal>illustration, you can put copies of the actual objects in
>maxtal>if you like (just get rid of appropriate *'s)
>
>    [ code deleted ]
>
>maxtal>Do not be scared of using a switch.
>
>I'm not sure that's such a good idea, either.  I'd avoid them like the
>plague.

    Try avoiding inheritance like the plague. It is a very
poor construction in may circumstances: it introduces strong
coupling (usually BAD) and the interface is then not
explicit (also considered BAD).

>My own feeling as to what would constitute an approach in the
>`object oriented fashion' follows:
>
>All things, like `pen', `eraser', `pencil' etc.  share the property
>that they can be put in the holder.

    No they do not. They do not share any properties at all.
They are completely independent objects. The only thing they
share is that they are objects, and you could derive them
all from class Object:

    class Object {
    public:
        virtual ~Object()=0;
    };

which has the benefit of ensuring that any Object gets deleted
properly -- nothing more.

>So, define class HolderTool.
>Then define subclasses of this, such as Pencil, Pen and Eraser.  Then
>one's holder is simply an array of HolderTool instances.

    I would consider this really, really BAD.

>What language are you using, BTW?
>

    What sort of holder tools do you have: dont you
put pens and pencils in:

    class Desk
    class PencilCase
    class Tray
    class DeskDrawer
    class CoffeeCup
    class Mouth // Yuk
    class BriefCase
    class Pocket

Are you really going to make ALL these things base classes
of class Pen? Are you going to modify Pen, Pencil,
Eraser, Pin, Stapler, Chalk ... every time you think
of a new place you can put them. This is exactly opposite
to the Open/Closed principle that you can close off
your classes permanently.

    Inheritance is best used (IMHO) for subclassing,
wherein ALL the properties of the objects have the same
interface (except construction details).

    This enables polymorphism.

    class Point {
    public:
        virtual void Draw();
    };

    class Circle : public Point {
    public:
        virtual void Draw();
    };

    class Square : public Point {
    public:
        virtual void Draw();
    };

*Same* interface for each class. The're all Points. Subclassing.

    class Float {
    public:
        float x;
    };

    class Complex : public Float {
    public:
        float y;
    };

OH DEAR. Not subclassing. A complex is not a float. Its the
other way around. What's been done here is an abuse
of inheritance: we should have used composition.
We do do this sort of thing sometimes to reuse an implementation,
but it is NOT subclassing.

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------