通过回调参数类型紧密耦合的依赖关系

Question

My example uses PHP, but the concept should apply to OOP in general.

I'm using the Dependency Injection pattern to decouple my classes and allow easy mocking and testing. For this concrete example, my example class ApiConsumer performs HTTP requests against an API using an HTTP client, which is injected in the constructor through an interface:

class ApiConsumer {
    private $client;

    public function __construct(HttpClientInterface $client) {
        $this->client = $client;
    }
}

interface HttpClientInterface {
    public function async(string $method, string $uri, array $options, callable $success, callable $failure): void;
}

Now my issue is with those callbacks and parameter type hinting (in other languages, this would be an issue of type declaration).

One possible implementation of the interface is my class Guzzle , which wraps the GuzzleHttp library, a popular HTTP client lib for PHP. This class looks like this:

class Guzzle implements HttpClientInterface {
    private $client;
    private $promises;

    public function __construct() {
        $this->client = new GuzzleHttp\Client;
    }

    public function async(string $method, string $uri, array $options, callable $success, callable $failure): void {
        $this->promises[] = function () use ($method, $uri, $options, $success, $failure) {
            return $this->client->requestAsync($method, $uri, $options)->then($success, $failure);
        };
    }
}

So it essentially parks the request in the $promises array until at some point, another method is called that actually runs those requests, executing either the success or failure callback depending on the request's result.

This leads to a problem when I'm writing those callback functions. In order to properly type hint the things that will actually end up getting passed to those callbacks, I need to directly reference the types used by the GuzzleHttp library. For example, say I'm making an API request inside my ApiConsumer class like this:

    public function consumeSomeEndpoint(): void {
         $this->client->async(
             'GET', 
             'https://some.api.com/endpoint/', 
             [],
             function (Psr\Http\Message\ResponseInterface $response) {
                 var_dump($response);
             },
             function (GuzzleHttp\Exception\BadResponseException $reason) {
                 echo $reason->getResponse()->getBody();
                 throw new RuntimeException($reason->getMessage());
             },
         );
    }

The ResponseInterface is fine, that's general enough that it can be used in many places (the entire Psr package is essentially just providing HTTP related interfaces). The BadResponseException , however, is specific to GuzzleHttp. If I want to create an alternate implementation of an HttpClientInterface , I have to actually import the GuzzleHttp lib just so I can understand those exceptions. I can't introduce an interface here because obviously the lib's Exceptions don't implement it. The interface implemented by BadResponseException , Psr\\Http\\Message\\RequestInterface\\RequestExceptionInterface , doesn't provide the getResponse() method used to access the response payload, which contains potential information from the API about the reason for the failure.

Is there any way around this?

Answer 1

Yes, the way around this is to depend in an exception that is not tightly bound to the library, and that other replacements can either throw or implement.

Luckily, that's the case for Guzzle.

GuzzleHttp\\Exception\\BadResponseException extends GuzzleHttp\\Exception\\RequestException , which in turns implements Psr\\Http\\Message\\RequestInterface\\RequestExceptionInterface ;

As seen, here and here :

/**
 * Exception when an HTTP error occurs (4xx or 5xx error)
 */
class BadResponseException extends RequestException
{ /** class omitted **}

/**
 * HTTP Request exception
 */
class RequestException extends TransferException implements RequestExceptionInterface
{ /** class omitted **}

To type-hint properly the ecallback, you probably have to specify Psr\\Http\\Client\\ClientExceptionInterface , since that's the most generic one in the PSR contract, and conforming implementations might throw any of the extended exceptions: NetworkExceptionInterface or RequestExceptionInterface , mentioned earlier.