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.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Java Application Architectue question -- Anti-patterns Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Java Application Architectue question -- Anti-patterns" Watch "Java Application Architectue question -- Anti-patterns" New topic
Author

Java Application Architectue question -- Anti-patterns

Mjeff Wilson
Greenhorn

Joined: Oct 30, 2007
Posts: 4
Kirk,

What are some common anti-patterns in Java architecture? Are there any particularly egregious ones? Also, are there some 'common wisdom' or 'best practices' architectural patterns being implemented by Java development teams that are in reality anti-patterns?

+jeff
Kirk Knoernschild
author
Ranch Hand

Joined: Apr 16, 2012
Posts: 41
That's a really interesting question, and I'm sure the community at large would have a lot to say about this. In terms of modularity, the one thing I've always found fascinating is that we spend a lot of time on the design activity. In most cases, we focus on class design and apply object-oriented principles and patterns. We try to create this structurally resilient and flexible piece of software. But then we package everything into a single deployable unit (WAR or EAR) and deploy it and essentially forego a lot of the flexibility we're striving for (i.e., unit of reuse equals the unit of release). Even the smallest change to the software requires that we build, test, and deploy the entire system. That's an anti-pattern. With a modular architecture, we can isolate change to a specific module, only build the module(s) that's changed, and then with a good module framework, only deploy the system modules that have changed. This level of dynamicity increases architectural agility.

Another I can think of is our failure to "architect all the way down", as I talk about in the book.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java Application Architectue question -- Anti-patterns