Does Class.newInstance() follow the “Abstract fact

Question

I have started reading Joshua Bloch's "Effective Java" (second edition). While reading item 2 (Consider a builder when faced with many constructor parameters), there is a particular statement that the author makes w.r.t the Class.newInstance() method. Specifically, the author says that

The traditional Abstract Factory implementation in Java has been the "Class" object, with the "newInstance" method playing the part of the "build" method.

This part has me confused a little bit - my understanding of the Abstract factory design pattern is that it is used to represent a factory of factories. The Class.newInstance() method, in my opinion, borders more on the "static factory method" coding philosophy (which incidentally, is item 1 in the same book)

Thoughts, anyone? I have been preparing hard to crack a few tough interviews and would really appreciate it if my fundamentals were solid before appearing for such interviews.

Thanks.

Answer 1

In my opinion, he is referring to code such as the following:

Integer.class.newInstance();

Where Class<T> is the abstract factory. It became concrete when you passed the type parameter, e.g. Integer. You then called the "builder", newInstance().

Answer 2

Here's my opinion.

First of all, the Abstract Factory pattern is not intended to be a factory of factories. The key aspect of this pattern is that there is an accessible interface with an underlying (probably inaccessible) factory implementation through which you can get accessible interfaces of (probably inaccessible) object implementations. I know, is a long nasty wordplay of how I understand some of the applicability conditions of this pattern in Gamma's book:

• a system should be independent of how its products are created, composed, and represented
• you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

At the end you're getting objects, not factories.

Second, I wouldn't make 1:1 relationships between pattern concepts and language keywords. "Abstract Factory" does not necessarily always translate to the Java abstract class or interface constructs. You can still have a regular, extendable, instantiable class that represents an "Abstract Factory" as long as you somehow guarantee that the client code is independent of the underlying factory and object implementations. This is the case of java.lang.Class, which is not abstract nor an interface, but does the job at hiding the parameterless constructor implementation of the type it represents through the newInstance() method. It's probably clearer if you use it like:

Object o = Class.forName(type).newInstance();

Class plays the "Abstract Factory", and Object plays the "Abstract Product" to the type implementation.

Last, newInstance() is not a static factory method, I think because this pattern is intended to return instances of the class it is implemented on. newInstance() does not return instances of Class nor sub-Classes. It returns instances of the type it represents. It neither is a "Factory Method" just as Bloch states in his book.

Answer 3

I don't think anything suggests that Abstract Factory is "a factory of factories". An AbstractFactory<T> does not create factories that create Ts, it creates Ts directly.

The idea that it's abstract is to allow the logic to create T to be injected. So for example, you could have:

public interface ConnectionFactory {
    Connection newConnection();
}

//passed to your object normally:
public class RealConnectionFactory implements ConnectionFactory {
    //...
}

//passed to your object when unit testing:
public class FakeConnectionFactory implements ConnectionFactory {
    //...
}

//...

public class MyDao {
   public MyDao(ConnectionFactory connectionFactory) {
       this.conn = connectionFactory.newConnection();
   }
}

In this case, ConnectionFactory creates Connections, but is abstract because it is an interface.

I tend to agree with you that Class<?>.newInstance() is not a canonical example of an abstract factory, because Class is not abstract, and in fact it can't be extended. You can't ask for a Class<Integer> and have one implementation initialize the new value to 1, and another initialize the new value to 7.

You could however stretch things by saying something like Class<? extends InputStream> is an abstract factory of InputStreams, with concrete implementations Class<SocketInputStream> and Class<FileInputStream>. This is not the traditional meaning of "abstract" though (there's still just one class: Class).

But even then it's useless as an abstract factory, because the way that you implement a new concrete version of the "factory" is by creating a new class that extends InputStream. This is hardly what abstract factories are intended for.