Assume my users can subscribe to several plan_types. I want to define those plans as classes, and be able to keep, for each user, a reference to a subscription_plan and also a presubscription_plan. This is like a State pattern :

class Payment::SubscriptionPlan
  def self.max_subscription_quantity
    120
  end 
end

class Payment::ConcretePlan1 < Payment::SubscriptionPlan
  def self.commitment_period
    2.months
  end
end

class Payment::ConcretePlan2 < Payment::SubscriptionPlan
  def self.max_subscription_quantity
    50
  end
end

What is the best way to "persist" the relation to a class in the database ? Currently I was doing the following using the as_enum gem

class Settings
  setting :subscription_plans, type: Array, default: [
    Payment::ConcretePlan1, 
    Payment::ConcretePlan2
  ]
end

class User
  as_enum :subscription_plan, Settings.subscription_plans, map: :string
  as_enum :presubscription_plan, Settings.subscription_plans, map: :string

  def subscription_plan
    return nil if super.nil?
    Payment.const_get(super.to_s.demodulize)
  end

  def presubscription_plan
    return nil if super.nil?
    Payment.const_get(super.to_s.demodulize)
  end
end

The current implementation works but I'm not sure this is the best way to tackle the problem

  • ConcretePlan1 has a subscription period where as the other plans do not. Shouldn't all plans also have a subscription period? If these classes are just placeholders for returning a particular value, you can have that same functionality? – BKSpurgeon May 19 '17 at 13:21
  • Some payment systems involve automatic payment where I need to specify a period (eg. Stripe), whereas some other subscriptions are managed from the outside. I have factories to handle the subscriptions but I need to save the type of subscription for that :D And actually no commitment_period is a bit different than the subscription period : for monthly payment, our offer stipulates that you have to pay for at least 3 months when you start a subscription. When paying yearly, no such commitment period apply. – Cyril Duchon-Doris May 19 '17 at 13:27

It works that's for sure.

But enums could just as easily be defined in the database. Now that you've already got it working with enums, I would say stick with enums untill you have a good reason to change it.

anyways, here's how i probably would have done it:

e.g.

  • user has_many subscription_plans
  • subscription_plan can belong to many users.
  • Limit the ability for a user to have a max of two, one of each type. Or the user must have two at any one time etc.

enter image description here

You get the picture. You can change the subscription plan table to suit your needs.

Hope this helps.

  • Hey thanks. I'm using a class object on my server since I need to define methods on the subscription_plan (subscription_plan.max_quantity, etc.) which is why I want to initialize some Ruby object where I can add whatever methods I want. I edited my example to include this. I'm not just using this as string enum. – Cyril Duchon-Doris May 17 '17 at 10:50
  • @CyrilDuchon-Doris: You should be able to still add methods and behavior specific to a kind of plan. ActiveRecord allows you to specify a "descriminator" column to instantiate a particular concrete class, giving you some of the benefits of polymorphism. – Greg Burghardt Jul 11 at 21:48
  • Also just realized the OP has a "mongo-db" tag. – Greg Burghardt Jul 11 at 21:58

It sounds like you really need subscription plans to be data-driven. The methods you are defining on the concrete types are really just data. No need for concrete types. You need a better database table (and I use the term "table" loosely since you tagged the question with mongodb):

| id | name   | max_subscription_quantity | commitment_period_num | commitment_period_type |
| 1  | Plan 1 | 120                       | 2                     | Month                  |
| 2  | Plan 2 | 50                        | NULL                  | NULL                   |

There really isn't a need for sub classes. Just one class ought to do it:

class Payment::SubscriptionPlan
  def commitment_period
    # return period based on type and number
  end
end

The only thing you need to define is commitment_period which does the calculation of the commitment_period_num and commitment_period_type columns.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.