Esecuzione di un metodo dopo il costruttore di una classe derivata

Question

Diciamo che ho una classe Java

abstract class Base { 
    abstract void init(); 
    ... 
} 

e so che ogni classe derivata dovrà chiamare init() dopo che è costruito. Potrei, naturalmente, è sufficiente chiamare nei costruttori delle classi derivate:

class Derived1 extends Base { 
    Derived1() { 
     ... 
     init(); 
    } 
} 

class Derived2 extends Base { 
    Derived2() { 
     ... 
     init(); 
    } 
} 

ma questo si rompe 'Non ripetere te stesso' principio piuttosto male (e ci stanno per essere molte sottoclassi di Base). Naturalmente, la chiamata init() non può andare al costruttore Base(), dal momento che sarebbe stato giustiziato troppo presto.

Delle idee come aggirare questo problema? Sarei abbastanza felice di vedere anche una soluzione di Scala.

UPDATE: Ecco una versione generica del metodo Factory Method:

interface Maker<T extends Base> { 
    T make(); 
} 

class Base { 
    ... 
    static <T extends Base> T makeAndInit(Maker<T> maker) { 
     T result = maker.make(); 
     result.init(); 
     return result; 
    } 
} 

UPDATE 2: Questa domanda è fondamentalmente "come si usa Template Method per i costruttori"? E la risposta sembra essere, "Puoi, ma è una cattiva idea". Quindi posso creare una fabbrica di modelli (metodo di template + factory astratta).

Answer 1

Cosa succede in init()? È probabile che un design migliore possa eliminare del tutto il metodo, o almeno allentare il requisito che viene eseguito dopo il costruttore della sottoclasse. Assicurati che init() non renda visibile l'oggetto in costruzione a nessun altro thread prima del completamento del costruttore, poiché ciò crea bug di concorrenza.

Come alternativa (brutto), un metodo astratto potrebbero essere attuate da sottoclassi come uno pseudo-costruttore:

abstract class Base { 
    Base() { 
    ctor(); 
    init(); 
    } 
    abstract void ctor(); 
    abstract void init(); 
} 

Answer 2

evitare questo. Se lo si fa, ogni classe che estende la classe DerivedX può decidere di chiamare anche init() lasciando così l'oggetto in stato incoerente.

Un approccio è consentire al metodo init() di essere richiamato manualmente dai client della classe. Avere un campo initialized, e buttare IllegalStateExcepion se qualsiasi metodo che richiede l'inizializzazione viene chiamato senza di essa.

Un approccio migliore sarebbe quella di utilizzare un metodo factory statico invece di costruttori:

public Derived2 extends Base { 
    public static Derived2 create() { 
     Derived2 instance = new Dervied2(); 
     instance.init(); 
     return instance; 
    } 
} 

Aggiornamento: Come lei suggerisce nel vostro aggiornamento, è possibile passare Builder ad un metodo factory statica, che chiamerà il init() sull'istanza. Se le sottoclassi sono poche, penso che questa sia una complicazione, comunque.

Answer 3

Oltre a recommendation di Bozho, un contenitore di applicazioni è eccellente per l'attività.

Contrassegnare il proprio metodo init() con l'annotazione javax.annotation.PostConstruct e un contenitore EJB o Spring correttamente configurato eseguirà il metodo dopo che le iniezioni di dipendenza sono terminate, ma prima che l'oggetto possa essere utilizzato dall'applicazione.

Un metodo esempio:

@PostConstruct 
public void init() { 
    // logic.. 
} 

In un'applicazione enterprise è possibile aprire le risorse per ad esempio il sistema di file nel metodo init(). Questa inizializzazione può generare eccezioni e non dovrebbe essere chiamata da un costruttore.

Answer 4

Oppure utilizzare la primavera ... si può fare <beans default-init-method="init">, vedere Default initialization and destroy methods.

Answer 5

Se siete avversi ad usare le fabbriche, per qualche motivo, è possibile utilizzare il seguente trucco:

trait RunInit { 
    def init():Unit 
    init() 
} 

class Derived1 extends Base with RunInit { 
    def init() = println("INIT'ing!") 
} 

Questo farà eseguire init() prima che il costruttore Derived1/corpo.

Answer 6

se Java ce l'avesse, non vedremmo tutte le chiamate di metodo init() in the wild.

"costruttore figlio surround con qualcosa" - che non può essere eseguito in puro java. Peccato, perché ci possono essere applicazioni molto interessanti, specialmente con il blocco di inizializzazione dell'istanza di classe anonima +.

fabbrica e contenitore: possono essere utili quando il codice nativo new non esegue il lavoro; ma è banale e noioso e non funzionerà con le classi anonime.