Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
abstract rules should be supported through inherited annotation(s) #66
The support of inheriting the boilerplate decorations from a abstract class should be added to reduce said boilerplate in child classes.
*** EasyRules user's abstract class looks something like ***
*** concrete class would look something like ***
Good idea, you are right. When you want your rules to inherit some common logic from an abstract rule, it is cleaner to put annotations once on the base class and override methods in child classes. I do strongly agree with you on that principle, but the effort to make Easy Rules do it is by far greater than the "boilerplate" it is supposed to save the developer from.
Making Easy Rules introspect the whole object hierarchy to look for condition/action methods in abstract classes is not that easy. It looks easy on an example with one abstract class and two concrete classes. But if you want to implement it, there are many considerations to take into account:
You see what I mean? The effort is not that easy, without even considering performance issues (I'm not prematurely opimizing things).
Remember, I agree on the principle, but in practice, the boilerplate of putting annotations on child classes (if we can really call this boilerplate) is not worth the complexity it will introduce in Easy Rules.
Do you agree?
I thank you for taking the time to analyze my humble request and respond in-kind. My goal was to suggest or provide myself, a slight enhancement to your very rational approach to a rules library - keeping things simple, not trying to boil the ocean. I'm buried right now, but I will submit a pull request and examples for you to consider, within the coming weeks.
I think the deep hierarchy issue requires more analysis - I'd love to know the more complicated use cases engaged by library users - my intuition says it's probably not as big of a problem as one might think, especially if you manage expectations up front; a user of the library who cares to decorate an abstract "rule" class gets the responsibility of implementing their solution(s) correctly.
BTW- I'm using your library for an IOT project at a fortune 10 company, and I've noticed that the division of code implementing the when()/then() methods is seldom 50/50 but more like 90/10 or 80/20 in either direction, so that might factor into the deep hierarchy analysis.
Thank you, you are welcome. Feel free to suggest any improvement, easy rules is not perfect!
I work on a couple of open source libraries, and in my little experience, users will abuse your library.
Very happy to hear that! coool
added a commit
May 9, 2017
I've re-read this thread and looks like I didn't fully understand your request.
I thought Easy Rules should do a lot of work to introspect deep rule objects hierarchies, but I think adding
I've added this in version 2.5.0-SNAPSHOT.
Could you please give it a try and tell me if this is ok for you?
Looking forward for your feedback.