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

PolicyDispatcher is always an EventListener #21

Open
mjdecker opened this issue Sep 27, 2017 · 1 comment
Open

PolicyDispatcher is always an EventListener #21

mjdecker opened this issue Sep 27, 2017 · 1 comment

Comments

@mjdecker
Copy link
Contributor

mjdecker commented Sep 27, 2017

Have an example branch (policy will rename to this issue number) with some suggested changes, may not have worked out the kinks yet.

But....

A PolicyDispatcher always additionally needs to inherit an EventListener. The srcSAXEventDispatcher requires it. I say we make a PolicyDispatcher inherit from EventListener so we are not requiring clients to do both. Its confusing.

Took a while to figure out how things work again, possibly because of this.

Slightly related, I made the constructor accept multiple PolicyListeners (in addition to multiple EventListeners). So, consistent.

@mjdecker
Copy link
Contributor Author

Not sure if it is a good idea as well, but we could also do the following to simplify things.

Eliminate EventListener make it a part of PolicyDispatcher.
Rename PolicyDispatcher to Policy as that is what we refer to them as.
Maybe rename EventDispatcher to Dispatcher, move it to dispatcher, or remove it. Or some combination. The remove it would be a move from the Polymorphic open/closed principle to the Meyer's open/closed principle. Although, I tend to like the Polymorphic one.

This may people do not get confused with what a policy listener and dispatcher is and what an event listener and dispatcher is and when to use them. Someone would only need to know about policy listener/dispatcher and event would be pretty much hidden. Problem is they are forced to implement DataInner.

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

No branches or pull requests

1 participant