Supponiamo di avere questo codice in una classe:
private DataContext _context;
public Customer[] GetCustomers()
{
GetContext();
return _context.Customers.ToArray();
}
public Order[] GetOrders()
{
GetContext();
return _context.Customers.ToArray();
}
// For the sake of this example, a new DataContext is *required*
// for every public method call
private void GetContext()
{
if (_context != null)
{
_context.Dispose();
}
_context = new DataContext();
}
Questo codice non è thread-safe - se due chiamate a GetOrders
/ GetCustomers
sono fatte contemporaneamente da thread diversi, possono finire usando lo stesso contesto, o il contesto potrebbe essere eliminato mentre è Usato. Anche se questo bug non esisteva, tuttavia, continua a "odorare" come un cattivo codice.
Un design molto migliore sarebbe per GetContext
per restituire sempre una nuova istanza di DataContext
e per sbarazzarsi del campo privato e per disporre dell'istanza una volta terminata. Passare da un campo privato inappropriato a una variabile locale sembra una soluzione migliore.
Ho esaminato gli elenchi degli odori del codice e non riesco a trovarne uno che lo descriva. In passato l'ho pensato come accoppiamento temporale , ma la descrizione di Wikipedia suggerisce che non è il termine:
Temporal coupling
When two actions are bundled together into one module just because they happen to occur at the same time.
Questa pagina discute l'accoppiamento temporale , ma l'esempio è l'API pubblica di una classe, mentre la mia domanda riguarda il design interno.
Questo odore ha un nome? O è semplicemente "codice bacato"?