我正在用 Ruby 编写一些工资单软件，它打算被美国和加拿大的公司使用（未来有可能在其他地方扩展。）显然对于像 Employee 这样的一些类，会有一些共享功能，但是也有很多不同之处。例如，一些监管数据和业务逻辑只需要在一个国家或另一个国家使用。
由于公司在此应用程序中只能包含一种类型的员工（即公司的员工只能是加拿大人或美国人），我想在运行时使用 mixins 添加不同的功能，而不是创建继承层次结构这有可能变得非常麻烦。Employee 类将不是唯一在国家/地区之间存在差异的类，因此动态扩充我的所有类以在运行时包含区域功能似乎会有所帮助。
这是组织我的应用程序的有效方式，还是有一些缺点？
这听起来像是一个非常好的模块用例。请注意，尽管 Ruby 在其标准库中也有委托模式，但也许您可以简单地使用它来将某些消息转发到通用员工对象。在对需求知之甚少的情况下，总是很难推荐一些东西。
如果你想了解更多关于 mixins 的内容，Russ Olsen 的“Eloquent Ruby”有一个很好的章节（第 16 章，“将模块用作 Mixins”）。我不建议仅仅为此而购买这本书，但无论如何它都是一本好书。我不确定，在那本书的某个地方，甚至似乎有一个与您尝试做的事情有些相似的例子（不同的背景，相同的原则）。
一般来说，在大多数情况下，对我来说使用 mixins 而不是继承似乎更好。继承是一种非常特殊的关系，并且通常看起来比它所提供的功能增加了更多的复杂性。通常，继承似乎需要更多地摆弄基类，而不是看起来很健康。当需要一个新的子类时，基类往往会随着一个或多个子类的特殊逻辑而增长。我发现 mixin 往往更易于重用，因为它们往往更小并且更专注于一个问题。