From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_20,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,658cbf6222fa4bf5 X-Google-Attributes: gid103376,public From: Joseph Wisniewski Subject: Re: OO and large packages Date: 1998/04/24 Message-ID: <6hqpsd$ja8@nntp02.primenet.com>#1/1 X-Deja-AN: 347393564 References: <353f7983.1926480@SantaClara01.news.InterNex.Net> Organization: Primenet (602)416-7000 X-Posted-By: wisniew@206.165.6.207 (wisniew) Newsgroups: comp.lang.ada Date: 1998-04-24T00:00:00+00:00 List-Id: 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 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