Use of SOLID principles for creating custom PHP Providers of Services Classes

Anybody can view this question? I cannot view in the discussions main panel but using My Questions menu item I view that and get the correct link, or if I answer my own question:

https://laracasts.com/discuss/channels/general-discussion/use-of-solid-principles-for-creating-custom-php-providers-of-services-classes

If I answer within the question I view in the main discussion panel, I tried clearing this second post and the question dissapears from the main discussions.

Maybe a cache issue?

Thanks.

@cloud4bpm I’d say just start coding and re-factor as you go. Watch the Laracast lessons on the SOLID principles, and then see if any of them can be applied to your code.

You don’t say why types of APIs you’re working with, so I can’t really offer any suggestions on code organisation or which methods should be abstract or whatnot.

Hi @martinbean , many thanks for your answer.

I'm working with Currency Converters and I create a general Provider and I'm getting knowledge about some interesting available APIs.

But not all are using the same public functionality, that is why I'm asking about that.

I have not access to view the SOLID Series because I'm currently not a subscriber, but I'm evaluating for that, although I'm using those SOLID Patterns as I commented here.

Thanks again.

https://www.youtube.com/watch?v=nuHfVn_cfHU

@luddinus ???

@cloud4bpm Then think about the operations you’d want to perform against a currency converter and place those methods in an interface. Thinking about it, a currency converter only has one use: convert an amount in one currency to another. So you could have a convert() method that accepts three parameters: amount, currencyFrom, and currencyTo. Then have your individual classes implement that method:

interface CurrencyConverter
{
    public function convert($amount, $from, $to);
}

namespace App\CurrencyConverter;

use App\Contracts\CurrencyConverter as CurrencyConverterContract;
use GuzzleHttp\Client as HttpClient;

class OpenExchangeRate implements CurrencyConverterContract
{
    public function __construct(HttpClient $http, $clientId)
    {
        $this->http = $http;
        $this->clientId = $clientId;
        $this->baseUrl = 'https://openexchangerates.org/api';
    }

    public function convert($amount, $from, $to)
    {
        $response = $this->http->get($this->baseUrl.'/convert/'.$amount.'/'.$from.'/'.$to);

        return $response->json();
    }
}

Note: This was written off the cuff and isn’t meant to be working code. But should be enough to get you started.

Many thanks @martinbean for your sample but, in example if you see the following API CurrencyLayer you can find some other methods:

live()
historical()
...

Thinking about that methods is why I was thinking about using Segregation Interface (eg. HistoryInterface.php with getHistoricalData() method) and implement by the specific ConversionProvider).

Thanks again.

@cloud4bpm Yes. Different APIs are going to have methods with different names and functionality. The idea of an interface is to allow your application code to access the functionality of these APIs through common method names without worrying about the underlying implementation.

So in your example, if one API offers historical data then you may define methods in an interface and apply that to the relevant wrapper classes. It’s perfectly acceptable to implement more than one interface. That way, you can tell what methods an API wrapper implements by checking what interfaces they implement:

if ($currencyConverter instanceof HistoryInterface) {
    // currency converter supports querying historical data
}

Many thanks @martinbean.

Very clear!