[Chicago-talk] super complex object

[Steven Lembark]

> Any suggestions? It seems that I can't be the only one to have run into
> an  overcomplicated object. Help a brother out. =)

Do you really need ALL of the functionality in
one object? When I see that many manipulators
I get the feeling that some number of separate
objects have been glommed together.

For inheritence: are all of the attributes and
functionality related via "isa" or is this one
simple object that "has-a" copy of a few others
in it (i.e., helper objects)?

Perl is nice -- and one of the few OO languages
avilable -- becuase its classes define
*behavior* (vs data). Question, then, is how
much of the behavior is really intrinsic to
the object's function -- or might better be
moved into behavior of contained objects?

For example, if you have an "ftp" object and
start to notice "socket" behavior creeping
into an interface that otherwise only has
get/put/cd/dir then you probably are inheriting
from a socket rather than containing one. That
or you aren't leaving the encapsulated socket
to its own behavior via method calls but are
inheriting its behavior into the FTP object.

If you can group the behavior in to "top" and
"bottom" level behaviors then the bottom stuff
is proably better off encapsulated where the
main object's methods can't see it.

That or you may have a zillion mutators for
some set of things that might be better
described via parameters. If many of the
behaviors are rather similar then you might
want to just have a single method for some
of them and modify its behavior via the
object's state or method call arguments.

What is the things really supposed to do?

-- 
Steven Lembark                                       85-09 90th Street
Workhorse Computing                                Woodhaven, NY 11421
lembark at wrkhors.com                                     1 888 359 3508