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 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 Java Interview Guide this week in the Jobs Discussion 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

Java Application Architectue question -- Anti-patterns

Mjeff Wilson

Joined: Oct 30, 2007
Posts: 4

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?

Kirk Knoernschild
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 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.

I agree. Here's the link:
subject: Java Application Architectue question -- Anti-patterns
It's not a secret anymore!