Java Package Structure & Access Modifiers

15 views
Skip to first unread message

Jason

unread,
Jun 26, 2010, 2:06:57 AM6/26/10
to jtablet-dev
A second issue that has been bugging me for quite a while is the
package structure and the access modifiers. Internal classes are
marked public, and the classes contained in any single package don't
necessarily seem to belong. The "public" modifier should be removed
from internal classes, and moved/refactored as necessary to enforce
separation of code.

Doing this will likely require a little bit of recoding, since a
number of classes depend on cross-package access at the moment. This
would work well with the modified TabletManager I'm also proposing. A
partial class library could look something like this:

cello.jtablet
cello.jtablet.TabletManager [class]
cello.jtablet.TabletEvent [class]
cello.jtablet.TabletListener [interface]
cello.jtablet.TabletDevice [abstract class]
cello.jtablet.TabletAdapter [abstract class]
cello.jtablet.TabletFunneler [abstract class]

cello.jtablet.driver
cello.jtablet.driver.MouseDriver
cello.jtablet.driver.MouseDevice

cello.jtablet.driver.cocoa
cello.jtablet.driver.cocoa.CocoaDriver
cello.jtablet.driver.cocoa.CocoaDevice

cello.jtablet.driver.wintab
cello.jtablet.driver.wintab.WinTabDriver
ecllo.jtablet.driver.wintab.WinTabDevice

cello.jtablet.driver.xinput
cello.jtablet.driver.xinput.XInputDriver
cello.jtablet.driver.xinput.XInputDevice

cello.jtablet.driver.wacomweb
cello.jtablet.driver.wacomweb.WacomWebDriver
cello.jtablet.driver.wacomweb.WacomWebDevice


Any thoughts on other possible ways of re-packaging the classes would
be appreciated.

Marcello Bastéa-Forte

unread,
Jul 10, 2010, 5:04:39 PM7/10/10
to jtabl...@googlegroups.com
On Fri, Jun 25, 2010 at 11:06 PM, Jason <kille...@gmail.com> wrote:
A second issue that has been bugging me for quite a while is the
package structure and the access modifiers. Internal classes are
marked public, and the classes contained in any single package don't
necessarily seem to belong. The "public" modifier should be removed
from internal classes, and moved/refactored as necessary to enforce
separation of code.

I completely agree with this sentiment. There is a paradox that the only appropriate way to protect classes internal classes is with package access, but once you do that, they all have to be in the same package... so you either end up with a bunch of protected classes all mixed together, or nicely organized classes that anyone can access (since they have to be public).

The only way I'm aware of is to use reflection combined with setAccessible, but that won't work on applets (unless some trickery is done for the thin client version).
I think this is a fine layout. It'd be pretty easy to rearrange(refactor) everything using Eclipse or IntelliJ (preserving svn history), but we would have to do a little bit of thinking on how it interacts with the JPen libraries. Also, how do you propose we not make the various internal classes public (or does it matter?).

Marcello
Reply all
Reply to author
Forward
0 new messages