2

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)

enter image description here

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?

5
  • Do you want to know which algorithm has the best forecast result? Apr 12, 2017 at 18:36
  • Do you want to execute always all? Or should the caller decide which API should be called? What are the parameters and return values for the methods? Apr 12, 2017 at 18:54
  • Are you asking what the pattern you've described is called? It's worth pointing out that not every possible software design has a name. If your design fits, then you should use it, and not worry too much about giving it a name, or about following design patterns from books/websites Apr 12, 2017 at 19:19
  • I am asking two questions : the most important one is what is the best pattern to do this, and the second one is what is the name (if it has) of the pattern that I described?. Apr 12, 2017 at 19:30
  • This diagram makes no sense to me. Why repeat the same abstraction 4 times? The Parent API has the common part in it already. Apr 13, 2017 at 22:52

4 Answers 4

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


}
1
  • Is this not the Composite Design pattern? It aggregates several implementations into one and provides a single implementation for the consumer to be able to interact with any of the three implementations? Dec 23, 2022 at 20:53
1

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"

0

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

3
  • Any chance you would explain why this is good instead of just including a link?
    – JeffO
    Apr 12, 2017 at 20:43
  • if you check the link in my answer which leads to tutorialspoint, you can see the similarities between drawings. all he needs is a factory to produce new apis for expansion Apr 13, 2017 at 6:26
  • Ah, okay, got it, the drawings are similar -1. Apr 14, 2017 at 21:37
0

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.

enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.