PSR-17: HttpFactoryInterface maybe?

[Daniyal Hamid]

Hi,

I was wondering if it would be a good idea to create an HttpFactoryInterface class that basically is an amalgamation of all PSR-17 interfaces, something like:

interface HttpFactoryInterface extends
    RequestFactoryInterface,
    ResponseFactoryInterface,
    ServerRequestFactoryInterface,
    StreamFactoryInterface,
    UploadedFileFactoryInterface,
    UriFactoryInterface
{
}

Guzzle and Nyholm already have HttpFactories as such so maybe it's a good idea to add such an interface?

[Anton Fedonjuk]

Good solution.

вторник, 12 ноября 2019 г., 1:32:23 UTC+3 пользователь Daniyal Hamid написал:

[Daniyal Hamid]

@Alexander Makarow asked: "What would be the benefit having it? "

So, the problem this would solve is; imagine a use case, for example with a static http factory that tries to auto-detect an http factory implementation (such as Nyholms' or Guzzles'). Having an HttpFactoryInterface would serve the following benefit in such a use-case:

1. If the developer wanted to add his own factory, the HttpFactoryInterface would allow type hinting;

2. We could ensure an HttpMessageFactory implementation always has all the required factory methods to create http message related classes;

3. Implementations (such as Nyholms' or Guzzles') could easily be swappable;

4. It promotes ease of use for creating http messages.

PS: @alexander Sorry, I ended up creating a duplicate post, the one you replied to I deleted, so I'm posting the reply here.

[Alexander Makarow]

What do you mean by autodetect?

There are interfaces for factories already. You can type hint as necessary, you can replace implementation. It already promotes creating message via individual interfaces such as ResponseFactoryInterface. It's not a good idea to inject general HttpFactoryInterface and then use only one part of its methods. It violates single responsibility principle.

вт, 12 нояб. 2019 г., 01:14 Daniyal Hamid <daniya...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f4f25988-528d-4b81-be83-d74d8898b3e6%40googlegroups.com.

[Alessandro Lai]

It also more importantly violates another SOLID principle, the I (interface segregation): having separate interfaces doesn't stop the implementers from having a single service that implements them all. So forcing that merge through a PSR interface is uncalled an not needed at all.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.