Анализ и улучшение класса

Условие

В примере показан класс Abstract с двумя приватными финальными полями (int a и String b) и двумя конструкторами. Требуется провести ревью кода и предложить варианты его оптимизации.

package com.jetbulb.interviews;

public class JetbulbInterview {
    public static void main(String[] args) {
    }
}

class Abstract {
    private final int a;
    private final String b;

    public Abstract(int a) {
        this.a = a;
    }

    public Abstract(int a, String b) {
        this.a = a;
        this.b = b;
    }
}

Ответ

Класс не компилируется: конструктор Abstract(int a) не инициализирует final-поле b. Делегируйте его второму конструктору через this(a, значениеПоУмолчанию).

class Abstract {
    private final int a;
    private final String b;

    public Abstract(int a) {
        this(a, null);
    }

    public Abstract(int a, String b) {
        this.a = a;
        this.b = b;
    }
}

Null выбран только как пример разрешённого значения; если b обязательно, одноаргументный конструктор следует убрать либо задать осмысленный default. Название Abstract допустимо, но сбивает с толку: класс от этого не становится abstract. Основное улучшение — ясный контракт и отсутствие дублирования, не микроптимизация.