This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Packaging for Reuse Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Packaging for Reuse" Watch "Packaging for Reuse" New topic

Packaging for Reuse

Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
I'm a rookie, but I've been doing some of the setup work on a Struts app. I don't have any experience packaging modules, so I need some guidance.

Say I've got these modules:


The architect wants to separate the MC from the V (as in MVC) in the package structure, so that we can easily reuse the MC pieces in future Struts apps. I further suggested separating all three layers, in case pieces of the model might be repurposed for a non-Struts app.

Just so we're straight, here's what how the architect is classifying the pieces:

M = Business Objects
V = (Struts) ActionForms
C = (Struts) Actions

Therefore, it's looking like we should do something like:

But I don't recall ever seeing such package structures. Is this prudent architecture? Please feel free to comment on all of the above. Any discussion on packaging would be enlightening.

Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
In our project, we have the follwing seperation:


you get the idea...

We don't do strict MVC - actually we are experimenting with more of an MVP approach. Anyway, we find that the navigation/presentation logic is quite coupled to the type of view, so we don't care about putting it into its own module yet (though they typically *do* go into their own java package(s)).

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
The architect envisions most reuse to be struts reuse, so that point of view argues for a separation of V from C, also. I don't know if this separation of V from C will actually be useful when/if the code is ever reused, but it does meet her requirement.

I see what you're doing, and it does make good sense to me. It's also probably the most practical separation.

Your structure is similar to mine, so I'm more comfortable with my structure now.

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This Dependency Inversion presentation has a couple slides on different motivations for different types of packaging. Let me know if it's at all helpful. Thanks!

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
I read through the presentation. Nice to see a presentation by example, I get lost in abstractions, until I'm familiar enough with them.

This might help me later, when I'm refactoring the modules themselves.

I agree. Here's the link:
subject: Packaging for Reuse
It's not a secret anymore!