SE2016 - Java EE revisits design patterns 2016

Java EE
revisits design patterns
Sep. 2-4
Kyiv, Desyatynna str. 12
@readlearncode
Alex Theedom Senior Java Developer

Who am I?
Alex Theedom, Senior Java Developer
@readlearncode

What’s on?
• Design patterns retrospective
• Map classical design patterns to Java EE 7
• Java EE Programming Model
• Singleton, Factory, Façade, Decorator and Observer
• Final Conclusions
• Q&A

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?

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

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
•@Inject and disambiguation via custom qualifier
•POJO (JSR 299 managed bean)
•Otherwise @Produces

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 …

Singleton Pattern
@DependsOn("DatabaseConnectionBean")
@Startup
@Singleton
public class Logger {
@PostConstruct
void constructExpensiveObject() {
// Expensive construction
}
}
@DependsOn("DatabaseConnectionBean")
@Startup
@Singleton
@PostConstruct
void constructExpensiveObject() {
// Expensive construction
}
}
@Inject
Logger logger;
@Inject
Logger logger;

Singleton Pattern
•Conclusions so far
•Very different implementation
•Substantially less boilerplate code
•Enhancements via specialized annotations
There’s more…

Singleton Pattern
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@AccessTimeout(value = 30, unit=TimeUnit.SECONDS)
@Lock(LockType.WRITE)
public void addMessage(String message) {}
@Lock(LockType.READ)
public String getMessage() {}
}
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@AccessTimeout(value = 30, unit=TimeUnit.SECONDS)
@Lock(LockType.WRITE)
public void addMessage(String message) {}
@Lock(LockType.READ)
public String getMessage() {}
}
•Container/bean managed concurrency

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

•The Bad:
•overuse can cause problems
•lazy loading causes delays
•eager loading causes memory problems

•And the ugly:
•considered an anti-pattern
•only niche use
•smarter to use a stateless session bean

Factory Pattern
•Creational pattern
•Interface for creating family of objects
•Clients are decoupled from the creation

Factory Pattern
•CDI framework is a factory !?!
public class CoffeeMachine implements DrinksMachine {
// Implementation code
}
}
•Use it like so:
@Inject
DrinksMachine drinksMachine;
@Inject

Factory Pattern
•Problem! Multiple concrete implementations
}
public class SoftDrinksMachine implements DrinksMachine {
}
}
}
@Inject
@Inject
•Which DrinksMachine to inject?
?!?

Factory Pattern
•Solution! Qualifiers
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.FIELD})
public @interface SoftDrink
@Qualifier
public @interface SoftDrink
@Qualifier
public @interface Coffee
@Qualifier
public @interface Coffee

Factory Pattern
•Annotate respective classes
@Coffee
}
@Coffee
}
@SoftDrink
}
@SoftDrink
}

Factory Pattern
•Annotate injection points
@Inject @SoftDrink
DrinksMachine softDrinksMachine;
@Inject @SoftDrink
DrinksMachine softDrinksMachine;
@Inject @Coffee
DrinksMachine coffeeDrinksMachine;
@Inject @Coffee
DrinksMachine coffeeDrinksMachine;

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

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
@Produces
return library;
}
@History
@Inject
List<Books> library;
@History
@Inject
List<Books> library;
@Qualifier
@Target({ElementType.METHOD})
public @interface History
@Qualifier
@Target({ElementType.METHOD})
public @interface History

Factory Pattern
•Scope
•Determines when method called
•Life of object: @RequestScoped -> @ApplicationScoped
@RequestScoped
@History
@Produces
return library;
}
@RequestScoped
@History
@Produces
return library;
}

•The Good:
•easy to implement
•no boilerplate code
•works magically
•any object can be made injectable
•automatic per class configuration
•Disambiguation/filtration via qualifiers

•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

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

Façade Pattern
•Encapsulates complicated logic
•@Stateless, @Stateful
@Stateless
public class BankServiceFacade{
public void complexBusinessLogic(){
// Very very complex logic
}
}
@Stateless
public class BankServiceFacade{
public void complexBusinessLogic(){
// Very very complex logic
}
}
@Inject
public BankServiceFacade service;
@Inject
public BankServiceFacade service;

•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

Decorator Pattern
•Structural Pattern
•Dynamically adds logic to an object at runtime
•More flexible that inheritance
•Classic implementation

Decorator Pattern
@Decorator
@Priority(Interceptor.Priority.APPLICATION)
public class PriceDiscountDecorator implements Product {
@Coffee
@Any
@Delegate
@Inject
private Product product;
public String generateLabel() {
product.setPrice(product.getPrice() * 0.5);
return product.generateLabel();
}
}
@Decorator
@Priority(Interceptor.Priority.APPLICATION)
public class PriceDiscountDecorator implements Product {
@Coffee
@Any
@Delegate
@Inject
private Product product;
public String generateLabel() {
product.setPrice(product.getPrice() * 0.5);
return product.generateLabel();
}
}

•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

Observer Pattern
•Behavioural Pattern
•Publisher-Subscriber
•Classic implementation: Implement a Subscriber
interface, register with publisher and call a notify
method on subscribers

Observer Pattern
•Define an event class
public class MessageEvent {
private String message;
public MessageEvent(String message){
this.message = message;
}
public String getMessage(){
return message;
}
}
public class MessageEvent {
private String message;
public MessageEvent(String message){
this.message = message;
}
public String getMessage(){
return message;
}
}

Observer Pattern
•Notifies dependents of state change
@Stateless
public class MessageService {
@Inject
Event<MessageEvent> messageEvent;
public void fireMessage(){
messageEvent.fire(new MessageEvent("Hello World"));
}
}
@Stateless
public class MessageService {
@Inject
public void fireMessage(){
messageEvent.fire(new MessageEvent("Hello World"));
}
}

Observer Pattern
•Dependent receives state change notification
@Stateless
public class MessageObserver {
public void listenToMessage(@Observes MessageEvent message){
System.out.println(message.getMessage());
}
}
@Stateless
public class MessageObserver {
public void listenToMessage(@Observes MessageEvent message){
System.out.println(message.getMessage());
}
}

Observer Pattern
•Qualifier to filter events
@WarningMessage
@Inject
@WarningMessage
@Inject
public void listenToMessage(
@Observes @WarningMessage MessageEvent message)
public void listenToMessage(
@Observes @WarningMessage MessageEvent message)

•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

Final Conclusion
•Efficiency savings
•Greater control over behaviour
•New features enhance implementation

Thank You
Sep. 2-4
Kyiv, Desyatynna str. 12
@readlearncode
Alex Theedom Senior Java Developer

SE2016 - Java EE revisits design patterns 2016

More Related Content

SE2016 - Java EE revisits design patterns 2016

Editor's Notes