Design pattern for multiples APIs that do the same function

Question

I retrieve some pieces of information from four forecasting APIs, I have three main methods that I will implement in each API's manager:

• history (only one of them provides this function)
• forecasting (all of them)
• yesterday data (only two)

I am thinking about the following pattern (it's similar to facada/strategy)

Questions:

1) Does this pattern have a name? 2) I want to manage those three methods from a particular class (PARENT API) and I want to find the easiest way to add a new API in the future. What is the pattern that fits better in this case?

Answer 1

I am not sure of the pattern name, but a possible scenario is that you will need multiple interfaces to support what has been shown. Each API will choose what interfaces to implement. The manager implements all interfaces and will automatically handle whether or not the current forecaster can perform the desired operation.

So adding more APIs should be straight forward as each API can pick and choose what interfaces to support. All operations are handled in the manager.

Interfaces

 public interface IForcastable
 {
     void Forecast();
 }

 public interface IHistoricalForcastable 
 {
     void ForecastHistory();
 }

 public interface IPreviousDayForcastable 
 {
     void ForecastYesterday();
 }

APIs

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
    }
}

Finally the Manager will implement everything and handle whether or not the current forecaster being managed can perform the operation.

Manager API

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();
    }


}

Answer 2

Determining the right pattern requires to know the intent. The structure alone is not always sufficient (e.g. Proxy, adapter and bridge have a similar structure, but differ in the intent they try to achieve).

Furthermore, on the diagram, It is not clear if the arrow from manager api to parent api is just a navigable association, or if you use it as in the gang of four (i.e. As an instantiation dependency):

• In the first case, it would only be simple polymorphism, the parent API defining the interface for elements in a container, and many children implementing it.
• In the second case, it could be a factory or an abstract factory, with the manager creating new specific api objects, which could be any of the three possible types.

However, depending on your intent, it could as well be a bridge pattern: in this case your manager offers an abstraction to the outside world, but different implementations of that abstraction could coexist. All the contacts between the outside world and the API would then be channelled through the manager. This could correspond best to what you call "a mix between facade and strategy"

Answer 3

IMHO, Factory pattern might be a good match. Check Tutorialspoint web site for details.

Answer 4

Does this pattern have a name?

No, what you have drawn is not a pattern. Showing a lot of good will I can see some influences from patterns.

It's hard to give you some advise without knowing more details. Anyway, for me it looks a bit awkward that you are using one interface for all forecast algorithms although they don't support all methods.

To avoid that all concrete classes has always implement all methods you can use the adapter pattern. With the adapter pattern you can decide which method you want to implement (by overriding the method) in your concrete forecast algorithm class.

This is useful when you extend your interface e.g. adding a new method. This new method doesn't have to be implemented in all concrete classes anymore - only in the adapter class and the classes which are providing a implementation of the method. Another benefit is you can ensure a common handling of unsupported methods.

By the way, by using an Adapter class you can also implement an other useful pattern, the Template method pattern. I am pretty sure regardless which algorithm you use, you have some common operations for all algorithms.

If you need more advise please add some details.