in reply to OO Perl and Design Issues
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. ;-)
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: OO Perl and Design Issues
by jonjacobmoon (Pilgrim) on Jan 02, 2002 at 04:28 UTC | |
by mstone (Deacon) on Jan 03, 2002 at 04:53 UTC |