A big thank you to Chris Barrett who has been taking the time to port Synthesis to Java.

JSynthesis is registered as a GoogleCode project and it will surely be integral to my toolkit next time I work on a Java project.

In my mind, there are two basic attributes that characterize Objects: State and Behavior.

Conceptually, an Object with the absence of any of the two is considered perfectly legal in Java, hence, Stateless Objects and what has long now come to be recognized as Java Beans. Java Beans could be seen as Java’s way of creating and representing custom data-types, they’re type definitions with no behavior or any logic attached to them.

I can see how a Stateless Object is still very much an Object. But take away the behavior, and the need for encapsulation becomes unclear.

An Object without behavior should probably not qualify as an Object.

By behavior, I mean any sense of business logic attached to a Class. This could translate to a class having methods, but field accessors do not qualify as such in my book. To cut a long story short, I don’t think Java Beans should be filed under Object, or declared as Classes.

I don’t see the big deal behind a programming language being purely Object Oriented. I think effective programming largely boils down to abstraction, modeling and elegant code and OO is but a means to achieve this.

And something like this:

structure Line {
  int width;
  String color;
}

looks much leaner – and saner – to me than:

class Line {
  private int width;
  private String color;

  public int getHeight() {
    return height;
  }

  public void setHeight(int height) {
    this.height = height;
  }

  public String getColor() {
    return color;
  }

  public void setHeight(String color) {
    this.color = color;
  }
}

Of course, in the absence of a C-like struct keyword, we can always code Java Beans as:

class Line {
  public int width;
  public String color;
}

but what I’m trying to stress here is the distinction between Data Driven and Behavior Driven modeling and that would become much better enforced with the existence of a behavior-less construct.

We’ve always talked about separating data from logic, although that somehow went down the route of XML configurations and property files and there’s nothing wrong with that, but it probably misses a big portion of the bigger picture.