Esiste una metodologia per commutare il codebase di grandi dimensioni in modo che possa essere interfacciato invece dell'accesso diretto alla classe?

Question

Esiste una metodologia per commutare il codebase di grandi dimensioni in modo che possa essere interfacciato invece dell'accesso diretto alla classe?

#1 da (6 voti)
#2 da (5 voti)

4

La nostra base di codici di organizzazione viene utilizzata da vari team. Nel corso degli anni, il codice si è evoluto e si è sviluppato senza utilizzare molte interfacce. Vorremmo cambiarlo, per ridurre la possibilità di rompere i cambiamenti.

vale a dire. cambia l'accesso ai componenti comuni da

Foo foo = new Foo();

a

Ifoo foo = SomeFactory.GetFoo();

La mia domanda è: esiste un modello di design \ refactoring pattern \ methodology per introdurre interfacce al codice legacy esistente?

Vale la pena ricordare che non abbiamo una "lista" delle classi più importanti che vogliamo proteggere convertendo il loro utilizzo in interfaccia. Esiste un modo consigliato per ottenere tale elenco?

interfaces object-oriented-design legacy-code

posta Ayal 07.03.2017 - 08:15

fonte

2 risposte

6

La migliore metodologia per farlo è YAGNI , o in altre parole, non farlo prima o "nel caso in cui".

Fatelo ovunque tu abbia davvero bisogno di cambiare qualcosa nel sistema che aggiunge valore di business effettivo. Quando ti trovi in una situazione in cui

sei

desideri aggiungere o migliorare una funzione
vuoi correggere un bug
desideri ottimizzare qualcosa

sai che devi cambiare qualcosa da qualche parte nel tuo programma. E quando si nota che l'introduzione di un'interfaccia ha senso in quel contesto (forse a causa di test dell'unità più semplici, forse a causa del riutilizzo, forse a causa della riduzione del codice duplicato), allora è il momento giusto per iniziare con un'interfaccia.

risposta data 07.03.2017 - 08:36

fonte

Leggi altre domande sui tag interfaces object-oriented-design legacy-code

Chi sono gli esperti del dominio? Come descrivo il pattern del repository?

score 5 · Accepted Answer

Per ogni classe che desideri nascondere dietro un'interfaccia, fai quanto segue:

Utilizza lo strumento di refactoring del tuo IDE preferito per modificare il nome della classe da Foo a IFoo . L'intera base di codice dovrebbe ora funzionare come prima.
Rinomina la classe in Foo ma senza utilizzare il refactoring. Il tuo codice ora dovrebbe essere pieno di errori che indicano che IFoo è sconosciuto.
Crea una nuova interfaccia IFoo e chiedi alla classe di implementarla. Molti errori dovrebbero ora scomparire. Ma avrai comunque un errore in ogni riga che dice new IFoo , affermando che IFoo è un'interfaccia e quindi non può essere istanziata.
Implementa il tuo modello creativo preferito (costruttore, fabbrica, metodo factory statico, qualunque cosa) e usalo per correggere tutti questi errori di new IFoo .
Esegui la tua prova.

Tuttavia, ti preghiamo di prendere in considerazione anche la risposta di Doc Brown . Un'interfaccia ha senso solo se hai almeno due classi che la implementano. Fino a quando non lo fai, quell'interfaccia è un codice boilerplate non necessario che non fa altro che aggiungere più complessità. Tuttavia, una lezione di derisione nel tuo seme di prova conta.