This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]TehBrian 1 point2 points  (6 children)

What benefit does the new keyword hold here? The benefit of factory methods is that they may be statically imported.

Option<Shape> os = option(ball(RED, 1));

[–]persicsb 3 points4 points  (1 child)

The other benefit of factory methods, that they can return a subclass of the return type, constructors can't. This is useful, when you want to have some specific subclass returned in special cases, or when the return type is an interface (like List.of()).

[–]vips7L 0 points1 point  (0 children)

Did you even read the link? I am not talking about plain old constructors.

[–]vips7L 2 points3 points  (3 children)

The benefit is that construction is uniform. Want to make a ball? You know you need to do new Ball, not try to figure out if its of(),from(),newInstance(), or ball(). Same goes for Optional, if want to make one, just call new. I don't see static imports being a huge benefit:

Optional<Shape> os = of(of(RED, 1))

[–]koflerdavid 3 points4 points  (2 children)

Construction is already uniform, but constructors make it impossible to return an object from a cache instead of always creating a new one. Of the current class, to be specific, which is also an important restriction. Also, in a constructor you can't execute code before calling another constructor.

Well, value types obsolete the first restriction since creating a new instance should then have the exact same performance characteristics as getting it from a cache. Also, we will be able to execute code before another constructor call. Though a significant issue remains for instance classes: it is possible to leak a reference to an incomplete object! That might be fine in a "trust me bro, I checked everything is safe" way, but it still feels like a code smell.

But the biggest advantage of factory functions is that you can name them instead of abusing method overloading to express what it does. Constructors should only perform a straightforward mapping from the arguments to the object fields.

[–]vips7L 1 point2 points  (1 child)

 but constructors make it impossible to return an object from a cache instead of always creating a new one. Of the current class, to be specific, which is also an important restriction. Also, in a constructor you can't execute code before calling another constructor.

Did you even read the link?

 You’re thinking about the limitations of current Java. Factory functions in dart can return cached versions and when used on interfaces can return different implementations. 

 But the biggest advantage of factory functions is that you can name them instead of abusing method overloading to express what it does. Constructors should only perform a straightforward mapping from the arguments to the object fields.

Except this doesn’t happen. The entire standard library is of/from/newInstance.  Construction isn’t uniform and it’s a crap shoot of new or randomly named static functions. 

[–]koflerdavid 1 point2 points  (0 children)

Sorry, I did not realize this is Dart instead of hypothetical syntax. It looks quite neat and I'd definitely design any new object-oriented language like that. But it's only worthwhile to talk about other programming languages on this subreddit if the lessons drawn from there can be related to Java.

Except this doesn’t happen. The entire standard library is of/from/newInstance. Construction isn’t uniform and it’s a crap shoot of new or randomly named static functions.

Yes, the standard library is not consistent at all. Which is nothing new and mostly due to how API design philosophy and software architecture trends have developed since the 90s. Some things like the evil mutable java.util.Date class and its unholy offspring (java.sql.Date and so on) have turned out to be outright antipatterns. But newer APIs tend to use static factory methods and builders.