The Beginning

Where did they come from? Did they just appear overnight? In fact, design patterns have a long history starting way before computing. But it wasn’t really until the GOF wrote their seminal book Design Patterns: Elements of Reusable Object-Oriented Software, that the concept of design patterns was cemented in the world of software development. The book introduces a list of design patterns categorized under three titles: creational, behavioral and structural.

I often post about Java EE on Twitter. Click to Follow @readlearncode

So what are design patterns in practice? Design patterns are solutions to problems already solved. They represent the collective wisdom of developers and provide us with a common vocabulary. By implementing solutions that are proven to work we avoid reinventing the wheel and can focus our efforts on solving the other problems we will face as we develop our application.

However, we need to take care not to overuse them. Unnecessary use of patterns tends to overcomplicate code making it hard to maintain and poor design pattern knowledge leads to the inappropriate implementation of patterns to problems that they were not designed to solve. It is very much the case that: If the only tool you have is a hammer, then you will see every problem as a nail.

The book’s authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

Enterprise Java and Design Patterns

After the GoF published their book, there was a talk at Java One 2000 about prototyping patterns for the J2EE platform this talk became a success and the speakers published the talk as a book. Core J2EE Patterns

The GoF book describes a range of patterns, not all common in Enterprise Java, but those that are common are baked into the APIs of the platform, so instead of having to implement them yourself the platform has them ready to use out of the box. This had already happened by Java EE 5.

Java EE Programming Model

The Java EE programming model has been simplified substantially since J2EE. Annotations have replaced the XML description files, convention over configuration has replaced the tedious manual configuration and dependency injection hides the creation and lookup of resources.

Resources are created and injected at injection points marked by annotations such as @Inject. All you need is a POJO that meets all of the conditions of the managed beans specification JSR 299 and depending on the annotation used it will become an EJB, servlet, singleton or RESTful web service.

The object is injected by the container and is determined by type. However using an interface as a type can confuse the container if there is more than one concrete implementation. It doesn’t know which object to inject. This confusion can be resolved by the use of a qualifier annotation that marks the concrete implementation you want to implement. We will see how this annotation is used with @Produces in the implementation of the factory pattern. Beans or objects that you want to inject that do not conform to JSR299 use the @Produces annotation to make them injectable.

JSR 299 Managed Bean Specification

• It is not a nonstatic inner class.
• It is a concrete class or is annotated @Decorator.
• It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.
• It has an appropriate constructor. That is, one of the following is the case:
• The class has a constructor with no parameters.
• The class declares a constructor annotated @Inject.

No special declaration, such as an annotation, is required to define a managed bean. To enable CDI you must have a beans.xml file in your project (under the META-INF or WEB-INF).

What Next

If you are interested in learning more about Java EE, why not check out my new course here, you can even start with a free trial. Also check out my other articles on the Observer Pattern, Decorator Pattern, Singleton Pattern, Factory Pattern, and the Facade Pattern.