¿Debo crear instancias de variables de instancia en la declaración o en el constructor?

Otra opción sería usar Inyección de dependencias.

class A{
   B b;

   A(B b) {
      this.b = b;
   }
}

Esto elimina la responsabilidad de crear el objeto B del constructor de A. Esto hará que su código sea más comprobable y más fácil de mantener a largo plazo. La idea es reducir el acoplamiento entre las dos clases A y B. Un beneficio que esto le da es que ahora puede pasar cualquier objeto que extienda B (o implemente B si es una interfaz) al constructor de A y funcionará. Una desventaja es que renuncias a la encapsulación del objeto B, por lo que está expuesto al llamador del constructor A. Tendrá que considerar si los beneficios valen esta compensación, pero en muchos casos lo son.

Hoy me quemé de una manera interesante:

class MyClass extends FooClass {
    String a = null;

    public MyClass() {
        super();     // Superclass calls init();
    }

    @Override
    protected void init() {
        super.init();
        if (something)
            a = getStringYadaYada();
    }
}

Ver el error? Resulta que el inicializador a = null se llama después de se llama al constructor de superclase. Dado que el constructor de superclase llama a init(), la inicialización de a es seguida de por la inicialización de a = null.

Mi "regla" personal (casi nunca rota) es:

• declare todas las variables al inicio de un bloque
• hacer que todas las variables sean definitivas a menos que no puede ser
• declare una variable por línea
• nunca inicializar una variable donde declarado
• solo inicializar algo en un constructor cuando necesita datos de el constructor para hacer el inicialización

Así que tendría un código como:

public class X
{
    public static final int USED_AS_A_CASE_LABEL = 1; // only exception - the compiler makes me
    private static final int A;
    private final int b;
    private int c;

    static 
    { 
        A = 42; 
    }

    {
        b = 7;
    }

    public X(final int val)
    {
        c = val;
    }

    public void foo(final boolean f)
    {
        final int d;
        final int e;

        d = 7;

        // I will eat my own eyes before using ?: - personal taste.
        if(f)
        {
            e = 1;
        }
        else
        {
            e = 2;
        }
    }
}

De esta manera siempre estoy 100% seguro de dónde buscar declaraciones de variables (al comienzo de un bloque), y sus asignaciones (tan pronto como tenga sentido después de la declaración). Esto termina siendo potencialmente más eficiente, ya que nunca inicializa una variable con un valor que no se utiliza (por ejemplo, declarar e iniciar vars y luego lanzar una excepción antes de la mitad de los vars necesarios para tener un valor). Tampoco termina haciendo inicialización sin sentido (como int i = 0; y luego más tarde, antes de que se use "i", do i = 5;.

I valora mucho la consistencia, así que seguir esta "regla" es algo que hago todo el tiempo, y hace que sea mucho más fácil trabajar con el código ya que no tienes que buscar para encontrar cosas.

Su kilometraje puede variar.

El ejemplo 2 es menos flexible. Si agrega otro constructor, debe recordar crear instancias del campo en ese constructor también. Solo instanciar el campo directamente, o introducir la carga perezosa en algún lugar de un getter.

Si la instanciación requiere algo más que un simple new, use un bloque inicializador. Esto se ejecutará independientemente de del constructor utilizado. Por ejemplo,

public class A {
    private Properties properties;

    {
        try {
            properties = new Properties();
            properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("file.properties"));
        } catch (IOException e) {
            throw new ConfigurationException("Failed to load properties file.", e); // It's a subclass of RuntimeException.
        }
    }

    // ...

}

Supongo que es casi solo una cuestión de gusto, siempre y cuando la inicialización sea simple y no necesite ninguna lógica.

El enfoque constructor es un poco más frágil si no utiliza un bloque inicializador, porque si más tarde agrega un segundo constructor y olvida inicializar b allí, obtendrá un null b solo cuando use ese último constructor.

Véase http://java.sun.com/docs/books/tutorial/java/javaOO/initial.html para más detalles sobre la inicialización en Java (y para explicaciones sobre bloques initalizer y otras características de inicialización no conocidas).

Siempre es preferible usar inyección de dependencia o inicialización perezosa, como ya se explicó a fondo en otras respuestas.

Cuando no quieres o no puedes usar esos patrones, y para tipos de datos primitivos, hay tres razones convincentes que puedo pensar de por qué es preferible inicializar los atributos de la clase fuera del constructor:

1. se evitó la repetición = si tienes más de un constructor, o cuando necesitarás agregue más, no tendrá que repetir la inicialización una y otra vez en todos los cuerpos de los constructores;
2. legibilidad mejorada = puede saber fácilmente con un vistazo qué variables tendrán que inicializarse desde fuera de la clase;
3. líneas de código reducidas = por cada inicialización realizada en la declaración habrá una línea menos en el constructor.

Ambos métodos son aceptables. Tenga en cuenta que en este último caso b=new B() puede no ser inicializado si hay otro constructor presente. Piense en el código del inicializador fuera del constructor como un constructor común y el código se ejecuta.

Creo que el ejemplo 2 es preferible. Creo que la mejor práctica es declarar fuera del constructor e inicializar en el constructor.

El segundo es un ejemplo de inicialización perezosa. El primero es la inicialización más simple, son esencialmente iguales.

Hay una razón más sutil para inicializar fuera del constructor que nadie ha mencionado antes (muy específica debo decir). Si está utilizando herramientas UML para generar diagramas de clases a partir del código (ingeniería inversa), creo que la mayoría de las herramientas notarán la inicialización del Ejemplo 1 y lo transferirán a un diagrama (si prefiere que muestre los valores iniciales, como yo). No tomarán estos valores iniciales del ejemplo 2. Una vez más, esta es una razón muy específica-si usted están trabajando con herramientas UML, pero una vez que aprendí eso, estoy tratando de tomar todos mis valores predeterminados fuera de constructor a menos que, como se mencionó antes, haya un problema de posible lanzamiento de excepciones o lógica complicada.

La segunda opción es preferible ya que permite utilizar diferentes lógicas en los ctors para la instanciación de clases y utilizar el encadenamiento de los ctors. Por ejemplo,

class A {
    int b;

    // secondary ctor
    A(String b) {
         this(Integer.valueOf(b));
    }

    // primary ctor
    A(int b) {
         this.b = b;
    }
}

Así que la segunda opción es más flexible.

No he visto lo siguiente en las respuestas:

Una posible ventaja de tener la inicialización en el momento de la declaración podría ser con IDE de hoy en día donde se puede saltar muy fácilmente a la declaración de una variable (en su mayoría Ctrl-<hover_over_the_variable>-<left_mouse_click>) desde cualquier lugar de su código. A continuación, se ve inmediatamente el valor de esa variable. De lo contrario, debe "buscar" el lugar donde se realiza la inicialización (principalmente: constructor).

Esta ventaja es, por supuesto, secundaria a todos los demás razonamientos lógicos, pero para algunas personas que "característica" podría ser más importante.