title: Entity objects getters and setters for data properties
body: <p>I recently started working in Java and was introduced to the wild and crazy world of getters and setters for everything. I hated it at first, but quickly got used to it. Too used to it.</p>
  
  <p>I have been spending a lot of time lately thinking more about class design. One of the things I am trying to do is avoid the trap of doing getters and setters for everything. However, much of the work I do is with entities that are mainly data containers and I am not certain that getters and setters are actually inappropriate in these cases.</p>
  
  <p>Here is a simple example using public properties.</p>
  
  <pre><code>class Space {
      public String name;
      public String description;
      Space(final String name, final String description) {
          this.name = name;
          this.description = description;
      }
  }
  </code></pre>
  
  <p>Here is a simple example using private properties and using getters and setters.</p>
  
  <pre><code>class Space {
      private String name;
      private String description;
      Space(final String name, final String description) {
          this.name = name;
          this.description = description;
      }
      public String getName() {
          return this.name;
      }
      public void setName(final String name) {
          this.name = name;
      }
      public String getDescription() {
          return this.description;
      }
      public void setDescription(final String description) {
          this.description = description;
      }
  }
  </code></pre>
  
  <p>In these examples, both the <code>name</code> and the <code>description</code> fields should be able to be changed.</p>
  
  <p>I feel like the getter/setter example is more clear and hides the implementation details of what <code>name</code> and <code>description</code> are. It would also allow for validation on set later if needed.</p>
  
  <p>I have read several discussions about getters and setters being evil and/or an anti-pattern, but it really feels like those might not apply to this situation.</p>
  
  <p>Maybe there are some options I have not yet considered. I'm open for suggestions!</p>