I’m coding some payroll software in Ruby, and it’s meant to be used by companies both in the US and Canada (with possibility of future expansion elsewhere.) Obviously for some classes like Employee, there is going to be some shared functionality, but a lot of differences as well. For example, some regulatory data and business logic will only have to be used in one country or the other.
Since a company can contain only one type of employee in this app (that is the employees of a company can only be Canadian or American), I was thinking of just using mixins to add the different functionality at runtime, instead of creating an inheritance hierarchy which has the potential to become extremely cumbersome. The Employee class will not be the only class which has differences between countries, so it seems it would be helpful to dynamically augment all my classes to include regional functionality at runtime.
Is this is an effective way to organize my app, or are there some downsides to this?
This sounds like a pretty good use case for modules. Note though that Ruby also has the delegator pattern in it’s standard library, maybe you could simply use that to forward certain messages to a generic employee object. It’s always hard to recommend something with so little knowledge of the requirements.
If you want to read some more on mixins, “Eloquent Ruby” by Russ Olsen has a good chapter on it (chapter 16, “Use Modules As Mixins”). I wouldn’t recommend buying the book just for that, but it’s a good read anyway. I’m not sure, somewhere in that book there even seems to be an example somewhat similar to what you try to do (different context, same principle).