Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm creating a data transfer object and can't decide whether it would be better to just give public access to the instance variables or if there would be a purpose to using getters and setters to access the data?

According to the Data transfer object Wikipedia Article:

A DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

It seems that public access would be justified for a DTO's instance variables.

Here is the example I'm working on:

Ivars with public access modifier:

class ServerContext
{
    public String host;
    public String user;
    public String password;
    public int port;

    ServerContext(String host, String user, String password, int port) {
        this.host = host;
        this.user = user;
        this.password = password;
        this.port = port;
    }
}

vs. private access modifiers:

class ServerContext
{
    private String host;
    private String user;
    private String password;
    private int port;

    ServerContext(String host, String user, String password, int port) {
        setHost(host);
        setUser(user);
        setPassword(password);
        setPort(port);
    }

    public String getHost() {
        return host;
    }

    public void setHost(String host) {
        this.host = host;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public String getUser() {
        return user;
    }

    public void setUser(String user) {
        this.user = user;
    }

    public int getPort() {
        return port;
    }

    public void setPort(int port) {
        this.port = port;
    }
}

EDIT: Could these be valid arguments for keeping the ivars private:

  1. The potential of refactoring a DTO later to have more functionality?

  2. Wanting to keep implementation consistent between DTO and regular objects?

share|improve this question
2  
This question is language-dependent, so I added the Java tag. In most modern languages, you would use properties. –  kevin cline May 24 '13 at 17:12
    
Good point. Thanks! –  Korey Hinton May 24 '13 at 17:13
1  
If you want to make it clear that these are Data Transfer Objects, you should name them something more descriptive, like ServerConfigurationData or ServerContext. –  Robert Harvey May 24 '13 at 19:10
add comment

3 Answers

up vote 0 down vote accepted

In layman's words.

Public instance variables violate encapsulation.

In doing so, client code will be coupled to the names of your instance variables.

Client code should not be coupled to anything internal.

Internal things could change in the future.

External interface ( contract ) should not be affected by changed internals.

If you don't want to manually write your getters and setters let the IDE do it for you.

Also, getters and setters lets you use the builder pattern to construct and "build" an instance of your object without the hundred-parameter constructor.

The class having no-behavior doesn't mean you can violate encapsulation. It also doesn't mean it will never have behavior in the future.

share|improve this answer
    
We're talking about Data Transfer Objects here, not fully-baked, batteries-included objects. Encapsulation only matters here in the sense that the object is a "property bag" container. But the container can still be transparent. –  Robert Harvey May 24 '13 at 19:08
    
@RobertHarvey The client code doesn't know if the object is fully-baked, half-baked or not baked at all. It only should be aware of the public interface. –  user61852 May 24 '13 at 19:12
    
Absolutely. But that public interface can still have public setters, and none of your talking points are really relevant for DTO's. DTO's just contain properties, nothing more. –  Robert Harvey May 24 '13 at 19:12
    
@RobertHarvey Setters are always public so instance variables can be private. –  user61852 May 24 '13 at 19:14
    
Sure. But this is only a problem in Java. In C#, we use "automatic properties," which create their own private backing members behind the scenes. The only reason we don't just use public variables is because they don't share binary compatibility with properties (making conversion of a public variable to a property a breaking change), and since Java doesn't have real properties, it's probably immaterial. –  Robert Harvey May 24 '13 at 19:16
show 1 more comment

I'm creating a data transfer object and can't decide whether it would be better to just give public access to the instance variables or if there would be a purpose to using getters and setters to access the data?

Properties can only be renamed. Get/set methods can be deprecated, validation rules applied and coded to convert data to different types. If you don't need those things then don't waste time.

A DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

Property set/get methods aren't behavior or business logic. They are just access methods to control the scope and access to interval states. A class would still be a DTO with get/set methods.

It seems that public access would be justified for a DTO's instance variables.

If public access to properties was a bad thing. Java wouldn't have the public keyword for properties. If the object works fine with code having read/write access to properties, then why add a ton of get/set methods with one line of code.

If on the other hand you need read-only, then create get methods.

share|improve this answer
    
+ I haven't run into this, but apparently at times beyond serialization, cache and threading can become interested parties to DTO's, making fields a difficult thing to handle in those cases. What @Dainius mentioned less explicitly about using Maps or Hashtables is supposedly a pretty good compromise. –  JustinC May 24 '13 at 19:47
add comment

It depends a bit how these object will be used, normally public visibility would be enough (or how they are called in modern languages - properties), but because it's java, you can have frameworks, where you should have methods to get and set values (setAttribute(), getAttribute() ). If you don't use any framework where you need to have special methods to access object members, I would say use public fields. Of course if you need to write more code lines, then generating extra code for set/get values is better for you.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.