Re: Need Development Guidelines To Organize Classes into Packages

[Jason Chambers <tooger@bellsouth.net>]

When designing packages, the same rules apply as they do for designing 
classes - it's just a different scale. For example, you want to make use of 
encapsulation - i.e. hide the details of the innards of the package and 
provide a nice clean API for users of the package. A good option for this 
is to publicly expose interfaces only and hide as many concrete classes as 
you can by making them package friendly (default access). You also want to 
avoid tight coupling - especially cyclic dependencies. For attaining 
cohesion, all classes and interfaces should have a common theme. If they 
don't then refactor because it sounds like some don't belong in the 
package. You may also want to provide a TestSuite which bundles all of the 
unit tests for the package into a single unit.

At 10:08 PM 11/3/2003 -0500, Lee Chalupa wrote:
>Hello:
>
>I am looking for some guidelines to help me organize a new application's 
>classes into packages.
>
>Is there a quantity of classes per package that tends to be easier to work 
>with?  What number of classes per package is definitely too few?  What is 
>definitely too many? Why might this be a problem?
>
>Should you consider some kind of fan-out ratio when you are organizing the 
>package hierarchy?
>
>How would you go about evaluating the quality of a packaging scheme for an 
>application?  What does goodness look like? For example, high cohesion 
>inside packages, low coupling between packages, intuitive package names, a 
>consistent range of quantity of classes in each package of the application.
>
>Does anyone have any references for these kind of development issues?
>
>Thanks
>
>Lee
>
>
>
>--
>Lee Chalupa
>Something Else Enterprises, Inc.
>lchalupa@seelink.org
>770 381 2377