-
Notifications
You must be signed in to change notification settings - Fork 50
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
Improve naming of find(…) methods in OrderManager #61
Comments
i can do this |
Feel free to go ahead. Be aware that we need to deprecate the existing methods to not break user code and provide a migration path. |
ok, i take care of that. Is it part of M 6.2 or 6.x |
I don't suspect that to be done until the end of the week, which is when 6.1 is scheduled for. Please create a pull request against master and we can then decide which branches to merge it to. |
@AndreasZaschka - The commit you linked looks like something we could actually use. Mind to create a pull request from that one? |
Slightly tweaked the method names in OrderManager to make sure calling them doesn't create unnecessary duplication in terms. E.g. a previously existing call: Iterable<Order> orders = orderManager.findOrdersByUserAccount(userAccount); can now be written like this: Iterable<Order> orders = orderManager.findBy(userAccount); The types and variable names carry enough information to communicate what's going on. Removed final declarations for methods in PersistentOrderManager as the type is package protected anyway. Introduced a builder style factory method for Intervals so that creating them changes from new Interval(start, end) to a more fluent Inveral.from(start).to(end). This also allows us to remove some assertions from the OrderManager implementation into the value object which makes them much more testable. Adapted test cases according to the API changes. Original pull request: #106.
No description provided.
The text was updated successfully, but these errors were encountered: