Structures in Java

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.

7 Responses to “Structures in Java”

  1. Chris Brown Says:

    This is why superior languages like C# have them.

  2. Akshay Says:

    I am also sick of frameworks like webwork and hibernate which impose the need of getters and setters on an object. In an ideal world a single object domain object should be used across all layers from db to presentation without breaking any encapsulation.

  3. n8han Says:

    We need something like ruby’s attr_accessor method. I’ve always hated writing (or generating, or just seeing) brain-dead getters and setters for Java, but I don’t make fields public because 1) people would freak out 2) sometimes you add unanticipated logic to an existing getter or setter.

  4. Guillaume Laforge Says:

    Even with an IDE, getters and setters are painful, even for your eyes. Groovy decided to make this simpler with auto-generated getters and setters:

    class Line {
    int width
    String color
    }

  5. Ricky Clarkson Says:

    ‘Dumb’ Getters and setters aren’t needed in internal code, only library code, as IDEs can automatically refactor public fields to private fields with accessors.

    Delphi (and C#?) provide properties, which allow you to specify what happens when a ‘variable’ is written to or read from.

    Netbeans (not that I run it) has refactoring scripts, which you can give to your clients when you change your library - they run it over their codebase and the IDE applies the refactors to match the change that you made.

    Obviously this is of limited use because it doesn’t work on all 3 Java IDEs.

  6. Jean-Marie Dautelle Says:

    C struct/union are intended for memory mapping.
    The equivalent capability for Java is currently provided by Javolution Struct/Union classes (http://javolution.org/api/javolution/io/Struct.html)

  7. James Law Says:

    Akshay,
    As a fellow setter eradicator, check out access=field in hibernate…

    J