4. Whatâs on?
⢠Design patterns retrospective
⢠Map classical design patterns to Java EE 7
⢠Contexts and Dependency Injection
⢠Singleton, Factory, Façade, Decorator and Observer
⢠Final Conclusions
⢠Q&A
5. What are you doing?
⢠Java Enterprise Edition (J2EE, EE 6/7)
⢠Spring
6. The beginning
â˘Design Patterns: Elements of Reusable Object-Oriented Software
(E Gamma, R Helm, R Johnson and J Vlissides. 1994)
AKA Gang of Four AKA GoF
â˘Creational, behavioral and structural
â˘So what are design patterns in practice?
7. Enterprise Java and design patterns
â˘JavaOne 2000 talk: Prototyping patterns for the J2EE
platform
â˘Core J2EE Patterns (D. Anur, J. Crupi and D. Malks)
â˘Out-of-box design pattern implementations with
Java EE 5
8. Java EE Programming Model
â˘Simplified programming model
⢠Annotations have replaced XML description files
⢠Convention over Configuration
⢠CDI hides object creation
â˘Resources are injected by type
9. Singleton Pattern
â˘Creational pattern
â˘Single instance and instantiated once
â˘Must be thread safe
â˘Not normally destroy during application life cycle
â˘Classic implementation: private constructor, double
locking, static initializer, enums âŚ
11. Singleton Pattern
â˘Conclusions so far
⢠Very different implementation
⢠Substantially less boilerplate code
⢠Enhancements via specialized annotations
Thereâs moreâŚ
13. The Good, Bad and the Ugly
â˘The Good:
â˘enhancements via specialized annotations
â˘startup behavioural characteristics
â˘fine grain control over concurrency and access
timeout
â˘substantially less boilerplate code
14. The Good, Bad and the Ugly
â˘The Bad:
â˘overuse can cause problems
â˘lazy loading causes delays
â˘eager loading causes memory problems
15. â˘And the ugly:
â˘considered an anti-pattern
â˘only niche use
â˘smarter to use a stateless session bean
The Good, Bad and the Ugly
17. Factory Pattern
â˘CDI framework is a factory !?!
public class CoffeeMachine implements DrinksMachine {
// Implementation code
}
â˘Use it like so:
@Inject
DrinksMachine drinksMachine;
18. Factory Pattern
â˘Problem! Multiple concrete implementations
public class CoffeeMachine implements DrinksMachine {
// Implementation code
}
public class SoftDrinksMachine implements DrinksMachine {
// Implementation code
}
@Inject
DrinksMachine drinksMachine;
â˘Which DrinksMachine to inject?
?!?
22. Factory Pattern
â˘Remember
â˘Only JSR299 beans are âinjectableâ
â˘But I want to inject a Collection type or Object with a
parameterized constructor
-> letâs dive deeper
23. Factory Pattern
â˘Dive deeper
⢠Producer methods
⢠Use it like so:
@History
@Produces
public List<Book> getLibrary(){
// Generate a List of books called 'library'
return library;
}
@History
@Inject
List<Books> library;
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface History
24. Factory Pattern
⢠Scope
⢠Determines when method called
⢠Life of object: @RequestScoped -> @ApplicationScoped
@RequestScoped
@History
@Produces
public List<Book> getLibrary(){
// Generate a List of books called 'library'
return library;
}
25. The Good, Bad and the Ugly
â˘The Good:
â˘easy to implement
â˘no boilerplate code
â˘works magically
â˘any object can be made injectable
26. The Good, Bad and the Ugly
â˘The Bad: named annotation is not type safe
@Named("History") -> @History
â˘and the ugly: object creation hidden, hard to follow
execution flow, IDE should help
27. Façade Pattern
â˘Hides the complex logic and provides the interface for
the client
â˘Typically used in APIs
â˘Classic implementation: Just create a method to hide
complexity
28. Façade Pattern
â˘Encapsulates complicated logic
⢠@Stateless, @Stateful@Stateless
public class BankServiceFacade{
public void complexBusinessLogic(){
// Very very complex logic
}
}
@Inject
public BankServiceFacade service;
29. The Good, Bad and the Ugly
â˘The Good: simple, robust, gives you a range of services
â˘The Bad: over use introduces unnecessary layers, if you
donât need it donât introduce one
â˘and the ugly: there isnât one really
30. Decorator Pattern
â˘Structural Pattern
â˘Dynamically adds logic to an object at runtime
â˘More flexible that inheritance
â˘Classic implementation: Both the decorator and target
object share the same interface. Decorator wraps the
target object and adds its own behaviour
32. â˘The Good: very easy to change behaviour without
breaking legacy code
â˘The Bad: needs XML config (<CDI 1.1)
â˘and the ugly: overuse will introduce an execution flow
which is hard to follow
The Good, Bad and the Ugly
34. Observer Pattern
â˘Define an event class
public class MessageEvent {
private String message;
public MessageEvent(String message){
this.message = message;
}
public String getMessage(){
return message;
}
}
35. Observer Pattern
â˘Notifies dependents of state change
@Stateless
public class MessageService {
@Inject
Event<MessageEvent> messageEvent;
public void fireMessage(){
messageEvent.fire(new MessageEvent("Hello World"));
}
}
36. Observer Pattern
â˘Dependent receives state change notification
@Stateless
public class MessageObserver {
public void listenToMessage(@Observes MessageEvent message){
System.out.println(message.getMessage());
}
}
37. Observer Pattern
â˘Qualifier to filter events
@WarningMessage
@Inject
Event<MessageEvent> messageEvent;
public void listenToMessage(
@Observes @WarningMessage MessageEvent message)
38. The Good, Bad and the Ugly
â˘The Good: very easy, no boilerplate code, less than JMS,
the container does the heavy lifting, light weight
â˘The Bad: confusing execution order but IDE will help
â˘and the ugly: nothing, its beautiful
39. Entity
â˘Lightweight domain object which is persistable
â˘Annotated with javax.persistence.Entity
â˘Can represent relational data object/relational mapping
annotations
40. Entity
@Entity
public class Contact {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String firstName;
private String lastName;
}