I'm inclined to switch it to an abstract class until we can get to traits. Now that it is handling its own enqueue options associative array, I'd have to add a handful of new methods to the interface that should really only have 1 implementation but would just be missing.

An interface with an abstract base class could break things up, but I'd already ONLY be using that abstract base class across all apps, everywhere. The interface would only exist to make us feel warm/fuzzy, but not actually be useful to a practical app.

"allow any object to present a job interface" I'd like to push back on that too from an SRP perspective, because I think it's probably a bad idea. A background job is a really specific and delicate thing, why should classes with other major responsibilities also know how to execute some small part of themselves later in the background?

lmk your thoughts! :8ball: