Abstract builders should not declare an abstract build() method

[koritakoa]

...and certainly not a package-private one.

In Item 2, the abstract Pizza class declares an abstract Builder class. This abstract builder declares an abstract
build method: abstract Pizza build();. I argue that this is unnecessary and incorrect.

The problem is that by declaring the abstract build method without checked exceptions, the abstract builder class is
forbidding subclasses from throwing checked exceptions from the build method.

The builder pattern is being used in place of constructors here. Having a build method that prevents subclasses from
throwing checked exceptions is like having a constructor that prevents subclasses from throwing checked exceptions in
their constructors.

It is incorrect of the author of the abstract builder class to assume that subclasses would not wish to throw checked
exceptions from their build methods or from the constructors these build method call.

I argue that declaring the abstract build method in the abstract builder is unnecessary because it is not the concern
of the author of the abstract builder class. The author of the abstract builder class should be concerned with writing
setters for values required by the constructor and retrieving these values in the constructor of the target class.

If a subclass of the builder does not have a build method that results in the builder being passed to the target type
constructor, then it is a failure on the part of the subclass, not the abstract builder superclass.

I acknowledge that constructors should be used to construct objects, not do extensive work. As such, we should probably
be mostly throwing RuntimeExceptions from constructors because of validation errors. However, sometimes constructors
do throw checked exceptions (like FileOutputStream). We may also wish to do work which may throw a checked exception
in the build method itself before calling the constructor of a subclass.

I also acknowledge that declaring the abstract build method helps to create subclasses of the builder with
consistently named build methods. Note that because the abstract build method is declared with package-private
access, this consistency is only probable (subclass authors will probably do the logical thing and override it with a
public access modifier - but they may do something weird), and not really that useful. The method is not part of a
consistent API shared by all instances of builders. All instances of builders probably have a build method, but other
classes cannot call Pizza.Builder.build(), only NyPizza.Builder.build() etc. You cant do this:

Collection<Pizza.Builder<?>> l = something();
l.stream().map(Pizza.Builder::build)

With package-private access, the abstract build method is not useful enough to warrant forbidding subclasses from
throwing checked exceptions.

If a consistent API across subclasses of Pizza.Builder is required then the build method should be declared
public in the abstract builder, and the author of the abstract builder should consider allowing subclasses to throw
checked exceptions.

I think authors of abstract builders should ask themselves if their task it to make their target class constructor
easier to use or if their task is to write API for a factory of their target class.