Re: [Cxtable-devel] Borne- a question about packages...

[Borne Goodman-M. <bm...@eg...>]

Usually there is some level of cross pollination from one package to
another.  The main thing to consider when breaking down the classes into
packages is logical use, and the growth of that particular package in
the future.  You want to keep the number of classes reasonably small so
that you don't have 100 classes in one package, which can be a bit
overwhelming.

An example I will give is my package hierarchy in the ominit project I
am working on:

---client
------ui
---------system
---------chat
---------arena
------net
---common
---server
------net
------services
---------chat
---------arena
---util
---xml

Most of these packages have only 1 or 2 classes in them, and at a max
(for now) 5 or 6.  Even if this does grow, I broke down the packages
based on functionality, and it is easy enough to add more, like I plan
to have a persistence layer (which could be on the client and the
server).  The main reason to have a package system is to be able to find
related functionality.

I would certainly have a plugins package, and then under it each plugin
could have it's own hierarchy, or just all be lumped into one directory,
depending on the complexity of the plugin.

Loading the plugins in a reflective manner isn't all that difficult of a
problem.  What is needed is just a Plug-In interface so you have a set
of methods you know you can call on the object you instantiate, and then
do a Class.forName(<class name>).  Once you have the Class object you
can create an instance of it.  Cast that instance to whatever interface
all the plug-in's implement, and off you go.... I am more than happy to
do this implementation if you like.

--bjgm

On Mon, 2001-12-10 at 14:58, Williams, David wrote:
> Let's say I have Package One, Package Two and Package Three
> 
> 
> In One, there are 2-3 classes that are used elsewhere.
> In Two, it uses classes from One, as well as classes from Three...also, it has 2-3 classes used elsewhere
> In Three, there are classes that are used elsewhere and uses classes from Two
> 
> When you go to compile them, all of the things in Two that require Three will be unhappy.  All of the things in Three that require Two would be unhappy..
> 
> I guess I could think of about 5 packages that the project could be placed in, but 3 of them overlap, and so my thought is that those 3 should become 1 package... 
> 
> ~Dave
> 
> PS- The "Chess Game" is technically a plugin...partially due to my lack of skill with packaging and custom class loaders, the "Plugin" implementors share the directory with the remainder of the project.  These classes could be placed ENTIRELY in their own package, but then I would need to figure out a way to access them reflectively later...
> 
> ~Dave