[Chicago-talk] super complex object

[JT Smith]

Ooooh. Mixin's. I had forgotten about those. I used to use those when I coded Lisp about 
10 thousand years ago.

That's very cool. I'll go with that. Thank you very much.


On Mon, 1 Aug 2005 17:10:44 -0500
  Jim Thomason <thomasoniii at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk


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