-
Notifications
You must be signed in to change notification settings - Fork 25
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
Unified addJob method #229
base: main
Are you sure you want to change the base?
Conversation
Allows to add the new job of any type to the scheduler
@@ -54,6 +66,16 @@ export class ToadScheduler { | |||
this.engines.cronJobEngine.add(job) | |||
} | |||
|
|||
addJob(job: Job): void { | |||
if (job instanceof SimpleIntervalJob || job instanceof LongIntervalJob) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instanceof check is notoriously unrealiable and will not work correctly when comparing instances created in a different realm (e. g. if you are using a job created inside a shared library in an app that depends both on a shared library and on toad-scheduler). I would recommend introducing some id field on the job, and using it for a proper type guard
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test is missing
I think this problem implementation is beyond my skills just yet, thanks for reviewing it |
@jakmaz I can guide you through it, if you want! You have 90% of the solution there, it just needs some small tweaks |
Okay! I suppose I get the point of adding the id field more now. I also thought of another solution, that is adding the abstract method |
Description:
This pull request simplifies the
ToadScheduler
by introducing a unifiedaddJob
method for job addition, deprecating the specific methods likeaddIntervalJob
andaddCronJob
.Rationale:
I chose this simple, single-method design over a polymorphic approach to maintain ease of use and understandability. The alternative considered was a more polymorphic design, where each job type would know how to add itself to the scheduler:
Instead, I used a straightforward approach where the
addJob
method internally determines the job type and delegates to the appropriate method:This approach would follow the Open/Closed Principle more closely but was not adopted due to the stability and limited extension expected in our job types.
Impact:
The update simplifies adding jobs to the scheduler, making the codebase easier to maintain and understand while still allowing for internal specialization for different job types.