I am currently working on a project based on ruby on rails. A particular feature of the website involves sending timely notifications through mails which contained a summary all the posts posted on the website. The mail was sent at a default interval of 30 days. So each user received a mail on a different day based on the day of his registration and also the date of the last news letter sent which was one of the data associated with the user.
But now I am thinking of adding settings to newsletter so that a user can configure the interval on which he wants to get the newsletter. So instead of sending newsletter based on the date last news letter was sent, I would like to send the newsletter to all the users on particular days of the month.
For example if a user wished to receive a newsletter weekly it would be sent on every sunday of the week. for monthly the newsletter would be sent on 1st on every month and so on.
One approach that came to my mind is to create a base class for sending newsletters and then creating subclasses for monthly,weekly… and so on to utilize the object orientedness of ruby. But I am not sure if this is the best way to proceed with solving the problem.
I wanted to know if there are other ways this problem could be solved. I do not need a ruby on rails way of solving, anybody having experience with solving this problem in any other programming language may help.
This is a design issue, and it may come down to whether it becomes more cumbersome to break the scheduling behavior into multiple classes. You will avoid a case statement, which is an indication that polymorphism could have been used.
If you do, however, choose to use separate classes, this is a good time for the ActiveRecord implementation of the type field. Each subscriber belongs to a schedule. (I’d recommend a schedule has one subscriber.)
The schedules table would have a type field, with the name of the class. You don’t have to set the type. Instead, to store the schedule, create the schedule object using the association from the subscriber object, and ActiveRecord will set the type field.
Now, whenever you get a schedule object from the database, it will be the class specified in the type field. You can have class for day of the week, a different one for date of the month, and as many different classes as different date calculation behaviors.
Do store the next due email date. This should be in the schedules table, but you could put it in the subscribers table, if that’s more convenient.
Use a method to calculate the next due date. Make sure that method has the same signature in all the classes. So, for the monthly schedule, store the date of the month in the table and do not pass the date of the month to the common method. That way the delivery code can call the method to update the due date, without having to know anything about the schedule algorithm or data.