Design pattern per le API multiple che svolgono la stessa funzione

Non sono sicuro del nome del pattern, ma uno scenario possibile è che avrai bisogno di più interfacce per supportare ciò che è stato mostrato. Ogni API sceglierà quali interfacce implementare. Il gestore implementa tutte le interfacce e gestirà automaticamente se l'attuale previsione può eseguire o meno l'operazione desiderata.

Quindi aggiungere più API dovrebbe essere semplice in quanto ogni API può scegliere e scegliere quali interfacce supportare. Tutte le operazioni sono gestite nel gestore.

Interfacce

 public interface IForcastable
 {
     void Forecast();
 }

 public interface IHistoricalForcastable 
 {
     void ForecastHistory();
 }

 public interface IPreviousDayForcastable 
 {
     void ForecastYesterday();
 }

API

public class Api1 : IForcastable, IPreviousDayForcastable
{
    public void Forecast()
    {
        //Implement Here
    }

    public void ForecastYesterday()
    {
        //Implement Here
    }
}

public class Api2 : IForcastable, IHistoricalForcastable
{
    public void Forecast()
    {
        //Implement Here
    }

    public void ForecastHistory()
    {
        //Implement Here
    }
}

Finalmente il Manager implementerà tutto e gestirà indipendentemente dal fatto che l'attuale gestore della previsione possa eseguire l'operazione.

API gestore

public class ForecastApiManager: IForcastable, IHistoricalForcastable, IPreviousDayForcastable
{
    private readonly IForcastable _forcaster;

    public ForecastApiManager(IForcastable forcaster)
    {
        _forcaster = forcaster;
    }


    public void ForecastHistory()
    {
        var historicalForcaster = _forcaster as IHistoricalForcastable;

        if (historicalForcaster != null)
        {
            historicalForcaster.ForecastHistory();
        }
    }

    public void ForecastYesterday()
    {
        var yesterdayForecaster = _forcaster as IPreviousDayForcastable;

        if (yesterdayForecaster != null)
        {
            yesterdayForecaster.ForecastYesterday();
        }
    }

    public void Forecast()
    {
        _forcaster.Forecast();
    }


}

Determinare il modello giusto richiede di conoscere l'intento. La struttura da sola non è sempre sufficiente (ad es. Proxy, adattatore e bridge hanno una struttura simile, ma differiscono nell'intento che cercano di ottenere).

Inoltre, sul diagramma, non è chiaro se la freccia da manager api a parent api sia solo un'associazione navigabile, o se la usi come nella banda di quattro (cioè come dipendenza da istanze):

• Nel primo caso, sarebbe solo un polimorfismo semplice, l'API principale che definisce l'interfaccia per gli elementi in un contenitore e molti bambini che la implementano.
• Nel secondo caso, potrebbe essere una fabbrica o una fabbrica astratta, con il gestore che crea nuovi oggetti API specifici, che potrebbero essere uno dei tre possibili tipi.

Tuttavia, a seconda delle tue intenzioni, potrebbe anche essere un schema del ponte : in questo caso il manager offre un'astrazione al mondo esterno, ma potrebbero coesistere diverse implementazioni di tale astrazione. Tutti i contatti tra il mondo esterno e l'API verrebbero quindi convogliati attraverso il gestore. Questo potrebbe corrispondere meglio a ciò che chiami "un mix tra facciata e strategia"

IMHO, lo schema di fabbrica potrebbe essere una buona corrispondenza. Per i dettagli, consulta sito web Tutorialspoint .

Does this pattern have a name?

No, ciò che hai disegnato non è un modello. Mostrando un sacco di buona volontà posso vedere alcune influenze dai modelli.

È difficile dare qualche consiglio senza conoscere ulteriori dettagli. Ad ogni modo, per me sembra un po 'strano che tu stia utilizzando un'interfaccia per tutti gli algoritmi di previsione sebbene non supportino tutti i metodi.

Per evitare che tutte le classi concrete applichino sempre tutti i metodi, puoi utilizzare il modello di adattatore . Con il pattern dell'adattatore puoi decidere quale metodo vuoi implementare (sovrascrivendo il metodo) nella tua concreta classe dell'algoritmo di previsione.

Questoèutilequandoestendilatuainterfaccia,ades.aggiungendounnuovometodo.Questonuovometodonondevepiùessereimplementatointutteleclassiconcrete-solonellaclasseadapterenelleclassichefornisconoun'implementazionedelmetodo.Unaltrovantaggioèchepuoigarantireunagestionecomunedeimetodinonsupportati.

Aproposito,utilizzandounaclasseAdapterpuoiancheimplementareunaltropatternutile,il modello di metodo Template . Sono abbastanza sicuro a prescindere dall'algoritmo che usi, hai alcune operazioni comuni per tutti gli algoritmi.

Se hai bisogno di più consigli per favore aggiungi alcuni dettagli.