OO and large packages

OO and large packages

[Tom Moran]

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?

Re: OO and large packages

[Simon Wright]

tmoran@bix.com (Tom Moran) writes:

> 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.

You could look at the (by now conventional) approach of
Xaw/Motif/Tk/Java, and for all I know MS-Windows, and regard the outer
window as a container for window interface components or widgets
(which may of course be themselves containers, recursively, but
include 'terminals' like buttons, menus, labels, entries ...). Widgets
have appropriate subsets of all possible behaviours (eg, buttons can
be pressed). The subsets tend to be reasonably small.

Come to that, why reinvent the wheel? Check out TASH at
http://ocsystems.com/ (http://ocsystems.com/xada/ I think).

Re: OO and large packages

[Joseph Wisniewski]

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

Re: OO and large packages

[Tom Moran]

>You could look at the (by now conventional) approach of
>Xaw/Motif/Tk/Java, and for all I know MS-Windows, and regard the outer
>window as a container for window interface components or widgets
>(which may of course be themselves containers, recursively, but
  This is a painting/drawing sort of window, so on input it needs to
handle mouse movement and buttons, keyboard, and menu.  On output it
needs to draw various things.  Then there is the general window
housekeeping.  It makes for a large package and doesn't break into
obvious pieces.
.
  The question is more general, though: Do non-trivial OO objects
always lead to large packages.