Использование инициализаторов и конструкторов в Java

Статические инициализаторы полезны, как упоминал cletus, и я использую их таким же образом. Если у вас есть статическая переменная, которая должна быть инициализирована при загрузке класса, тогда вам подойдет статический инициализатор, особенно потому, что он позволяет вам выполнять сложную инициализацию и по-прежнему иметь статическую переменную final. Это большая победа.

Я считаю "if (someStaticVar == null) // делать что-нибудь" беспорядочным и подверженным ошибкам. Если он инициализирован статически и объявлен final, вы избегаете того, чтобы он был null.

Однако меня сбивает с толку, когда вы говорите:

Инициализаторы static / instance могут использоваться для установки значения "final" статических переменных / переменных экземпляра, тогда как конструктор не может

Я предполагаю, что вы говорите оба:

• статические инициализаторы могут использоваться для установки значения "конечных" статических переменных, тогда как конструктор не может
• инициализаторы экземпляра могут использоваться для установки значения "конечных" переменных экземпляра, тогда как конструктор не может

и вы правы в первом пункте, неправы во втором. Вы можете, например, сделать это:

class MyClass {
    private final int counter;
    public MyClass(final int counter) {
        this.counter = counter;
    }
}

Кроме того, когда конструкторы разделяют большой объем кода, один из лучших способов справиться с этим - связать конструкторы в цепочку, предоставив значения по умолчанию. Это делает довольно понятным, что делается:

class MyClass {
    private final int counter;
    public MyClass() {
        this(0);
    }
    public MyClass(final int counter) {
        this.counter = counter;
    }
}

Анонимные внутренние классы не могут иметь конструктора (поскольку они анонимны), поэтому они вполне естественно подходят для инициализаторов экземпляров.

Я чаще всего использую блоки статического инициализатора для настройки конечных статических данных, особенно коллекций. Например:

public class Deck {
  private final static List<String> SUITS;

  static {
    List<String> list = new ArrayList<String>();
    list.add("Clubs");
    list.add("Spades");
    list.add("Hearts");
    list.add("Diamonds");
    SUITS = Collections.unmodifiableList(list);
  }

  ...
}

Теперь этот пример можно выполнить с помощью одной строки кода:

private final static List<String> SUITS =
  Collections.unmodifiableList(
    Arrays.asList("Clubs", "Spades", "Hearts", "Diamonds")
  );

но статическая версия может быть намного аккуратнее, особенно когда элементы нетривиально инициализировать.

Наивная реализация также может не создать неизменяемый список, что является потенциальной ошибкой. Вышеупомянутое создает неизменяемую структуру данных, которую вы можете с радостью вернуть из общедоступных методов и так далее.

Просто чтобы добавить сюда уже несколько отличных моментов. Статический инициализатор является потокобезопасным. Он выполняется при загрузке класса и, таким образом, упрощает инициализацию статических данных, чем использование конструктора, в котором вам понадобится синхронизированный блок, чтобы проверить, инициализированы ли статические данные, а затем фактически инициализировать их.

public class MyClass {

    static private Properties propTable;

    static
    {
        try 
        {
            propTable.load(new FileInputStream("/data/user.prop"));
        } 
        catch (Exception e) 
        {
            propTable.put("user", System.getProperty("user"));
            propTable.put("password", System.getProperty("password"));
        }
    }

против

public class MyClass 
{
    public MyClass()
    {
        synchronized (MyClass.class) 
        {
            if (propTable == null)
            {
                try 
                {
                    propTable.load(new FileInputStream("/data/user.prop"));
                } 
                catch (Exception e) 
                {
                    propTable.put("user", System.getProperty("user"));
                    propTable.put("password", System.getProperty("password"));
                }
            }
        }
    }

Не забывайте, что теперь вам нужно синхронизировать на уровне класса, а не экземпляра. Это влечет за собой стоимость каждого созданного экземпляра вместо единовременной стоимости при загрузке класса. К тому же это некрасиво ;-)

Я прочитал целую статью в поисках ответа на вопрос о порядке инициализации инициализаторов и их конструкторов. Я не нашел его, поэтому написал код, чтобы проверить свое понимание. Я подумал, что добавлю эту небольшую демонстрацию в качестве комментария. Чтобы проверить свое понимание, посмотрите, сможете ли вы предсказать ответ, прежде чем читать его внизу.

/**
 * Demonstrate order of initialization in Java.
 * @author Daniel S. Wilkerson
 */
public class CtorOrder {
  public static void main(String[] args) {
    B a = new B();
  }
}

class A {
  A() {
    System.out.println("A ctor");
  }
}

class B extends A {

  int x = initX();

  int initX() {
    System.out.println("B initX");
    return 1;
  }

  B() {
    super();
    System.out.println("B ctor");
  }

}

Выход:

java CtorOrder
A ctor
B initX
B ctor

Статический инициализатор - это эквивалент конструктора в статическом контексте. Вы наверняка увидите это чаще, чем инициализатор экземпляра. Иногда вам нужно запустить код для настройки статической среды.

В общем, инициализатор экземпляра лучше всего подходит для анонимных внутренних классов. Взгляните на книгу рецептов JMock, чтобы увидеть инновационный способ ее использования, чтобы сделать код более читабельным.

Иногда, если у вас есть какая-то логика, которую сложно связать между конструкторами (скажем, вы создаете подкласс и не можете вызвать this (), потому что вам нужно вызвать super ()), вы можете избежать дублирования, выполнив общие вещи в экземпляре инициализатор. Однако инициализаторы экземпляров настолько редки, что для многих они представляют собой удивительный синтаксис, поэтому я избегаю их и предпочел бы сделать свой класс конкретным, а не анонимным, если мне нужно поведение конструктора.

JMock - исключение, потому что именно так предполагается использовать фреймворк.

При выборе необходимо учитывать один важный аспект:

Блоки инициализатора являются членами класса / объекта, а конструкторы - нет. Это важно при рассмотрении расширения / создания подкласса:

1. Инициализаторы наследуются подклассами. (Хотя может быть затенен)
   Это означает, что в основном гарантируется, что подклассы инициализируются так, как задумано родительским классом.
2. Однако конструкторы не наследуются. (Они вызывают только super() [т.е. без параметров] неявно, или вам нужно сделать конкретный вызов super(...) вручную.)
   Это означает, что неявный или неявный вызов super(...) может не инициализировать подкласс, как задумано родительским классом.

Рассмотрим этот пример блока инициализатора:

    class ParentWithInitializer {
        protected String aFieldToInitialize;

        {
            aFieldToInitialize = "init";
            System.out.println("initializing in initializer block of: " 
                + this.getClass().getSimpleName());
        }
    }

    class ChildOfParentWithInitializer extends ParentWithInitializer{
        public static void main(String... args){
            System.out.println(new ChildOfParentWithInitializer().aFieldToInitialize);
        }
    }

выход:

initializing in initializer block of: ChildOfParentWithInitializer
init

-> Независимо от того, какие конструкторы реализует подкласс, поле будет инициализировано.

Теперь рассмотрим этот пример с конструкторами:

    class ParentWithConstructor {
        protected String aFieldToInitialize;

        // different constructors initialize the value differently:
        ParentWithConstructor(){
            //init a null object
            aFieldToInitialize = null;
            System.out.println("Constructor of " 
                + this.getClass().getSimpleName() + " inits to null");
        }

        ParentWithConstructor(String... params) {
            //init all fields to intended values
            aFieldToInitialize = "intended init Value";
            System.out.println("initializing in parameterized constructor of:" 
                + this.getClass().getSimpleName());
        }
    }

    class ChildOfParentWithConstructor extends ParentWithConstructor{
        public static void main (String... args){
            System.out.println(new ChildOfParentWithConstructor().aFieldToInitialize);
        }
    }

выход:

Constructor of ChildOfParentWithConstructor inits to null
null

-> Это инициализирует поле по умолчанию на null, даже если это может быть не тот результат, который вам нужен.

Я также хотел бы добавить одно замечание ко всем приведенным выше сказочным ответам. Когда мы загружаем драйвер в JDBC с помощью Class.forName (""), происходит загрузка класса и запускается статический инициализатор класса Driver, а код внутри него регистрирует драйвер в диспетчере драйверов. Это одно из важных применений статического блока кода.

Как вы упомянули, во многих случаях это бесполезно, и, как и в случае с любым менее используемым синтаксисом, вы, вероятно, захотите избежать его, просто чтобы следующий человек, смотрящий на ваш код, не потратил 30 секунд на то, чтобы вытащить его из хранилищ.

С другой стороны, это единственный способ сделать несколько вещей (я думаю, вы в значительной степени охватили их).

Сами статические переменные в любом случае следует избегать - не всегда, но если вы используете их много или много в одном классе, вы можете найти разные подходы, и ваше будущее будет вам благодарно.