in reply to Re: Re: Help with ADT
in thread Help with ADT

Well, you wrote:
The client only does stuff through the accessors, so you don't have the coercion issues.
which sounds specific enough to me, and that was what I argued against.

You are right about that it's good to do the design first (if only all programmers would). It's also good to have an API, but that's already implied if you are using an ADT, because it wouldn't be much of an ADT if you'd poke around in the datastructure outside of defined set of functions. However, you do not need objects to be able to deal with ADTs. Your password file can be seen as an ADT which you access via the *pwent set of functions.

Abigail

Replies are listed 'Best First'.
Re: Re: Help with ADT
by dragonchild (Archbishop) on Jul 25, 2002 at 14:38 UTC
    dimmesdale wrote:
    $info->{subdirectory}->{file}->[measurement] = INDEX; $info->{subdirectory}->{file} = PARSER; $info->[measurement]->{name} = NAME;

    That looks very much like "pok(ing) around in the datastructure ..." *shrugs*

    Design, especially before coding, is good.

    Creating mockups in search of knowledge to help design is good.

    Poking around in complex data structures is bad.

    Creating API's to encapsulate complexity is good.

    (I'm starting to feel like a Mastercard commercial.)

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Well, you have to poke *somewhere* in your code in your datastructure, otherwise it wouldn't be useful. You can make the most beautiful API, but if you never put something in your datastructure, or never look at something inside it, it's not going to be very useful.

      I don't think the post gave any indication the accessing was done outside of an API. Perhaps it was, but there's no reason to assume it so.

      Not that whether it was done inside or outside an API has anything to do with his problem.

      Abigail

        Yes, it does. If you're within an object and you're doing 2- and 3-deep lookups into $self, you're programming horribly. It's mean, but true.

        Even within an object, you should be using your accessors. In addition, using objects would allow you to abstract out some of the parts of this ADT. For example, dimmesdale has this concept of a "measurement". That should be abstracted out to some other object. Now, you deal with anything in that measurement through that API. This actually solves his initial problem.

        Plus, I suspect that he's working with test subject data, from the little he posted. There are usually hundreds of measurements for a given test subject. So, he has a List of Measurements within a TestSubject, all with appropriate accessors. The DB-access methods are now a piece of cake. The display methods are a piece of cake.

        I'm not always "OO rulez" or whatever. But, if the shoe fits ...

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.