Re: OO and large packages

[Joseph Wisniewski <wisniew@primenet.com>]

I am sure that you will get more in-depth answers from those more
well-able to answer this, but a few thoughts and rhetoric questions come
to mind. ( Also this if from an Ada83 mindset, not an Ada95 one )

Have you appropriately designed the package in the sense that the
appropriate amount of functions are private and public.

Have you implemented your "package interfacing" in an API "sense".
That is, instead of package think of what you are trying to design in
terms of a sub-system of a number of package. One school of thought
says that you ought to have a  "front-door" package ( within the subsystem
) that provides access from "other" subsystems to your subsystem. 
Your API package may or may not do "real work" or may perform traffic cop
functionality for your subsystem and call other exported functions within
other packages in that same subsystem to do the real work.

If the API starts getting real big, then you are right, you have a
problem. Try and take a look at your design from a reuse standpoint.
How "corrupted" is your package if some level of reuse or ( requirements
changes, same difference really ) comes along.

As far as nitty gritty goes, as a matter of personal preference, I stay
away from packages within packages to represent "composition" as opposed
to separate packages. 

I guess I would need more specifics of the design issues. I am curious to
hear others comments on this.

Joe

Tom Moran <tmoran@bix.com> wrote:
: Is there a good methodology to break up a complex object into multiple
: smaller packages?
:   In a windowing system I have a "window" object with a great many
: functions for both input and output, some of which are rather complex.
: One possible split is 
:   type output_window is new basic_window ...
: and a package providing just the output functions, then another
: package with
:   type input_window is new output_window ...
: overiding the input functions of basic window (which weren't even
: mentioned in input_window).  That produces two, smaller, package, but
: output_window is secretly passing all the input functions from
: basic_window on to input_window, which seems a really poor idea.
:   The only other obvious breakup is to include everything in one large

:   type io_window is new basic_window ...
: but move the guts of the larger functions off to separate packages in
: a traditional bottom-up way, with no special conceptual structure.
:   Suggestions?

-- 
Joe Wisniewski
President, Commercial Software Solutions, Ltd.

Full Onsite/Offsite Software Engineering Consulting Services
Specializing in Embedded RealTime Applications and Training

4403 W. Chama Suite #101
Glendale, Arizona 85310

(Voice) 602-580-4008	888-229-7597
(Fax)   602-580-4010    888-568-8734
wisniew@primenet.com

Co-Author: Program Smarter, Not Harder. 
           Get Mission-Critical Projects Right the First Time
           ISBN: 0-07-021232-5 McGraw-Hill