-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split up the driver interface #224
Comments
@henrikbjorn may I ask for your feedback on this one? |
Separate driver responsibilities:
These are all separate responsibilities and not all of the drivers support all of them. A default noop implementation might make sense and might be required in many cases, but instead of relying on meaningless empty values, we could rely on the driver's nature (namely implements and interface of not). |
@henrikbjorn WDYT? |
Not sure this is worth pursuing, currently the drivers are "internal" only, meaning the end user should not work with them directly. |
but if it will clean up some code paths i am for it. |
Well, after rethinking there is only one remaining thing that bugs me: it seems to be wrong to return an empty array in peek when the driver does not support peeking. No-op code (like createQueue when manual creation is not necessary) is not that big problem after all. |
In my opinion, there is too much responsibility in the Driver interface. For example not all queues allow to give information about itself (which can't be abstracted anyway), not all of them allow to create new or remove queues, etc. Therefore I think we should split up the Driver interface into several smaller one:
This of course comes with complications in the implementation, however I think it would be better to put knowsledge (what a driver capable of) into abstraction instead of returning empty/default values. If a driver is not capable of something, why would you try to do that thing?
Looking forward to hear your feedback.
The text was updated successfully, but these errors were encountered: