Originally Posted by
Intrice Joe
garbage take. it is far too easy to store things in a readable format these days for someone to use serialization for something they will store locally. in what world would you want to work with binary blobs over something more readable. it will be a pain to refactor, and you will have binary blobs sitting there that are of no use to query/look at/graph whatever (well unless of course you make special tooling but then...). why in the world would you store things as serialized objects this is 2021 people are literally spoonfeeding you better ways.
scenario: you need to refactor a timed task or remove a timed task type.
OT: Not the way I would do this. Not a fan of relying on package names? to determine which classes belong to which task type. You keep digging yourself deeper and deeper into a pigeonhole when this is supposed to be "abstract". What about a task that happens every 4 hours, or whatever? Why do I need to add a bunch of infrastructure changes to support that? Why is the abstract task forcing you to provide a list of items (I get you can override the giveRewards, but still, why am I forced to implement rewards()). Why not have AbstractTask (everything) -> ItemRewardTask (for convenience, base class for those item reward ones). Your enum also has item rewards... like why are item rewards so heavily integrated into this for no reason.
I would reccomend you take a step back and think "what is the engine here". The answer is: something that will assign/do something to each player based on some "clock time". First make that and then worry about the task stuff secondarily. Right now that is already poorly written and making your life difficult.