I am trying to incorporate more functional programming idioms into my java development. One pattern that I like the most and avoids side effects is building classes that have behavior but they don’t necessarily have any state. The behavior is locked into the methods but they only act on the parameters passed in.
The code below is code I am trying to avoid:
public class BadObject {
private Map<String, String> data = new HashMap<String, String>();
public BadObject() {
data.put("data", "data");
}
/**
* Act on the data class. But this is bad because we can't
* rely on the integrity of the object's state.
*/
public void execute() {
data.get("data").toString();
}
}
The code below is nothing special but I am acting on the parameters and state is contained within that class. We still may run into issues with this class but that is an issue with the method and the state of the data, we can address issues in the routine as opposed to not trusting the entire object.
Is this some form of idiom? Is this similar to any pattern that you use?
public class SemiStatefulOOP {
/**
* Private class implies that I can access the members of the <code>Data</code> class
* within the <code>SemiStatefulOOP</code> class and I can also access
* the getData method from some other class.
*
* @see Test1
*
*/
class Data {
private int counter = 0;
public int getData() {
return counter;
}
public String toString() { return Integer.toString(counter); }
}
/**
* Act on the data class.
*/
public void execute(final Data data) {
data.counter++;
}
/**
* Act on the data class.
*/
public void updateStateWithCallToService(final Data data) {
data.counter++;
}
/**
* Similar to CLOS (Common Lisp Object System) make instance.
*/
public Data makeInstance() {
return new Data();
}
} // End of Class //
Issues with the code above:
-
I wanted to declare the Data class private, but then I can’t really reference it outside of the class:
-
I can’t override the SemiStateful class and access the private members.
Usage:
final SemiStatefulOOP someObject = new SemiStatefulOOP();
final SemiStatefulOOP.Data data = someObject.makeInstance();
someObject.execute(data);
someObject.updateStateWithCallToService(data);
Edit-1: This is a good comment. My response: “As soon as you make the Data class accessible outside the main class you are exposing implementation details, ” — comment.
My Response: The Data class is a simple POJO and will work like other pojos with setters and getters. What I was doing in the class above was trying to only manipulate the Data class from the behavior class, SemiStatefulOOP. I do intend to have stateless classes but I wanted to have a clear separation from the state classes and the behavior classes.
Related:
Stateless Design Pattern
http://guides.brucejmack.biz/Pattern%20Documents/Stateless%20Design%20Pattern.htm
There’s an interesting OO architectural style that aims to separate the data and the behavior of a system, so that they can evolve independently: the DCI Architecture.
In practice, you create data objects for your domain concepts (possibly only with simple behavior related to the data itself); and behavior objects that work with the data objects and that realize the use cases of the system. These behavior objects are seen as roles that the domain objects can play, and are materialized with the OO concept of a trait (pdf).
Scala has traits, but Java doesn’t. You can try to use the Qi4J framework in Java for that.