Domanda

A quel punto dovrebbe Yagni Prestare la precedenza contro le buone pratiche di codifica e viceversa? Sto lavorando a un progetto al lavoro e voglio introdurre lentamente buoni standard di codice ai miei colleghi (attualmente non ce ne sono e tutto è solo un po 'hackerato insieme senza rima o ragione), ma dopo aver creato una serie di classi (noi Non fare TDD, o purtroppo nessun tipo di test unitari) ho fatto un passo indietro e ho pensato che stesse violando Yagni perché praticamente so con certezza che non abbiamo bisogno della necessità di estendere alcune di queste classi.

Ecco un esempio concreto di ciò che intendo: ho un livello di accesso ai dati che avvolge una serie di procedure memorizzate, che utilizza un modello rudimentale in stile repository con funzioni di crud di base. Dato che ci sono una manciata di metodi di cui hanno bisogno tutte le mie classi di repository, ho creato un'interfaccia generica per i miei repository, chiamati IRepository. Tuttavia, ho quindi creato un'interfaccia "marcatore" (interfaccia IE che non aggiunge alcuna nuova funzionalità) per ogni tipo di repository (EG ICustomerRepository) e la classe concreta lo implementa. Ho fatto la stessa cosa con un'implementazione di fabbrica per costruire gli oggetti aziendali da DataReader/set di dati restituiti dalla procedura memorizzata; La firma della mia classe di repository tende a assomigliare a questa:

public class CustomerRepository : ICustomerRepository
{
    ICustomerFactory factory = null;

    public CustomerRepository() : this(new CustomerFactory() { }

    public CustomerRepository(ICustomerFactory factory) {
        this.factory = factory;
    }      

    public Customer Find(int customerID)
    {
        // data access stuff here
        return factory.Build(ds.Tables[0].Rows[0]);
    }
}

La mia preoccupazione qui è che sto violando Yagni perché so con il 99% di certezza che non ci sarà mai un motivo per dare qualcosa di diverso da un concreto CustomerFactory a questo repository; Dal momento che non abbiamo test unitari non ho bisogno di un MockCustomerFactory O cose simili e avere così tante interfacce potrebbe confondere i miei collaboratori. D'altra parte, l'uso di un'implementazione concreta della fabbrica sembra un odore di design.

C'è un buon modo per arrivare a un compromesso tra la progettazione del software adeguata e non superando la soluzione? Mi chiedo se ho bisogno di avere tutte le "singole interfacce di implementazione" o se potrei sacrificare un po 'di buon design e ho, ad esempio, l'interfaccia di base e quindi il singolo calcestruzzo e non preoccuparti della programmazione per interfaccia se l'implementazione è che verrà mai utilizzata.

Nessuna soluzione corretta

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top