[Chicago-talk] super complex object

[Jim Thomason]

If this were Objective-C, it'd be easy. You'd break things out into
categories and be all set. I think the C++ term is a mixin. Since it's
perl, it's still easy, just less formal.

For example:

package God;

use God::Stuff;
use God::OtherStuff;
use God::FunctionBucket;

1;

then, in your various other modules:
#God/Stuff.pm

package God;
.
.
.
1;

Note the important distinction - place it in God/Stuff.pm, but name
the package God. Everything goes into the God namespace.

I'm not sure what sort of maintenance headaches this would create for
you, though. You end up with bunches of function buckets that can't
operate on their own.

(If you want a slightly more formalized approach, you can take a look
at Class::Mixin on CPAN)

Further, if you can't figure out how to break the object into other
objects to inherit from, it may also be difficult to conceptually
break things up into function buckets in this manner.

And, finally, it may actually be true that your super complex object
is too, well, super complex. Re-factoring may be appropriate.

-Jim....

On 8/1/05, JT Smith <jt at plainblack.com> wrote:
> I have created a monster super complex object. It only has a half dozen properties, but
> those properties can be manipulated in a near infinite number of ways.
> 
> The problem is that I want my main class to have all sorts of methods for use by the
> subclasses in order to keep the subclasses small. The problem is that I now have a
> master class that has almost 100 methods in it. That just seems wrong to me, but at the
> same time, every one of the subclasses uses all of those methods at one time or another,
> so I can't just get rid of them. And since they're always in use by all the subclasses,
> it doesn't seem to make sense to create any sort of middle tier subclass.
> 
> What I'd like to do is break them out into seperate files by functional groupings, but
> bring them all in as methods to the master class. Does that make sense to do? Is there a
> good way to do it?
> 
> I've also been trying to figure out how I can break the master object down into simpler
> classes that the master can then inherit from, but I haven't been able to do it. The
> methods seem to rely on each other too much to make that work.
> 
> Any suggestions? It seems that I can't be the only one to have run into an
> overcomplicated object. Help a brother out. =)
> 
> JT ~ Plain Black
> ph: 703-286-2525 ext. 810
> fax: 312-264-5382
> http://www.plainblack.com
> 
> I reject your reality, and substitute my own. ~ Adam Savage
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>