Re: Best Practices - common code
From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 01/28/05
- Next message: Maarten via JavaKB.com: "Add a scrollbar to the rightside of a splitpane"
- Previous message: Andrea Desole: "Re: Is a MyClass[] also an Object[]?"
- In reply to: Rhino: "Re: Best Practices - common code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 28 Jan 2005 08:41:10 -0500
Rhino wrote:
> "John C. Bollinger" <jobollin@indiana.edu> wrote in message
> news:ctbenj$427$1@rainier.uits.indiana.edu...
>
>>Rhino wrote:
>>My recommendation would be to break it up into smaller
>>pieces that you don't object to distributing as indivisible units. The
>>natural way of doing this would be to assign classes to packages so that
>>you can break up the bulk along package or package family* lines.
>>Technically, a Java package is little more than a namespace and access
>>control domain for classes, but it is common practice to use packages to
>>group classes into functional and/or distribution units.
>>
>>*Package family: a non-Java term by which I mean a collection of
>>packages all having a common name prefix.
>>
>
> I've already broken my Common project into a variety of different packages
> with names like this:
> mydomain.common.prefs
> mydomain.common.edits
> mydomain.common.error
> mydomain.common.filters
> mydomain.common.utilities
>
> That's what you mean, right?
Yes, just so.
> But in the case of project Foo, whose package names are mydomain.foo and
> mydomain.foo.Resources, I only need some of the classes in
> mydomain.common.utilities, not all of them. That's really the nub of my
> question: should I be packaging all of mydomain.common.utilities when I only
> need two of the dozen classes in it?
I wouldn't worry about a difference of ten classes in a medium-size project.
>>>c. less code that can be reverse-engineered by competitors
>>
>>I guess you could argue that the hypothetical competitors keen on your
>>technology would have to obtain multiple of your products to get their
>>hands on all of "Common". If that makes a noticeable difference to your
>>bottom line then you are small enough potatoes that your competitors
>>either (a) for all intents and purposes don't exist or (b) are way out
>>of your league.
>>
>
> I'll have to think about that one a bit more. I'm truly not sure how much
> risk there is of competitors reverse-engineering code. I know that
> obfuscators exist to make reverse-engineering more difficult but I don't
> know how effective they actually are. Maybe the people who buy obfuscators
> are just paranoid and the actual amount of reverse-engineering is
> infinitesimal....
My point was that breaking up your "common" code and distributing fewer
unnecessary pieces simply means that a competitor who wanted to get all
of it would have to obtain more of your products to do so. If the
handful of additional sales is noticeable to you then (I assert) you are
a small enough operation that one of the two alternatives I offered applies.
Obfuscation is a different beast, and I will not otherwise comment on it
here.
>>You would have to do slightly more work than just click a button, but
>>Ant can analyze class dependencies. Look at the ClassFileSet entity.
>>Ant uses BCEL to perform that task, and it wouldn't be too hard to write
>>your own tool for it if you didn't want to use Ant. I would expect that
>>there are other possibilities, too; some may have a nice GUI.
>>
>
> I'm very fond of Ant but didn't realize it could analyze the dependencies. I
> saw the acronymn BCEL in the docs but had no idea what it did or that it was
> anything useful so thanks for telling me about it. I know that I could write
> a tool that did that sort of analysis but I wasn't wild about re-inventing
> the wheel when I was pretty sure there was some automated way of doing that
> analysis.
BCEL = ByteCode Engineering Library. It's an Apache Jakarta project
that offers rather good facilities for analyzing, modifying, and even
creating Java classes at the bytecode / class file format level.
>>On the other hand, if you reduce the scope of your problem by dividing
>>up "Common" as I suggest, then you don't really need to worry much about
>>it. Just jar up whole packages or package families and distribute them
>>as units.
>
>
> Based on what I've described above, would I be correct in understanding that
> you are recommending that I incorporate all of the
> 'mydomain.common.utilities' package, even the classes that Foo doesn't need?
Yes. It's a management and maintenance issue. By making packages the
unit of distribution (instead of classes) you dramatically reduce the
complexity of the problem of including all required classes, while
taking a granular enough view to meaningfully cut in to the problem of
distributing unneeded classes.
> I'd be reluctant to incorporate all of the 'mydomain.common' package family
> since much of it isn't used within Foo. I don't have as much of a problem
> with distributing a few unneeded classes in 'mydomain.common.utilities'.
I see no need to distribute all of 'mydomain.common' if only
'mydomain.common.utilities' is used.
>>Document package dependencies instead of individual class
>>dependencies. Use a build and / or packaging tool for which you can
>>prepare a static configuration file (e.g. Ant, most IDEs).
>>
>
> I assume that those two sentences represent indepedendent thoughts.
Yes.
> What is
> the best way of documenting package dependencies, Javadoc?
You could do it in package-level Javadocs, but I was thinking more along
the lines independent developer documents. If you aren't maintaining
any and don't see a need to start then perhaps the dependency
documentation isn't so important for you.
> What do you mean
> by a 'static configuration file'? I don't recognize that term from Ant or
> Eclipse so I'm not quite sure what you mean, what it would contain, or what
> it would look like.
I was trying to be generic. For Ant, the term would refer to a project
build file (i.e. build.xml by default). For Eclipse it would be part of
the project configuration, and / or an Ant build file if you are using
Ant inside Eclipse.
John Bollinger
jobollin@indiana.edu
- Next message: Maarten via JavaKB.com: "Add a scrollbar to the rightside of a splitpane"
- Previous message: Andrea Desole: "Re: Is a MyClass[] also an Object[]?"
- In reply to: Rhino: "Re: Best Practices - common code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
