Move Interfaces in Separate Package

[devinlyons]

Is your feature request related to a problem? Please describe.

It's nice that you hide everything behind interfaces like IConnection and others. However, including them in the main package ties them to their implementation. When the client library is used, you have to reference the interfaces and their implementation in order to write code against the interfaces.

Describe the solution you'd like

Follow a pattern similar to Microsoft. Release a RabbitMQ.Client.Abstractions package with the interfaces. Then release a RabbitMQ.Client package that is dependant on the RabbitMQ.Client.Abstractions package.

Describe alternatives you've considered

No response

Additional context

This would be the perfect time to do this as you prop for the 7.0 release of your library.

[lukebakken]

To be honest, for the version 8 release of this library we might remove all public interfaces from the API. Why? Because you should not be mocking things like IConnection - if you really need to test it, you should do an integration test against a running instance of RabbitMQ.

I can be convinced otherwise, of course. Moving them to a separate library, probably not.

I'll leave this discussion open because I'm sure there will be a lot of feedback.

[devinlyons]

I agree with the IConnection and IModal stuff. But interfaces like IBasicConsumer could benefit from a different package structure. It can be wrapped, of course, but an abstractions lib would help to reduce this kind of thing. Stripping out all the public interfaces would be good too. Having interfaces packaged with their implementations is just a difficult thing to deal with.

[michaelklishin]

The absolute majority of libraries, .NET and not, ship interfaces together with their implementations.

[devinlyons]

Splitting the libraries allows consumers to code against the interfaces without having to depend on the implementation. Keeping the libraries together provides only a minor simplification of the project structure. Either way is fine. I just wanted to have the discussion.

[michaelklishin]

Following a pattern of Microsoft is great when you have a comparable amount of resources to Microsoft, which most teams do not.

This is the first time I remember seeing a request like this in my close to 14 years in this community.

I'd say we should hold off on any changes before 7.0 is done, and even then, wait for more interest and comments.

[lukebakken]

I'd say we should hold off on any changes before 7.0 is done

Yes, anything along these lines would be a version 8 feature / change.