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

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

Dove i dati sono una mela. Dove AppleAdapter è di classe servizio / business-intelligence. Dove AppleService è un riferimento Singleton ad 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 quello che stai facendo sia necessariamente sbagliato, ma se SomeDataAdapter rappresenta davvero un qualche tipo di servizio aziendale stateless, allora un singleton sarebbe la migliore pratica per questo. Spero che sia d'aiuto! L'esempio fornito è un modo ingegnoso per garantire l'assenza di contesa di _appleService nel caso in cui sia accaduto sia nullo sia accesso allo stesso tempo da due o più thread.

Sai cosa? Se SomeDataAdapter è un ADO IDbDataAdapter (che è quasi certamente), trascura questa intera risposta!

:

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, IDbCommand e il cablaggio di tutto dietro le quinte, quindi no non considererei un odore di codice perché ora stiamo parlando di flussi e altre cose che devono essere smaltiti quando abbiamo finito di usarli.

Penso che questo problema vada ancora più in profondità. Anche se lo si rifatta in un metodo statico, si ottiene il codice in cui si chiama il metodo statico singolo dappertutto. Quale a mio parere è l'odore di codice in sé. Potrebbe indicare che manchi qualche importante astrazione. Forse vuoi creare un codice che faccia un po 'di pre e post-elaborazione permettendoti di cambiare ciò che accade nel mezzo. Quel pre e post-processing conterrà le chiamate comuni mentre l'intermedio dipenderà da un'implementazione concreta.

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

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

Se lo stato di possesso rende una determinata classe più funzionale, funzionale ... riutilizzabile, allora no. Per qualche motivo, mi viene in mente il schema di progettazione del comando ; quella ragione non è certo il desiderio di annegare Robert Harvey.

Definisci "frequentemente". In che modo spesso istanziate l'oggetto? Molto - probabilmente no?

Ci sono probabilmente problemi più grandi di cui preoccuparsi nel tuo sistema. L'andare statico comunicherà più chiaramente al programmatore che lo stato interno dell'oggetto non sta cambiando, ottimo.

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

Sì è un odore di codice, solo piccolo.

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

L'odore qui è che questo è un codice procedurale avvolto (minimamente) negli oggetti.

Ci deve essere un motivo perché si vuole eseguire quell'operazione sulla tabella dati, ma piuttosto che modellare quell'operazione con altre operazioni correlate che condividono alcune semantiche (cioè hanno un significato comune), la l'autore ha appena attivato una nuova procedura all'interno di una nuova classe & lo chiamò.

In un linguaggio funzionale, è così che faresti le cose;) ma nel paradigma OO, vorresti modellare qualche astrazione che includesse quell'operazione. Quindi useresti le tecniche OO per arricchire quel modello e fornire una serie di operazioni correlate che mantengono una certa 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.

Attenzione a BTW ogni volta che viene visualizzato il programma che viene modellato invece dello spazio problema . È 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 solitamente legate a un modello di dominio anemico . Significa che qualcuno sta semplicemente raggruppando il codice per comodità, invece di modellare realmente i concetti che vogliono implementare.