> The following was supposedly scribed by
> Fergal Daly
> on Sunday 05 October 2003 06:54 am:
>That said, having a single package so full of stuff that you need to split
> it into sub files is often an indicator that you're doing way too much in
> one package anyway. It's possible you could benefit from mixin classes.
> That is classes which contain only methods and these methods make very few
>assumptions about about their $self object.
I do have Get and Set methods which would allow functions like Move() to
operate without directly accessing the data structure, but they would still
have to know about the per-entity data structure (i.e. I could later change
where the entity is stored in the object, but the functions need to know
about some of the details of the entity.) Is this enough separation?
Originally, I was worried about the function call overhead, but I think this
is really a small price to pay for the design flexibility that I get from
making the packages less dependent on the data structure.
It looks like this will work:
Each "subpackage" is defined according to the filename and has "use"
statements for CAD::Drawing and CAD::Drawing::Defined. Each "subpackage"
does not need to know about any other "subpackage" (with the exception of
Defined.pm (which exports everything.))
the files will look like this:
CAD::Drawing
CAD::Drawing::Calculate
CAD::Drawing::Defined
CAD::Drawing::Manipulate
CAD::Drawing::IO
CAD::Drawing::IO::openDWG
CAD::Drawing::IO::Image
CAD::Drawing::IO::PostScript
and CAD::Drawing will have:
use CAD::Drawing::Defined;
use CAD::Drawing::Calculate;
use CAD::Drawing::Manipulate;
use CAD::Drawing::IO;
our @ISA = qw(
CAD::Drawing::Calculate
CAD::Drawing::Manipulate
CAD::Drawing::IO
);
CAD::Drawing::IO will then contain the "front-end" load() and save() functions
and use statements for each of the IO packages (this is another tricky part,
but I'll get back to it.)
--Eric
