Come "convertire" un progetto di stile di accesso statico in stile IoC / DI?

Question

Come "convertire" un progetto di stile di accesso statico in stile IoC / DI?

#1 da (3 voti)

0

Esistono approcci migliori per il refactoring di un progetto di programmazione che è stato precedentemente scritto con il pattern anti-riferimento statico (la maggior parte delle classi si riferisce a un bean statico, dove tutte le sue variabili sono pubbliche.

A metà della classe, ad esempio vedrai qualcosa di simile:

EvilClass.Variable = returnsABoolean() .

Quindi in una classe diversa, vedrai qualcosa di simile:

if(EvilClass.Variable == foo){
    doSomething();
}else{
    doSomethingDifferent();
}

Fino a poco tempo fa, ho lavorato con questo modello perché non voglio mescolare gli stili e ottenere confusi tra gli stili. Ma voglio lentamente ma sicuramente "sistemare" questo progetto.

Sono l'unico dev su questo, e non ho il tempo di sedermi e refactarlo (altrimenti, spingerei per una completa riscrittura!).

Ci sono delle best practice da prendere in considerazione quando si lavora / si risolve questo tipo di progetto / problema?

dependency-injection inversion-of-control refactoring static-access

posta Pureferret 16.04.2013 - 10:50

fonte

1 risposta

Leggi altre domande sui tag dependency-injection inversion-of-control refactoring static-access

Che cos'è ServletUtilities? Migrazione dell'app Web da php a Java [chiuso]

score 3 · Answer 1

Probabilmente mi avvicinerei a questo con il seguente approccio multi-step:

Fase 1:

Se possibile, isola la classe statica.
- In C # sposterei la classe statica sul proprio assembly o su un assembly isolato e ne renderei tutti i membri pubblici in modo che solo una classe nello stesso assembly isolato possa utilizzarla.
Quindi, crea una classe non statica che espone la classe statica.
Inietti questa classe non statica in tutti gli altri bit di codice che richiedevano la classe statica.

Fase 2:

Rendi la classe non statica un singleton (solo temporaneamente) in modo da generare un'eccezione se istanziata più di una volta
Sposta tutto il codice statico nella classe non statica.
Elimina la classe statica

Fase 3:

Esegui l'intera serie di test con questa nuova configurazione (se sei abbastanza fortunato da averne)
- Oppure, crea un elenco di tutti i percorsi di codice che utilizzano la nuova classe non statica e prova a coprire tutti con la verifica manuale.
Se si verificano eccezioni Singleton, si crea un'istanza casuale della classe non statica più di una volta. Scopri perché e risolvilo
Se non riscontrate eccezioni, siete al sicuro.

Fase 4:

Rifatta qualsiasi codice che utilizza la tua nuova classe non statica in modo che rispetti il Principio di Responsabilità Unica. Ciò richiederà molto lavoro, ma dovrebbe aiutare a prevenire l'utilizzo accidentale dell'istanza errata della classe non statica.
Rimuovi il pattern Singleton dalla classe non statica
Continua a eseguire il refactoring finché tutte le dipendenze non vengono iniettate ovunque :) (detto più facile!)