Skip to content
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

fix: EventSourceManager and ResourceController interface enhancements #618

Merged
merged 2 commits into from
Oct 26, 2021

Conversation

csviri
Copy link
Collaborator

@csviri csviri commented Oct 25, 2021

Improvements on event source registration related naming and structure. This might not be the final form, something to consider.

@@ -15,7 +16,7 @@
import io.javaoperatorsdk.operator.processing.event.internal.TimerEventSource;

public class DefaultEventSourceManager<R extends CustomResource<?, ?>>
implements EventSourceManager {
implements EventSourceManager<R>, Closeable {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why move Closeable to the implementation? Shouldn't all EventSourceManager implementations be Closeable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EventSourceManager is just the API that user should see from the init method. Should not be aware that it is actually closeable, it's an implementation detail in the background.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if we had several implementations of the interface, all of them should be closeable. So, to me, Closeable should be part of the contract of the EventSourceManager interface. Otherwise, if we push your logic to its conclusion, then we shouldn't even have a interface because we only have one implementation and that implementation needs to be closeable for the SDK to work properly. 😄
If we don't expect any other implementations, I don't think we need to worry about having an interface just for the sake of hiding some things away. Worse, having an interface implies that we potentially expect several implementations, which isn't really the case. It makes things more complex without much benefit.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense, it's basically interface segregation principle:
https://en.wikipedia.org/wiki/Interface_segregation_principle
The intended users should not see the other methods if we don't intend it for them.
They should not care if there is an other implementation or not, this is what we provide, it should be used.

The benefit is clear user facing interface. But without to much added complexity (close to 0).

Copy link
Collaborator Author

@csviri csviri Oct 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe @lburgazzoli or @adam-sandor , what do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

discussed with @metacosm . Will merge it now, and will do subsequent PRs, if we find a better structure/way.

@csviri csviri merged commit 3a10383 into v2 Oct 26, 2021
@csviri csviri deleted the es-manager-minor-improvement branch October 26, 2021 09:16
@csviri csviri self-assigned this Oct 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Question & Opinion) ResourceController's init(EventSourceManager) method feels a bit vague.
2 participants