Implementing Strategies with Enums.

Implementing Strategies with Enums.

As most Design Patterns, Strategy pattern is an incredibly useful pattern to express polimorphic behaviour.
I don't pretend to explain Strategy pattern on this post. My intention is only to show you a nice way of implementing the pattern using a Java Enum.

Sometimes the difference between strategies is small, and you have control over all the strategies. (There is no intention that a client implements its own strategy).
Also, usually each strategy comes in the form of a Singleton instance.
It would be nice to have all Strategies in a common place, sharing a common namespace.

All the previous can be addressed with the use of the Enum construct in Java 1.5+

Let's suppose a Voice "strategizable" class, with two concrete strategies Screaming Voice and Whisper Voice

This is how we would do this with an Enum.

public enum Voice {
SCREAM(){
@Override
public String say(String say){ return say.toUpperCase()+" !!";}
},
WHISPER(){
@Override
public String say(String say){return say.toLowerCase()+ " please ";}
};
public abstract String say(String say);
}

There we have our two Strategy implementations under the same namespace (the ENUM type), singleton guaranteed. To test the startegy we have the following test case.


package misc;

import org.junit.Test;
import static org.junit.Assert.*;

public class VoiceTest {
@Test
public void testVoice() {
// if in good mood
VoiceUser user = new VoiceUser(Voice.WHISPER);

// if in bad mood
VoiceUser user2 = new VoiceUser(Voice.SCREAM);

assertEquals("do that please", user.askSomeone());
assertEquals("DO THAT !!", user2.askSomeone());
}
}

class VoiceUser {
public VoiceUser(Voice voice) {
this.voice = voice;
}

Voice voice;

String askSomeone() {
String string = "Do that";
return voice.say(string);
}
}

From which Jar is a class Loaded

I post this for future reference.

public class Main {

public static void main(String[] args) {
System.out.println(findJar(System.class));
}

public static String findJar(Class clase) {
String name = clase.getName();
name = name.substring(name.lastIndexOf('.') + 1) + ".class";
String jar = clase.getResource(name).toString();
return jar;
}

}

Fast Flex Cairngorm Explanation

Flex Cairngorm fast explanation

As an experienced Spring and Spring MVC developer, i started my new Flex-Java based personal project with the idea of using a flex framework that encourages the same kind of patterns that i'm used to.
I took on the Cairngorm framework from de Adobe people.

I'll try to establish correspondences between Cairngorm elements and Spring MVC elements.

The elements:

The elements that form part of a Flex Cairngorm Architectura are the following:

View: The view is normally an mxml file. The view shows the data to the user and receives his interactions. The view allows to initiate updates of the model. When an update is to happen, it generates an appropiate event informing of this. The view holds a binded reference to the model that is automatically updated on change. This Object corresponds to the JSPs (Or any other view technology) in Spring MVC.

Model Domain Objects: Are the objects that form part of the Model of the application, are the objects on which the application logic is applied.

Events: Is the flex preferred way of communicating that an action must be taken due to something happening. In cairngorm, the Event object usually carry a Model Object reference on it. This object corresponds, more or less, to the HttpRequest that is sended to the Servlet Container on the Submit event.

Front Controller. As in the major of MVC frameworks, the front controller is the central piece that ties together and routes flow between the view and the business logic. If you are familiar with Spring MVC, this Object corresponds to the DispatcherServlet of Spring.

ModelLocator: In Flex, a Model locator is a Registry that contains references to the different model objects.

Command Objects: Following the GoF Command design pattern, Cairngorm Command Objects are objects that implements an execute method, and are selectively invoked by the front Controller to carry on certain business logic. In normal cairngorm applications, the command object basicaly only extracts the model object from the Event object and passes it to a Business Delegate Object. If you are experienced with Spring MVC this Command Object corresponds to the Controller in the Spring MVC Framework.

Business Delegate: This object's job is to hold a reference to the (usually remote) Service that is going to be called. (Usually this reference is obtained from a ServiceLocator). The business delegate Calls the remote object, and on response, invoke's the Command Object's result method, which is in charge of updating the model in the Model Locator.

Groovy Dynamic Typing

Groovy Dynamic Beahaviour.

As oposed to Java, Groovy is dynamically typed. Which basically means that the type is not checked at compile time, but instead only at runtime.
Besides some drawbacks, this allows to do many cool things including Duck Typing.
The principle of duck typing is that "if it quacks like a duck it's a duck". this basically means that the behaviour of the Object is based on the use it has on the application, not on its specific type.
In essence this allows to call an object's methods without knowing (at compile time) that these methods exist. In Runtime the methods are invoked. Note that this works even with two different unrelated (No hierarchy or interfaces shared) objects, that implements the method, and precisely this is the beauty of it.

For example

[CODE]
def metodo(anything){
anything.call(144)
}

metodo{
println it
}

def clos2= {println it+it}
metodo(clos2)

class X{
public def call(value){
println value*3
}
}

metodo(new X())
[/CODE]

As you can see, the method "metodo" is called three times with different types.
The first two times is called with a Closure, one inline closure and other declared closure.
And the third time with a totally different object X. That happens to implement the methdo in its own way.

Understanding workflow languages

Using JBPM as a starting point and taking a look at its documentation, I’ve realized that it’s not really that hard to build a very simple Workflow Model. It basically consists of the following classes.

Node: Each Step in the workflow flow is defined by a node. A node is a Command object (Command Design Pattern) and has references to the incoming transitions and to the outgoing transitions.

Transition: A directional link that links two nodes together.

Execution: An execution is the context that the workflow is currently working on. An execution has a reference to the node it is at the moment. Transitions pass this context from node to node.

So the workflow basically works this way.

An Execution object is instantiated with a reference to the first node. From that point on, the execution of the flow is controlled by events passed to the Execution Object.
In general, Nodes are responsible for sending events to the Execution Object, determining what the execution of the process will do next.

So this is a very simple example of a workflow Model implementation. In Pseudo.

Class XNode implements Node{
Public execute(Execution exe){
doSomething…..
exe.event(“transicionA”)
}
}
Class Execution{
Node currentNode;
Public event(Event e){
currentNode.getTransitionForEvent(e).take(this)
}
}
Class Transition{
Node origin;
Node destination;
Public take(Execution e){
destination.execute(e)
}
}