usage of packages in large Java project

Member
Posts: 45
Joined: 2006.11
Post: #1
lol this is starting to become a series of questions about java heh.

My little tama project is starting to get relatively large, with many classes. Currently they are all under the same "tama" package, but I'm wondering at what point I should start separating the classes into different packages. Are there any rules of thumb or common conventions that I should know about?

Here is an inventory of the classes in my project:

Code:
// an abstraction layer for whatever graphics
// rendering api I decide on using. Fairly simple for
// this game, you can set the color and texture, and
// draw Squares, which can be colored and textured
// or not. Manages Texture resources internally.
abstract class RenderSystem;

// An identifier to an internally represented Texture
// within RenderSystem. One is returned from the
// abstract method loadTextureFromFile(String fileName)
class RenderSystem.Texture;

// Abstract class to hold a color. Probably not even
// necessary to have this class, so:
// TODO: find standard alternative
class Color;

// represents a rectangular region in 2D space
// can check if a point is inside the region
class Region;

// extends Region to contain a color and a texture for
// use as a drawing primitive with a RenderSystem
class Square extends Region;

// A concrete implementation of RenderSystem
// using Java2D
class Java2DRenderSystem extends RenderSystem;

// provides the method double getTime() which
// returns the time in seconds.
interface TimerClock;

// implements TimerClock using System.nanoTime()
class JavaClock implements TimerClock;

// acts like a stopwatch. you can start it, stop it, and get
// the difference in time between those two actions
// uses a TimerClock which is passed to it
// TODO: being redesigned
class Timer;

// works similarly to Timer, but instead giving an
// average time delta between successive calls to
// getDelta. This average is taken over a specified
// number of calls to getDelta.
// TODO: being redesigned
class SmoothTimer;

// Provides some globally useful static utility methods
// such as clipping floats to a range of values, etc..
class Utils;

// kind of a wrapper for the game code. Has methods
// similar to glut callbacks like display, keyboard, etc..
// must be passed a RenderSystem which it uses to
// draw the scene.
interface Scene;

// represents a little tama creature!
class Tama;

// This is the scene for the TamaGotchi game
class TamaScene implements Scene;

// The class which contains the main method.
class Main;

So, first of all, has my class/interface naming broken any conventions I'm unaware of? And second, should these classes be separated into two or more packages, rather than lumped into one "tama" package? How would you split them up?

Thanks for your help,
JeroMiya
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
We mostly used packages to enforce code separation (eg. importing package a in package b is allowed, but importing package b in package a is not).

Beyond that, we used sub-packages to group related stuff together, since in Java the concept of a folder of source files and a package are intimately tied together.
Quote this message in a reply
Moderator
Posts: 452
Joined: 2008.04
Post: #3
I'd definitely create different packages to organize out the gui code from the backend of your project.

So, Tama and the timers might stay in the tama package, but consider a package like "tama.gui" for the gui stuff. If you do choose to go with some kind of command pattern like in the other java post, I'd make a package like "tama.actions" for that too. Otherwise, I usually just use packages to keep things straight in my head.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  large arrays on the stack cause segfaults Skorche 2 2,482 May 23, 2007 10:50 PM
Last Post: Skorche
  py2app usage, and windows equivalent? purplemaji 1 2,750 Oct 24, 2006 02:00 AM
Last Post: aarku