This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I am refactoring a bunch of stuff in our project here and ran into a stumbling block. My question is more of the philosophies of Java design. First let me ask if my general idea is on point. I'm attempting to refactor our project (which is rather big and complex) into several smaller sub projects or components, each defining a very coarse grained piece of the overall larger project. Our project is a general business application. So far I've identified the following abstract components of our app: application-services, application-utilities, application-framework, application-interfaces, and application-ui. The application-utilities component was very easy and straight foward. It holds general purpose utility objects such as String helpers, StreamTokenizers, Reflection helpers and so on. The application-framework component is also somewhat easy to understand. It will hold objects that have nothing to do with business logic rather deal with value added framework services such as printing, messaging over JMS or other protocols, a repository for holding reports, and so on. The application-ui component will include the logic used to define the UI (Swing), and possibly some ui-specific controller logic. I'm struggling over application-services and application interfaces. In the services I intend to put all business logic defined in POJOs and DAOs. The interfaces component will be a shared library that just contains the interfaces exported from the services component. I'm not quite sure the interfaces call for a separate component or sub project. Also I have trouble deciding on whether or not to include Exceptions referenced by the interfaces in there.
So far does what I've said make any sense? My goal is to be able to work on, use, and deploy the pieces independent of one another. I'm currently managing the components as individual Maven2 projects. Eacho component so far builds a jar that can be used by other components and/or by the original project. It's working pretty good for some simple things I just wonder how well my idea will scale. Please poke holes in my idea and find any/all flaws you can. I'm looking for the best way to take this beast of an application that is based on improper use of EJB and make it manageable.
I plan to take any good feedback I get here, claim it as my own original idea, post it on my blog (which almost nobody reads anyway) and implement it taking full credit for the results. Please make me look good in front of my homies and family.
(In all reality I do give credit where it is due but I have a rather twisted sense of humor as I find the prior paragraph funny. What's not funny is my lack of imagination which lead to my asking for advice here. If I were anywhere as clever as I pretend to be I would have this figured out already.)
Holla at me...<br /><a href="http://codeforfun.wordpress.com" target="_blank" rel="nofollow">http://codeforfun.wordpress.com</a>
Read up on Robert Martin's ideas about package dependencies. This blog has links to some articles, but the book he calls PPP is the very best. If the articles grab your imagination at all, buy the book and pay extra for overnight delivery.
JDepend is a free tool that computes all of Martin's metrics across a body of code. I made a little script that pulls the package-to-package relationships out of the JDepend report and makes a GraphViz picture. I run it often and find it a worthy challenge to keep the arrows going the right direction.
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
Joined: May 26, 2006
I've been reading Uncle Bob through Software Development magazines and I love his stuff. It never occurred to me to look for a weblog by him. I'm definitely going through his site. Thanx!