È un odore di codice se si crea frequentemente un oggetto solo per chiamare un metodo su di esso

Ho ereditato una base di codice in cui c'è molto codice che va in questo modo:

SomeDataAdapter sda = new SomeDataAdapter();
sda.UpdateData(DataTable updateData);

E poi sda non viene mai più utilizzato.

È un odore di codice che indica che quei metodi dovrebbero effettivamente essere metodi di classe statici?

Lo considererei un odore di architettura in quanto UpdateData probabilmente dovrebbe appartenere a una classe di "servizio".

Dove i dati sono una Apple. Dove AppleAdapter è un servizio / classe di business intelligence. Dove AppleService è un riferimento Singleton a un AppleAdapter che esiste al di fuori del metodo corrente.

private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
    get
    {
        if (_appleService == null)
        {
            lock (_appleServiceLock)
            {
                if (_appleService == null)
                    _appleService = new AppleAdapter();
            }
        }
        return _appleService;
    }
}

public SomeAppleRelatedMethod(Apple apple)
{
    AppleService.UpdateData(apple);
}

Non penso che ciò che stai facendo sia necessariamente sbagliato, ma se SomeDataAdapter rappresenta davvero un qualche tipo di servizio aziendale senza stato, allora un singleton sarebbe la migliore pratica per questo. Spero possa aiutare! L'esempio fornito è un modo fantasioso per garantire l'assenza di contese di _appleService se si verifica che entrambi sono nulli e vi si accede esattamente allo stesso tempo da due o più thread.

Sai cosa? Se SomeDataAdapter è un IDbDataAdapter ADO (che quasi sicuramente lo è), ignora l'intera risposta!

: P

Non ho il permesso di aggiungere un commento alla domanda originale, ma se potessi specificare dove esiste questo codice.

Se questo codice rappresenta un'implementazione personalizzata di un IDbDataAdapter e UpdateData sta creando un IDbConnection, un IDbCommand e lo sta cablando tutto dietro le quinte, allora no non prenderei in considerazione che un odore di codice perché ora stiamo parlando di stream e altro cose che devono essere eliminate quando abbiamo finito di usarle.

Penso che questo problema sia ancora più profondo di così. Anche se lo si converte in un metodo statico, si ottiene il codice in cui si chiama un singolo metodo statico ovunque. Che secondo me è l'odore del codice in sé. Potrebbe indicare che ti stai perdendo qualche astrazione importante. Forse vuoi creare un codice che eseguirà alcune operazioni di pre e post elaborazione e ti permetta di cambiare ciò che accade nel mezzo. Che pre e post-elaborazione conterranno gli inviti comuni mentre l'intervallo dipenderà da un'implementazione concreta.

Tipo. Di solito significa che vuoi passare una funzione in giro e la tua lingua preferita non ti permetterà. È un po 'goffo e inelegante, ma se sei bloccato in una lingua senza funzioni di prima classe, non c'è molto che puoi fare.

Se nessuno di questi oggetti viene passato come argomento ad altre funzioni, è possibile trasformarli in metodi statici e nulla cambierebbe.

Se il mantenimento dello stato rende una determinata classe più utile, funzionale ... riutilizzabile, allora no. Per qualche ragione viene in mente il modello di progettazione del comando ; quella ragione non è certo il desiderio di far annegare Robert Harvey.

Definisci "frequentemente". Con quale frequenza istanzia l'oggetto? Molto - probabilmente no?

Probabilmente ci sono problemi più grandi di cui preoccuparsi nel tuo sistema. Andare statico comunicherà più chiaramente al programmatore che lo stato interno dell'oggetto non sta cambiando - fantastico.

Se però lo stato è incasinato e devi iniziare a rendere statiche altre cose per rendere statica la prima cosa, allora devi chiedere quali parti devono essere statiche e quali no.

Sì , è un odore di codice, solo piccolo.

Rendilo un metodo statico e vai avanti. Non c'è niente di sbagliato nei metodi statici. Una volta che emerge un modello d'uso, puoi preoccuparti di astrarre il modello.

L'odore qui è che questo è un codice procedurale racchiuso (minimamente) in oggetti.

Ci deve essere un motivo per cui si desidera eseguire tale operazione sulla tabella dei dati, ma piuttosto che modellare quell'operazione con altre operazioni correlate che condividono una semantica (cioè hanno un significato comune), l'autore ha appena avviato una nuova procedura all'interno di una nuova classe e lo chiamò.

In un linguaggio funzionale, è così che faresti le cose;) ma nel paradigma OO, vorresti modellare qualche astrazione che includeva quell'operazione. Quindi useresti le tecniche OO per dare forma a quel modello e fornire una serie di operazioni correlate che preservano un po 'di semantica.

Quindi l'odore principale qui è che l'autore sta usando le classi, probabilmente perché il compilatore lo richiede, senza organizzare le operazioni in un modello concettuale.

A proposito, fai attenzione ogni volta che vedi il programma modellato invece dello spazio problematico . È un segno che il design potrebbe beneficiare di più pensiero. In altre parole, fai attenzione alle classi che sono tutte "xAdaptor" e "xHandler" e "xUtility", e di solito legate a un modello di dominio anemico . Significa che qualcuno sta semplicemente raggruppando il codice per comodità, invece di modellare effettivamente i concetti che vogliono implementare.