[Proleps]

why not use:

  public final class Article{
    public final String title;
    public final String author;
    public final List<String> tags;
    public Article(String title, String author, List<String> tags) {
      this.title = title;
      this.author = author;
      this.tags = tags;
    }
  }

Getters don't seem very useful on an immutable object.

[organsnyder]

If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API.

For instance, let's say that you don't want to store the author's name as a string anymore, and want to store a reference to an Author object. If you have a getAuthor() method, you can change it from a simple getter to instead call author.getName(), preserving your public-facing API.

[TheLoneWolfling]

And this is one of the major reasons why Java is regarded as verbose. There's a simple solution (have the compiler transparently rewrite references to x.foo to x.getFoo / x.setFoo and transparently add getFoo/setFoo - the JVM inlines (trivial) getters and setters anyways) and yet Java, in the interests of "transparency", doesn't allow it.

And their justification fails. Sure, currently if you read x.foo you know that no code is being executed - but you never see x.foo because everything has getters and setters. So all it does in practice is make things (even) more verbose.

[0942v8653]

That's one of my favorite things about Swift. I can do, for example:

    // version 1
    var author: String

    // version 2
    var author: String {
        get {"\(authorFirst) \(authorLast)"}
    }

[robwilliams]

C# as well. C# 6 is very concise.

[virmundi]

So I think a fair question at this point is how often does that happen? To further inquire, how often does that happen in contexts that you don't control?

I'm sure that library/framework people need to worry about that. Most normal developers do not. For many cases Java objects like Article are just structs. They are static maps. Sure, in the example on the site there was a getTags that added some logic, but still, pretty much a struct.

Switching to either public accessor for mutable or immutable objects actually will stream line code. You might say that public mutators are bad; encapsulation and all that. For the most part little is actually gained in the majority of getter/setter code to necessitate their weight.

Heck, as per the JavaBean spec (a spec for making components to create drag and drop UIs by the way), you can't even have fluent APIs where the setter returns "this". It has to be void.

API stability has value. If you're a library, you probably want to do this just to be safe. But really for most imperative Java code it's just a lot of fluff for little value.

[V-2]

Besides, getters and setters are debuggable. They allow you for setting breakpoints, adding Log calls etc... Not so in case of fields.

It would be nice to have some syntax sugar for defining properties more tersely though, like in C#.

[organsnyder]

Project Lombok allows you to use annotations to create getters and setters:

  @Getter
  private String author;
  @Getter
  private String title;

Or, on the class, here with a fluent (non-JavaBean) API:

  @Data
  @Accessors(fluent = true) // experimental
  public class Article {
    private String author;
    ...
  }

[thescrewdriver]

That's also one of the differences between Scala and Java. In Scala you have referential transparency, so you easily can switch between fields/properties and methods without changing the calling code.

[Proleps]

> If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API.

Then it wouldn't be immutable, if I can change the implementation I can also create a mutable version.

Edit example

  public class Article {
      private final String title;
      private final String author;
      private final List<String> tags;

      private Article(String title, String author, List<String> tags) {
          this.title = title;
          this.author = author;
          this.tags = tags;
      }

      public String getTitle() {
          return title;
      }

      public String getAuthor() {
          return author;
      }

      public List<String> getTags() {
          return tags;
      }
  }

  public class MutableArticle extends Article {
      private String title;
      private String author;
      private List<String> tags;

      public MutableArticle() {
          super(null, null, null);
      }

      public String getTitle() {
          return title;
      }

      public void setTitle(String title) {
          this.title = title;
      }

      public String getAuthor() {
          return author;
      }

      public void setAuthor(String author) {
          this.author = author;
      }

      public List<String> getTags() {
          return tags;
      }

      public void setTags(List<String> tags) {
          this.tags = tags;
      }

  }

[organsnyder]

Making a class immutable doesn't mean that the implementation is fixed. If you need to change your implementation to store data differently, the consumers of your API shouldn't need to be modified. The following modification to your first class would still be immutable:

  public class Article {
    private final Author author;
    ...
    public String getAuthor() {
      return author.getName();
    }
  }

Also, your first class isn't fully immutable—getTags should be implemented as follows:

  /**
   * @return Unmodifiable list of tags
   */
  public List<String> getTags() {
    return Collections.unmodifiableList(tags);
  }

[Proleps]

> Also, your first class isn't fully immutable—getTags should be implemented as follows:

True. It would be nice if Java had some immutable collection classes that don't have mutable methods. A method that gets a List<String> made with Collections.unmodifiableList(tags), doesn't know that it is actually immutable.

[potatosareok]

For some reason seeing your code really bothers me. Is it normal to ever use private variables in inheritance like that?

Say you had toString() in Article class that returned ("%s%" author, title).

Now if you create a MutableArticle on it, ma.toString() will return null unless you override toString on it as well (since Articles variables are private and not inherited).

I don't code much so I don't know is it normal to see code like that?

Also less relevant but Articles constructor should probably be public?

[organsnyder]

I agree that this design is sub-optimal. However, if a.toString() called the getters instead of using the instance variables directly, you wouldn't have problems.

The Article class is unusable as provided due to the private constructor (in fact, the MutableArticle class wouldn't even compile), but private constructors can be useful. I often use private constructors and instead provide public static methods that call the constructors. This practice is often derided, and goes into Java's perception as a verbose, arcane language, but it allows for improving an API without breaking clients built to previous versions, as well as making an API more clear (since we can give the static methods more descriptive names).

[potatosareok]

Thanks for taking time to reply. Didn't think about having toString use the getters instead of accessing the instances directly. I guess in some way that's the more proper way of doing it in the context of OOP.

I'm familiar with Java private constructors and builders/factory methods though, that was more of a minor nitpick, but again thanks for explaining on that.

[thescrewdriver]

Java code tends to follow the JavaBeans naming convention even when not implementing beans.

Scala version of your code:

    case class Article(title: String, author: String, tags: List[String])

[V-2]

But you can still modify elements of a final List (thereby modifying the Article object).

Properly implemented getTags should create a copy of tags so that fiddling with the returned value doesn't affect the object.