Programmazione per l'uso futuro delle interfacce

Ho un collega seduto accanto a me che ha progettato un'interfaccia come questa:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

Il problema è che in questo momento non stiamo usando questo parametro "end" da nessuna parte nel nostro codice, è solo lì perché potremmo doverlo usare un po 'di tempo in futuro.

Stiamo cercando di convincerlo che è una cattiva idea inserire parametri in interfacce che non servono al momento, ma continua a insistere sul fatto che molto lavoro dovrà essere fatto se implementiamo l'uso della data "fine" un po 'di tempo più tardi e poi adattare tutto il codice.

Ora, la mia domanda è: ci sono fonti che stanno trattando un argomento come questo dei guru del codice "rispettati" a cui possiamo collegarlo?

Invitalo a conoscere YAGNI . La parte logica della pagina di Wikipedia può essere particolarmente interessante qui:

Secondo coloro che sostengono l'approccio YAGNI, la tentazione di scrivere codice che al momento non è necessario, ma che potrebbe essere in futuro, presenta i seguenti svantaggi:

• Il tempo impiegato viene impiegato per aggiungere, testare o migliorare la funzionalità necessaria.
• Le nuove funzionalità devono essere sottoposte a debug, documentate e supportate.
• Qualsiasi nuova funzione impone vincoli su ciò che può essere fatto in futuro, quindi una funzione non necessaria può impedire l'aggiunta di funzioni necessarie in futuro.
• Fino a quando la funzionalità non è effettivamente necessaria, è difficile definire completamente cosa dovrebbe fare e testarla. Se la nuova funzionalità non è definita e testata correttamente, potrebbe non funzionare correttamente, anche se alla fine è necessaria.
• Porta a codice gonfio; il software diventa più grande e più complicato.
• A meno che non ci siano specifiche e un qualche tipo di controllo di revisione, la funzione potrebbe non essere nota ai programmatori che potrebbero farne uso.
• L'aggiunta della nuova funzionalità può suggerire altre nuove funzionalità. Se anche queste nuove funzionalità sono implementate, ciò potrebbe comportare un effetto valanga verso lo scorrimento delle funzionalità.

Altri possibili argomenti:

• "L'80% del costo della vita di un software è destinato alla manutenzione" . Scrivere il codice giusto in tempo riduce il costo della manutenzione: bisogna mantenere meno codice e concentrarsi sul codice effettivamente necessario.

• Il codice sorgente viene scritto una volta, ma letto decine di volte. Un ulteriore argomento, non usato da nessuna parte, porterebbe a perdere tempo a capire perché esiste un argomento che non è necessario. Dato che questa è un'interfaccia con diverse possibili implementazioni rende le cose solo più difficili.

• Il codice sorgente dovrebbe essere auto-documentato. La firma effettiva è fuorviante, dal momento che un lettore potrebbe pensare che endinfluisca sul risultato o sull'esecuzione del metodo.

• Le persone che scrivono implementazioni concrete di questa interfaccia potrebbero non capire che l'ultimo argomento non dovrebbe essere usato, il che porterebbe a approcci diversi:

  1. Non ho bisogno end, quindi ignorerò semplicemente il suo valore,

  2. Non ho bisogno end, quindi lancerò un'eccezione se non lo è null,

  3. Non ho bisogno end, ma proverò ad usarlo in qualche modo,

  4. Scriverò un sacco di codice che potrebbe essere usato in seguito quando endsarà necessario.

Ma tieni presente che il tuo collega potrebbe avere ragione.

Tutti i punti precedenti si basano sul fatto che il refactoring è facile, quindi aggiungere un argomento in seguito non richiederà molto sforzo. Ma questa è un'interfaccia e, come interfaccia, può essere utilizzata da diversi team che contribuiscono ad altre parti del prodotto. Ciò significa che cambiare un'interfaccia potrebbe essere particolarmente doloroso, nel qual caso YAGNI in realtà non si applica qui.

La risposta di hjk offre una buona soluzione: aggiungere un metodo a un'interfaccia già utilizzata non è particolarmente difficile, ma in alcuni casi ha anche un costo sostanziale:

• Alcuni framework non supportano i sovraccarichi. Ad esempio e se ricordo bene (correggimi se sbaglio), WCF .NET non supporta i sovraccarichi.

• Se l'interfaccia ha molte implementazioni concrete, aggiungere un metodo all'interfaccia richiederebbe di esaminare tutte le implementazioni e aggiungere anche il metodo lì.

ma continua a insistere che molto lavoro dovrà essere fatto se implementiamo l'uso della data di "fine" qualche tempo dopo e dovremo adattare tutto il codice allora.

(qualche tempo dopo)

public class EventGetter implements IEventGetter {

    private static final Date IMPLIED_END_DATE_ASOF_20140711 = new Date(Long.MAX_VALUE); // ???

    @Override
    public List<FooType> getFooList(String fooName, Date start) throws Exception {
        return getFooList(fooName, start, IMPLIED_END_DATE_ASOF_20140711);
    }

    @Override
    public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception {
        // Final implementation goes here
    }
}

Questo è tutto ciò di cui hai bisogno, sovraccarico di metodo. Il metodo aggiuntivo in futuro può essere introdotto in modo trasparente senza influire sulle chiamate al metodo esistente.

[Esistono] guru del codice "rispettati" a cui possiamo collegarlo [per convincerlo]?

Gli appelli all'autorità non sono particolarmente convincenti; meglio presentare un argomento valido indipendentemente da chi lo ha detto.

Ecco una reductio ad absurdum che dovrebbe convincere o dimostrare che il tuo collega è bloccato per essere "giusto", indipendentemente dalla sensibilità:

Ciò di cui hai veramente bisogno è

getFooList(String fooName, Date start, Date end, Date middle, 
           Date one_third, JulianDate start, JulianDate end,
           KlingonDate start, KlingonDate end)

Non si sa mai quando si dovrà internazionalizzare per Klingon, quindi è meglio occuparsene ora perché richiederà un sacco di lavoro per il retrofit e i Klingon non sono noti per la loro pazienza.

Dal punto di vista dell'ingegneria del software, credo che la soluzione corretta per questo tipo di problemi sia nel modello del costruttore. Questo è sicuramente un link degli autori di 'guru' per il tuo collega http://en.wikipedia.org/wiki/Builder_pattern .

Nel modello builder, l'utente crea un oggetto che contiene i parametri. Questo contenitore di parametri verrà quindi passato al metodo. Ciò si occuperà di eventuali estensioni e sovraccarichi dei parametri di cui il tuo collega avrebbe bisogno in futuro, rendendo il tutto molto stabile quando è necessario apportare modifiche.

Il tuo esempio diventerà:

public interface IEventGetter {
    public List<FooType> getFooList(ISearchFooRequest req) {
        throws Exception;
    ....
    }
}

public interface ISearchFooRequest {
        public String getName();
        public Date getStart();
        public Date getEnd();
        public int getOffset();
        ...
    }
}

public class SearchFooRequest implements ISearchFooRequest {

    public static SearchFooRequest buildDefaultRequest(String name, Date start) {
        ...
    }

    public String getName() {...}
    public Date getStart() {...}
    ...
    public void setEnd(Date end) {...}
    public void setOffset(int offset) {...}
    ...
}

Non ti serve ora, quindi non aggiungerlo. Se ne hai bisogno in seguito, estendi l'interfaccia:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start)
         throws Exception;
    ....

}

public interface IBoundedEventGetter extends IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

Nessun principio di progettazione è assoluto, quindi mentre per lo più concordo con le altre risposte, ho pensato di interpretare l'avvocato del diavolo e discutere alcune condizioni in base alle quali prenderei in considerazione l'accettazione della soluzione del tuo collega:

• Se si tratta di un'API pubblica e prevedi che la funzionalità sia utile per gli sviluppatori di terze parti, anche se non la usi internamente.
• Se ha notevoli benefici immediati, non solo quelli futuri. Se la data di fine implicita è Now(), l'aggiunta di un parametro rimuove un effetto collaterale, che presenta vantaggi per la memorizzazione nella cache e il test dell'unità. Forse consente un'implementazione più semplice. O forse è più coerente con altre API nel tuo codice.
• Se la tua cultura di sviluppo ha una storia problematica. Se i processi o la territorialità rendono troppo difficile cambiare qualcosa di centrale come un'interfaccia, allora quello che ho visto accadere prima è che le persone implementano soluzioni alternative sul lato client invece di cambiare l'interfaccia, quindi stai cercando di mantenere una dozzina di date di fine ad hoc filtri anziché uno. Se questo genere di cose accade molto nella tua azienda, ha senso dedicare un po 'più impegno alla correzione futura. Non fraintendetemi, è meglio cambiare i processi di sviluppo, ma di solito è più facile a dirsi che a farsi .

Detto questo, nella mia esperienza il più grande corollario di YAGNI è YDKWFYN: non sai di quale forma avrai bisogno (sì, ho appena inventato quell'acronimo). Anche se la necessità di alcuni parametri limite può essere relativamente prevedibile, potrebbe assumere la forma di un limite di pagina, o un numero di giorni, o un valore booleano che specifica di utilizzare la data di fine da una tabella delle preferenze dell'utente o qualsiasi numero di cose.

Dato che non hai ancora il requisito, non hai modo di sapere quale tipo dovrebbe essere quel parametro. Spesso finisci per avere un'interfaccia scomoda che non è abbastanza adatta alle tue esigenze, o devi comunque cambiarla.

Non ci sono abbastanza informazioni per rispondere a questa domanda. Dipende da cosa getFooListeffettivamente fa e da come lo fa.

Ecco un esempio evidente di un metodo che dovrebbe supportare un parametro aggiuntivo, usato o no.

void CapitalizeSubstring (String capitalize_me, int start_index);

L'implementazione di un metodo che opera su una raccolta in cui è possibile specificare l'inizio ma non la fine della raccolta è spesso sciocca.

Devi davvero guardare al problema stesso e chiederti se il parametro è privo di senso nel contesto dell'intera interfaccia e davvero quanto onere impone il parametro aggiuntivo.

Temo che il tuo collega possa in realtà avere un punto molto valido. Sebbene la sua soluzione non sia in realtà la migliore.

Dalla sua interfaccia proposta è chiaro che

public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception;

sta restituendo istanze trovate entro un intervallo di tempo. Se i client attualmente non utilizzano il parametro end, ciò non cambia il fatto che si aspettano istanze trovate entro un intervallo di tempo. Significa solo che attualmente tutti i client utilizzano intervalli aperti (dall'inizio alla eternità)

Quindi un'interfaccia migliore sarebbe:

public List<FooType> getFooList(String fooName, Interval interval) throws Exception;

Se si fornisce l'intervallo con un metodo di fabbrica statico:

public static Interval startingAt(Date start) { return new Interval(start, null); }

quindi i clienti non sentiranno nemmeno la necessità di specificare un orario di fine.

Allo stesso tempo, la tua interfaccia trasmette più correttamente ciò che fa, poiché getFooList(String, Date)non comunica che ciò si occupa di un intervallo.

Nota che il mio suggerimento deriva da ciò che il metodo attualmente fa, non da ciò che dovrebbe o potrebbe fare in futuro, e come tale il principio YAGNI (che è davvero molto valido) non si applica qui.

L'aggiunta di un parametro non utilizzato è confusa. Le persone potrebbero chiamare quel metodo supponendo che questa funzione funzioni.

Non lo aggiungerei. È banale aggiungerlo successivamente usando un refactoring e riparando meccanicamente i siti di chiamata. In una lingua tipicamente statica questo è facile da fare. Non è necessario aggiungerlo con entusiasmo.

Se c'è una ragione per avere quel parametro è possibile evitare la confusione: Aggiungi un'asserzione per l'attuazione di tale interfaccia per imporre che questo parametro sia passato come valore di default. Se qualcuno utilizza accidentalmente quel parametro almeno durante il test noterà immediatamente che questa funzione non è implementata. Questo elimina il rischio di far cadere un bug in produzione.