tags:

views:

89

answers:

4

For the use in a Servlet based application I've written a class to store a view name and objects to be rendered. Actually it is more a data structure than a class in the sense of OOP. I wonder if I should expose the members or if should use getters.

public class Result {

    private final int status;
    private final String view;
    private final Map<String, Object> model = new HashMap<String, Object>();

    public Result(final int status, final String view) {
        this.status = status;
        this.view = view;
    }

    public Result put(final String modelName, final Object modelObject) {
        model.put(modelName, modelObject);
        return this;
    }

}

Should I add getStatus(), getView() and getModel() or should I change the member visibility to "public"? At the moment I don't know any scenario where it would be useful to have a method to access a member. "Result" is an immutable datastructure and no computations are needed when members are accessed. Would you add getters for the unlikely event that the implementation changes?

Addendum

I read a section related to my question in Robert C. Martins excellent book Clean Code (page 99):

Hybrids

This confusion [about objects and data structures] sometimes lead to unfortunate hybrid structures that are half object and half data structure. They have functions that do significant things, and they also have either public variables or public accessors and mutators that, for all intents and purposes, make the private variable public, tempting other external functions to use those variables the way a procedural program would use a data structure.

Such hybrids make it hard to add new functions but also make it hard to add new data structures. They are the worst of both worlds. Avoid creating them. They are indicative of muddled design whose authors are unsure of - or worse, ignorant of - whether they need protection from functions or types.

+1  A: 

Have a look at

benefits of getter/setter VS public vars?

astander
+2  A: 

For a data-holder class creating getters or not is a matter of taste. Based on your description you can make the visibility public or package on status and view, but I would add a getter for retrieving a model by name. Although the map is final, its contents is not.

Edit I meant something like:

public Object get(final String modelName) {
    return model.get(modelName);
}

There is no reason to make the model map visible. (I would name the map "models" and use setModel(name, model) and getModel(name) as accessors.)

rsp
Do you mean something like this?public Map getModel() { return java.util.Collections.unmodifiableMap(model);}
deamon
+1 and I'll also point out one disadvantage: If you change you mind later and decide to create getters/setters, you'll have to change all of your clients. Java has no notion of properties built into the language.
Rob H
The reason to expose the map is that a template engine like FreeMarker can handle maps directly.
deamon
In that case returning an unmodifiable map is a good approach. Instead of creating a new one every time, I would create one and keep a reference to it as attribute in the getter and `null` the reference in `put()`.
rsp
+1  A: 

I can't make concrete recommendations as it would depend on how you're going to be using that class. However...

I often create "lightweight" objects intended as data structures to transport some immutable data. Like you, I make the members public final and initialize them in the constructor.

The risks associated with accessible, mutable data members aren't there when they're final; all you're losing is the ability to meaningfully subclass the class. Also, you can't attach functionality to data access. But for a lightweight data transfer object, chances are you won't be doing that anyway.

Carl Smotricz
+1  A: 

You say:

At the moment I don't know any scenario where it would be useful to have a method to access a member.

That's precisely why I'd advocate accessing the data via getters. At the moment you're using the object to store corresponding objects in your model. However your model may well change in the future, and yet you may want to display the data in the view in the same fashion.

Given that, and the headache in testing the view component of an MVC, I would always implement the getter/setter mechanism.

Brian Agnew