5

In the new date package in Java 8, we changed from using "new Date()" to "LocalDate.of()".

Date d = new Date(year, month, dayOfMonth);            //Old way
LocalDate d2 = LocalDate.of(year, month, dayOfMonth);  //new way

When you want a new object you usually use the new keyword. This is an intuitive way to create a new object.

Sometimes, when you need a singleton with delayed initialization you can use a static method to get the instance. In this case you must call it getInstance() so developers know what to expect.

This new syntax makes the code less intuitive. It forces you to learn how to deal with specific objects instead of simply using them.

Are there any good reasons under the hood for this change?

Boann
  • 48,794
  • 16
  • 117
  • 146
David Marciel
  • 865
  • 1
  • 12
  • 29
  • 1
    It's called the builder pattern –  Jan 24 '20 at 08:53
  • 7
    The use of static methods like this is actually fairly common, especially with immutable classes. Also, the [package documentation](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/time/package-summary.html) of `java.time` has a section named _Design notes (non normative)_, which says the `of` prefix is used for "static factory methods" as part of the hope of making the API more manageable. – Slaw Jan 24 '20 at 08:57
  • 1
    Builder pattern helps you to set multiple variables in an immutable object before instantiate it. In this case you set all the parameters in a single method, I don´t think it is the same case. – David Marciel Jan 24 '20 at 08:59
  • In the documentation is fairly clear, the point is: the change seems less usable than the previous version, so there must be a good reason to do this change, I wonder why – David Marciel Jan 24 '20 at 09:14
  • 6
    Keep in mind that not just `of` replaced `new`. There's also factory methods such as `LocalDate#ofInstant(Instant,ZoneId)`, `LocalDate#ofYearDay(int,int)`, `LocalTime#ofNanoOfDay(long)`, `LocalTime#ofSecondOfDay(long)`, `LocalDateTime#ofEpochSecond(long,int,ZoneOffset)` and so on. Reading those method names is much clearer than each class having 5+ constructors and having to determine which constructor is being used, and what it does, by tediously inspecting the arguments. – Slaw Jan 24 '20 at 09:28
  • 1
    Factory methods are widespread in Java 8 and 9 and were also used in earlier Java versions. To mention a few: [`DatatypeFactory.newInstance()`](https://docs.oracle.com/javase/10/docs/api/javax/xml/datatype/DatatypeFactory.html#newInstance()) (since Java 1.5). [`Integer.valueOf()`](https://docs.oracle.com/javase/10/docs/api/java/lang/Integer.html#valueOf(int)). [`IntStream.of()`](https://docs.oracle.com/javase/10/docs/api/java/util/stream/IntStream.html#of(int...)). – Ole V.V. Jan 24 '20 at 16:10
  • 2
    Intuitive? I beg to differ. The old way isn’t more intuitive per se, but feels like it because your familiar with it. If there is a difference, `new` is intuitive for guaranteeing a new instance, while `of` is intuitive for not caring whether you get a new instance or an existing one. And since `LocalDate` and friends are immutable and value-based, you do not care. – Ole V.V. Jan 24 '20 at 16:20

3 Answers3

5

Usually static factory methods are preferred to constructors for several reasons,

  • They have a name and that makes your code much more readable.
  • static factory methods can have covariant return types, but constructor can't. This allows your API users to work with the interface, not the implementation, allowing you more room to change the concrete types in future releases. Also it reduces the conceptual surface area of the API too.
  • Unlike constructors, static factory methods can do certain optimizations. On the contrary, every time you call a constructor, you expect it to return a new object. For an instance, check out the implementation of the static factory method Collections.emptyList();
public static final List EMPTY_LIST = new EmptyList<>();

public static final <T> List<T> emptyList() {
    return (List<T>) EMPTY_LIST;
}

It eagerly creates a singleton list and returns it on every invocation saving unnecessary overhead that would occur when constructors were used.

Due to the above reasons, static factories are preferred to constructors in today's programming. However, you can still use the new keyword with constructors as circumstances warrant.

Ravindra Ranwala
  • 20,744
  • 6
  • 45
  • 63
  • 4
    And it allows to hide the actual implementation class, `EmptyList` in the example, from the public API. In case of `java.time`, these classes are further marked explicitly as [value-based](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/doc-files/ValueBased.html) class. – Holger Jan 24 '20 at 10:27
  • 2
    Good catch, I have added it to the point 2. Appreciate it. Thanks ! – Ravindra Ranwala Jan 24 '20 at 10:49
2

There is a problem with new: your code depends on the concrete class. Thus changing/evolving the code is a more difficult task.

A factory is much more manageable because (1) the user code is not dependant on the concrete type (2) the code that choose the concrete type is in a single place. Then the final code is much more secure/evolvable, etc.

getInstance() is not a good name for a factory, it is more the name of a singleton method. "get" is not intended to create something, just to get something already existant. createInstance or create is much more explicit for factories (many of them, even in Java are called such - examine createImage and alike). But alas, for reasons explicited by @slaw in comments, you need to be more precise to help the user choose between argument semantic, thus things like createFromYears, createFromMinutes, etc. That may be slightly verbose, then of seems to be a good compromise. Finally it is more easy (IMHO) to use of*() than createImage() with a lot of parameters to explain what arguments are...

Jean-Baptiste Yunès
  • 34,548
  • 4
  • 48
  • 69
  • 2
    `ZoneId.of()` is a nice example of not depending on the concrete class. What it gives you, is not a `ZoneId`, but an instance of a subclass. – Ole V.V. Jan 24 '20 at 16:23
1

There a design pattern called Fluent interface, which allows "chaining" of methods, see Wikipedia. It's supposed to very readable, imitating natural speech ("get x of y with z").

It's not especially chaining in your example (given it consists of only one method call), but it makes sense to use the same paradigm everywhere.

crusy
  • 1,424
  • 2
  • 25
  • 54
  • 2
    I didn’t get it exactly. What would have hindered method chaining with `new` like `new LocalDate(year, month, dayOfMonth).with(DayOfWeek.THURSDAY).atStartOfDay()`? If they had preferred this designed. – Ole V.V. Jan 24 '20 at 16:26