I metodi init () hanno un odore di codice?

C'è uno scopo per dichiarare un init()metodo per un tipo?

Non sto chiedendo se dovremmo preferire init()un costruttore o come evitare di dichiarareinit() .

Sto chiedendo se c'è qualche logica dietro la dichiarazione di un init()metodo (visto quanto sia comune) o se è un odore di codice e dovrebbe essere evitato.

Il init()linguaggio è abbastanza comune, ma devo ancora vedere alcun beneficio reale.

Sto parlando di tipi che incoraggiano l'inizializzazione tramite un metodo:

class Demo {
    public void init() {
        //...
    }
}

Quando sarà mai utile nel codice di produzione?

Sento che potrebbe essere un odore di codice poiché suggerisce che il costruttore non inizializza completamente l'oggetto, risultando in un oggetto parzialmente creato. L'oggetto non dovrebbe esistere se lo stato non è impostato.

Questo mi fa credere che potrebbe far parte di un qualche tipo di tecnica utilizzata per accelerare la produzione, nel senso delle applicazioni aziendali. È l'unica ragione logica che posso pensare di avere un tale idioma, non sono sicuro di come sarebbe utile in tal caso.

Sì, è un odore di codice. Un odore di codice non è qualcosa che deve necessariamente essere sempre rimosso. È qualcosa che ti fa dare una seconda occhiata.

Qui hai un oggetto in due stati fondamentalmente diversi: pre-init e post-init. Tali stati hanno responsabilità diverse, metodi diversi che possono essere chiamati e comportamento diverso. Sono effettivamente due diverse classi.

Se li trasformi fisicamente in due classi separate, rimuoverai staticamente un'intera classe di potenziali bug, a costo forse di far sì che il tuo modello non corrisponda al "modello del mondo reale" abbastanza da vicino. Di solito è il nome del primo Configo Setupo qualcosa del genere.

Quindi, la prossima volta, prova a refactoring i tuoi idiomi di costruzione-init in modelli di due classi e vedi come ti risulta.

Dipende.

Un initmetodo è un odore di codice quando non è necessario che l'inizializzazione dell'oggetto sia separata dal costruttore. A volte ci sono casi in cui ha senso separare questi passaggi.

Una rapida ricerca su Google mi ha dato questo esempio. Posso facilmente immaginare più casi in cui il codice eseguito durante l'allocazione degli oggetti (il costruttore) potrebbe essere meglio separato dall'inizializzazione stessa. Forse hai un sistema livellato e l'allocazione / costruzione avviene nel livello X, ma l'inizializzazione solo nel livello Y, perché solo Y può fornire i parametri necessari. Forse "init" è costoso e deve essere eseguito solo per un sottoinsieme degli oggetti allocati, e la determinazione di quel sottoinsieme può essere eseguita solo nel livello Y. Oppure si desidera sovrascrivere il metodo (virtuale) "init" in un derivato classe che non può essere eseguita con un costruttore. Forse il livello X ti fornisce oggetti allocati da un albero ereditario, ma il livello Y non è a conoscenza della derivazione concreta, ma solo dell'interfaccia comune (doveinit forse definito).

Naturalmente, per la mia esperienza, questi casi sono solo una piccola percentuale del caso standard in cui tutta l'inizializzazione può essere eseguita direttamente nel costruttore e ogni volta che vedi un initmetodo separato , potrebbe essere una buona idea mettere in discussione la sua necessità.

La mia esperienza si divide in due gruppi:

1. Codice in cui init () è effettivamente richiesto. Questo può accadere quando una superclasse o un framework impedisce al costruttore della tua classe di ottenere tutte le sue dipendenze durante la costruzione.
2. Codice in cui viene utilizzato init () ma che avrebbe potuto essere evitato.

Nella mia esperienza personale ho visto solo alcuni esempi di (1) ma molti più esempi di (2). Di conseguenza, di solito presumo che init () sia un odore di codice, ma non è sempre così. A volte non riesci proprio ad aggirarlo.

Ho scoperto che usare il Builder Pattern può spesso aiutare a rimuovere la necessità / il desiderio di avere un init ().

Uno scenario tipico in cui un metodo Init è utile è quando si dispone di un file di configurazione che si desidera modificare e di cui tenere conto della modifica senza riavviare l'applicazione. Questo, ovviamente, non significa che un metodo Init debba essere chiamato separatamente da un costruttore. È possibile chiamare un metodo Init da un costruttore, quindi richiamarlo in seguito quando / se i parametri di configurazione cambiano.

Per riassumere: come per la maggior parte dei dilemmi là fuori, che si tratti di un odore di codice o meno, dipende dalla situazione e dalle circostanze.

Dipende da come li usi.

Uso questo modello in linguaggi di immondizia raccolti come Java / C # quando non voglio continuare a riallocare un oggetto nell'heap (come quando sto realizzando un videogioco e ho bisogno di mantenere alte le prestazioni, i garbage collector ne uccidono). Uso il costruttore per fare altre allocazioni di heap di cui ha bisogno einit per creare lo stato utile di base prima di ogni volta che voglio riutilizzarlo. Ciò è legato al concetto di pool di oggetti.

È inoltre utile se si dispone di più costruttori che condividono un sottoinsieme comune di istruzioni di inizializzazione, ma in tal caso initsarà privato. In questo modo posso minimizzare ogni costruttore il più possibile, quindi ognuno contiene solo le sue istruzioni uniche e una sola chiamata ainit per fare il resto.

In generale, tuttavia, è un odore di codice.

init()i metodi possono avere un certo senso quando si hanno oggetti che richiedono risorse esterne (come, ad esempio, una connessione di rete) che vengono utilizzati contemporaneamente da altri oggetti. Potrebbe non essere necessario / necessario limitare la risorsa per la durata dell'oggetto. In tali situazioni, potresti non voler allocare la risorsa nel costruttore quando è probabile che l'allocazione delle risorse fallisca.

Soprattutto nella programmazione integrata, si desidera avere un footprint di memoria deterministico, quindi è pratica (buona?) Comune chiamare i costruttori in anticipo, forse anche statici, e inizializzare solo in seguito quando si verificano determinate condizioni.

A parte questi casi, penso che tutto dovrebbe andare in un costruttore.

In genere preferisco un costruttore che riceve tutti gli argomenti richiesti per un'istanza funzionale. Ciò chiarisce tutte le dipendenze di quell'oggetto.

D'altra parte, utilizzo un semplice framework di configurazione che richiede un costruttore pubblico senza parametri e interfacce per l'iniezione di dipendenze e valori di configurazione. Fatto ciò, il framework di configurazione chiama il initmetodo dell'oggetto: ora hai ricevuto tutte le cose che ho per te, fai gli ultimi passi per prepararti al lavoro. Ma nota: è il framework di configurazione che chiama automaticamente il metodo init, in modo da non dimenticare di chiamarlo.

Non c'è odore di codice se il metodo init () - è semanticamente incorporato nel ciclo di vita dello stato dell'oggetto.

Se devi chiamare init () per mettere l'oggetto in uno stato coerente è un odore di codice.

Esistono diversi motivi tecnici per cui esiste una struttura del genere:

1. gancio quadro
2. reimpostazione dell'oggetto allo stato iniziale (evitare la ridondanza)
3. possibilità di scavalcare durante i test

Il nome init a volte può essere opaco. Prendiamo una macchina e un motore. Per avviare l'auto (solo accendere, per ascoltare la radio) si desidera verificare che tutti i sistemi siano pronti per partire.

Quindi costruisci un motore, una porta, una ruota ecc. Lo schermo mostra engine = off.

Non è necessario avviare il monitoraggio del motore, ecc. Poiché sono tutti costosi. Quindi quando si gira la chiave per accendere si chiama engine-> start. Inizia a eseguire tutti i processi costosi.

Ora vedi engine = on. E inizia il processo di accensione.

L'auto non si accenderà senza il motore disponibile.

Puoi sostituire il motore con i tuoi calcoli complessi. Come una cella di Excel. Non tutte le celle devono essere sempre attive con tutti i gestori di eventi. Quando ti concentri su una cella, puoi avviarla. Aumentare le prestazioni in questo modo.