Implementazione dell'interfaccia: un parametro che non mi serve

pseudo-codice

interface IPagingInfo
{
    int CurrentPageNo { get; }
    int RowsPerPage { get; }
    ...
}

interface ResultsRetriver
{
    ResultRows GetResults(IPagingInfo pagingInfo);
}


class ANewResultsRetriver : ResultsRetriver
{
    ResultRows GetResults(IPagingInfo pagingInfo)
    {
        // TODO: Retrieve and return all results, ignore pagingInfo.
    }
}

Spiegazione

interface ResultsRetriver esiste da quando conosciamo il tempo. Esistono molte implementazioni di ResultsRetriver che funzionano felicemente nel sistema. Il nuovo programmatore arriva e ha il compito di scrivere ANewResultsRetriver . Tuttavia, il suo retriever dei risultati è diverso in quanto non ha un concetto di paging, deve sempre restituire tutti i risultati.

Il programmatore ritiene che la persona che ha scritto interface ResultsRetriver avrebbe dovuto fornire una versione della chiamata senza il parametro di paging per casi come questo, in cui il parametro non è richiesto. Ora vuole aggiungerlo, un GetResults() .

Un collega suggerisce che va bene non usare il parametro pagingInfo in questo caso speciale, ma cosa succede se il chiamante invia un pagingInfo valido aspettandosi che i risultati siano conformi al pagingInfo fornito? Quindi ignorare la richiesta dei chiamanti potrebbe non essere prudente. Quindi il collega suggerisce anche di lanciare un PagingNotSupportedException() per avvisare il chiamante se viene fornito un pagingInfo valido.

Suggerimenti:

1. Aggiungi un nuovo metodo GetResults a ResultsRetriver che non richiede alcun parametro. Riescializza tutto il codice nell'interfaccia per chiamare la versione corretta in base alla validità di pagingInfo.
2. Ignora il parametro pagingInfo.
3. Ignora il parametro pagingInfo ma lancia un PagingNotSupportedException() se viene fornito un parametro pagingInfo valido per avvisare il chiamante del fatto che il parametro verrà ignorato e potrebbe essere necessario aggirare questo problema.
4. Supponi che ciò che il programmatore sta scrivendo non sia in realtà un ResultsRetriver dato che ResultsRetriver deve supportare il paging con la sua definizione originale. Quindi una nuova interfaccia deve essere definita NonPagedResultsRetriver con un metodo GetResults() senza parametri. Il refactoring per includere questa interfaccia con il codice circostante che attualmente funziona con ResultsRetriver per funzionare anche con NonPagedResultsRetriver
5. Qualcos'altro?

Domanda

Qual è la soluzione ottimale e perché?

Vedi anche

Design minimale rispetto all'uso previsto