Tye already mentioned 'demoting' the data from the table.. giving the class a single attribute (a hash) that holds all the tuples from that table instead of trying to make every key-value tuple from the table a full-fledged attribute. I agree with that suggestion, and what follows is a discussion of why I agree:

Good OOP tends to lean toward consistent interfaces.. every object in a class having exactly the same set of attributes and methods, with the instances only differing in their attribute values. That gives you the freedom to assume that any object from the same class will work exactly the same way, which in turn lets you write simpler client code (code that uses the object).

Polymorphism.. creating an object that inherits interfaces from more than one base class.. makes it easier to shuffle interfaces among several classes, but still keeps the interfaces themselves consistent. Every object in a polymorphic class still has the same set of methods and attributes, and it's still safe to assume that all objects from that class will work the same way.

You're asking how to put different interfaces on two objects from the same class. Yes, it's possible, but it tends to be a bad idea.

For one thing, changing interfaces on a per-object basis tends to make your client code insanely complicated. Instead of being able to write one-size-fits-all routines, you're forced to inspect each object you get to see what it can do. Then you have to work out the logical gymnastics necessary to reach the right handling routine for each permutation of attributes and methods. In the vocabulary I know, that's called 'floating' complexity up to the higher, more abstract parts of your program, instead of 'sinking' it into the lower, more concrete regions. Historical best practices suggest that it's better to go the opposite way.

For another thing, making objects that flexible tends to create a breeding ground for runtime errors that are a bitch to find and fix. Typos become especially nasty, because there's no reason for the object to think you don't want one attribute named 'thing1' and another named 'thing 1'. Likewise, it becomes easy to break your code by changing it in one place, but not propagating the same change to everywhere else that it might be necessary. And since your client code has to inspect the object a lot, you end up with more places to search.

And since you did specify design issues, those are things you should probably keep in mind. ;-)

In reply to Re: OO Perl and Design Issues by mstone
in thread OO Perl and Design Issues by jonjacobmoon

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.