Tukukkk

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

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.

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

Hope this helps.

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.