Most Important Patterns (Top 6)

Shortly a developer asked me, what are the most know-worthy patterns - in context of Java EE. My answer was:

  1. Facade: it decouples independent classes, and more important, decreases (makes the interface more coarse grained) the granularity. Session Facade from Java EE is a sample.
  2. Adapter: makes incompatible things compatible. Especially important in server programming, in case you have to talk to legacy backend systems like SAP, CICS or IMS. Business Delegate in J2EE 1.4 (catches RemoteExceptions and throws something else), DAOs or JCA Connectors are adapters.
  3. Decorator: Enhances an interface (in our case the Facade), with additional aspects (it is actually the beginning of AOP :-)). In Java EE we have the Servlet Filter, Interceptors or implicit decoration with transactions, state or security. In Java SE the whole package is a decorator.
  4. Interface (actually not a standard pattern): is needed for encapsulation, decoupling the clients from the interface realization, and so is the beginning of service orientation or SOA.
  5. Factory/Builder: encapsulates the creation of differnt implementations for a Java-Interface. Can be a part of a framework (see Spring or Java EE 5), or of project architecture.
  6. Command: provides a simple and stable interface (often one method with name like execute, go, run, actionPerformed etc). The implementation provides the behavior, having the only the interface, it is not possible to see what happens :-). Command is the foundation of JMS, the whole SOA (stands for Same Old Architecture :-)) and also the event handling of frameworks like swing (ActionListener), or Struts (Actions).
So a typical J2EE 1.4/Java 5 architecture consist of:
Business Delegate (Adapter + Factory) ------> Decorator (Transactions, Logging, Security) + Session Facade  (Facade), a bunch of POJOs or Session Beans, and some DAOs (Adapter) or connectors to the backends. Message Driven Beans (Command) are often used for batch processing.

It's amazing, but it is possible to build almost every (Java EE) architecture with these building blocks.

Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition the podcast:

Stay in touch:


It's dangerous to think of design patterns as building blocks for an architecture, and that there is some set of core patterns that are most important.

Patterns are mostly just a workaround for weaknesses in a language or environment. This should be blatantly obvious with so-called J2EE design patterns (e.g. session facade, data transfer objects, etc.) that clearly exist just to address problems with a flawed spec.

That's not to say patterns are not important tools (and utterly necessary when working within the constraints of Java/J2EE).

But it's critical that you don't treat them as a foundation for an architecture. They're temporary solutions and stepping stones until our tools get better. So it's critical that we look for better ways to address those deficiencies. Which includes looking for, lerning, adopting, and-or creating better/simpler frameworks and languages.


Posted by Anthony on October 17, 2006 at 10:11 PM CEST #


the patterns, which I mentioned, are more concepts than classic design patterns. In J2EE 1.4 case you are right, most of the patterns were workarounds. But most of the patterns are still valid also for Java EE 5, .NET or distributed computing. You need something, which increases the granularity, you have still adapters etc.

My opinion remains: almost every architecture (regardless of the used technology) consists of these building blocks. J2EE 1.4 is only one sample.

Posted by Adam Bien on October 17, 2006 at 11:32 PM CEST #

What about Observer/Listener? Pretty much the most fundamental pattern of them all. I can't think of a program I have written that doesn't use it. Without it there are no asynchronous call-backs and therefore no event-driven programming.

Strategy is also a useful one, this maybe overlaps with your "interface" pattern.

Posted by Dan Dyer on October 18, 2006 at 01:16 AM CEST #


yes Observer is important. But you are also right, it overlaps with the interface and command (and a for- or while-loop :-)).

thank you for your comment!,


Posted by Adam Bien on October 18, 2006 at 10:15 AM CEST #

Are you sure of the decorator pattern described here? The most common decorator form I have seen is a simplification of an api that adapts it to a specific domain.

Posted by Ignacio Coloma on October 18, 2006 at 01:13 PM CEST #

You missed probably the single ONE most important pattern: the template method. Re-read the chapter about it in the GOF's "Design Patterns". This is where "Inversion of Control" has its roots.

Posted by George Jempty on October 18, 2006 at 04:04 PM CEST #


I'm pretty sure -> decorator means for me: the same interface as the "real object" but more cross-cutting functionality. Just see: BufferedOutputStream and FileOutputStream from the io package.

Posted by Adam Bien on October 18, 2006 at 08:01 PM CEST #


yes template is essential. But it is more a design pattern, than a concept. I meant in my more "architectural" patterns or building blocks.

Thank you for your comment!

Posted by Adam Bien on October 18, 2006 at 08:03 PM CEST #

Could you update Most Important Patterns article with a typical architecture for java 7 or later? Great article

Posted by Zavael on August 04, 2016 at 02:37 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments