Sostituisci metodo con metodo Oggetto v Principio di minima visibilità

Question

Sostituisci metodo con metodo Oggetto v Principio di minima visibilità

#1 da (4 voti)
#2 da (2 voti)

2

Sto leggendo il libro di rifattorizzazione di Martin Fowlers. A pagina 110 parla di "Sostituisci metodo con oggetto metodo" dove trasforma un metodo con variabili locali in una classe con variabili di istanza.

Il risultato è una classe chiamata: PriceCalculator con tre variabili di istanza, ad esempio primaryBasePrice, secondaryBasePrice e prezzo base teritario.

Recentemente ho fatto una domanda su variabili locali e variabili di istanza: Quando devono essere utilizzate variabili locali su variabili di istanza? . Sono d'accordo con la risposta di Samuels e la risposta di Timothy Truckles - Ho sempre usato il principio della visibilità minima nel mio lavoro.

Tuttavia, il refactoring di Fowlers sembra contraddirlo e mi confonde. Anche tutti i diagrammi delle classi nel mio libro UML sembrano contraddire il principio della visibilità minima, ovvero usano una classe con variabili di istanza indipendentemente dallo scenario come questo: link . Capisco che devi scendere a compromessi in questo gioco quando consideri le prestazioni, ecc. Il design "migliore" ha variabili di istanza piuttosto che variabili locali?

c# domain-driven-design

posta w0051977 22.06.2017 - 12:42

fonte

2 risposte

Leggi altre domande sui tag c# domain-driven-design

Dovremmo scrivere il diagramma uml per il nostro codice prima di iniziare la programmazione? [duplicare] Convalida degli argomenti in Costruttore

score 4 · Answer 1

Un refactoring non è necessariamente un miglioramento, è solo un cambiamento strutturale. Trasformare un metodo in un oggetto metodo è un refactoring, ma lo è anche l'opposto, trasformando un oggetto metodo in un metodo semplice.

I refactoring sono spesso passaggi eseguiti per rendere possibile l'introduzione di nuove funzionalità. Ad esempio, se è necessario introdurre la possibilità di annullare o riprodurre i metodi di selezione, un primo passaggio potrebbe essere quello di trasformare i metodi in oggetti metodo, poiché ciò consentirà di implementare il modello di comando come passaggio successivo.

Ma isolatamente, trasformare un metodo in un oggetto metodo non migliorerà il tuo codice.

score 2 · Answer 2

Per citare Timothy Truckels correttamente:

Turning local variables into instance variables (for no particular reason) violates the least visibility scope principle

Ma cos'è una "ragione particolare"? Penso che sarete d'accordo sul fatto che una ragione ragionevole è quando un metodo supera una certa complessità. Ed è quello che Fowlers "Sostituisci metodo per metodo Oggetto" per rifattorizzare è per, niente di meno, non di più. Contro @TSar, non trovo l'esempio di Fowler in "Sostituisci metodo con metodo Object" particolarmente cattivo. Dichiara chiaramente che è per "un metodo lungo che usa le variabili locali in modo tale che non puoi applicare il metodo Extract" - che è una chiara differenza per l'esempio di Calcolatrice in la tua precedente domanda . Nota anche che il catalogo di Fowler cerca di dare una descrizione completa per ciascuno dei refactoring, sicuramente non voleva riempire cinque pagine del suo libro con il codice di un vero programma per assicurarsi che qualcuno creda che il metodo che trasforma in una classe sia davvero un lungo, complesso.

Se si prende il "principio della visibilità minima" all'estremo solo perché si vuole seguirlo in modo settoriale, si ottengono metodi molto lunghi con centinaia di LOC e dozzine di variabili locali, solo per non introdurre l'istanza variabili. Oppure si ottengono cluster di metodi con dozzine di parametri, passando le variabili locali da un metodo a un altro, per lo stesso motivo. Questo sicuramente non è ciò che vuoi raggiungere.