I am getting lots of push back from Rails because I have subclassed User into many different subclasses. In my application, not all users are equal. There’s actually a lot of model objects and not every User type has access to them.
I also need a way to do polymorphic behaviour. For example, many methods will behave differently depending on the type. Isn’t that what polymorphism is for?
But the thing is, I am always getting push back from Rails. The defaults – especially the way forms submit to parameter hashes – seem to work like non-subclassed models. Links and parameter hashes are just two ways in which the defaults really bite you.
What is the “right” way to handle complex logic for different types of Users in Rails? In Java, the subclassing model works – you don’t have to go through hoops to get it to work the way you want to. But in Rails, it’s hard to get subclasses to work with REST conventions, it punishes you when you forget to include :as => :user, or it punishes you when you put a subclassed object in links, such as edit_user_path(@user) <- bad idea!
There’s one other area which is also very hard to deal with. Let’s say I have a Company model and it has many Users. These users can be directors, instructors, trainees, etc – all different subclasses.
When we create the account, we might want to use accepts_nested_attributes_for :users. However, if we use this, we can’t specify the classes that it creates. Bloody hell!
It seems like everything in Rails is designed to not want you to subclass your models. If you don’t subclass, everything ‘just works’. But if you subclass, you are in for hell.
What is the solution?
Generally speaking, inheritance is discouraged in Ruby in favor of mixin behavior and delegation. Ruby and Rails can do that stuff but it tends to result in the push back you mentioned
Your particular example sounds like a case for delegation: have a User class which belongs to an employee (or vice versa). The type-specific behavior of that employee (eg director, instructor, etc) is all in that specific employee class. Then the user will delegate how to handle specific scenarios to the employee that it’s joined with