nickfelt 7e80b5646f Make Cancellation OneTime vs Recurring logic explicit ... This CL does a very similar cleanup to Cancellation as the diffbase does to GracePeriod - see [] It simplifes logic where we used to overload methods to accept eitherw OneTime or Recurring billing events refs, despite storing them in separate fields in the entity (since BillingEvent is not a polymorphic superclass, just a Java-only one, you can't store them as refs to BillingEvent). That overloading was ultimately only there as a convenience/hack from when we added Recurring events and didn't want to go back and change everything. It obfuscates what's really going on, requires extra casting/loss of type-safety, and relies on indirect signals (e.g. the Billing event reason being AUTO_RENEW) to guess what the right billing event type is. That latter aspect will likely no longer work in a monthly billing world, and was brittle anyways (as came up in the context of removing the AUTO_RENEW reason - see [] ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=117165174		2016-03-16 21:20:25 -04:00
..
com/google	Make Cancellation OneTime vs Recurring logic explicit	2016-03-16 21:20:25 -04:00