红宝石继承与混入 [英] ruby inheritance vs mixins

问题描述

在 Ruby 中，由于您可以包含多个 mixin，但只能扩展一个类，因此 mixins 似乎比继承更受欢迎.

In Ruby, since you can include multiple mixins but only extend one class, it seems like mixins would be preferred over inheritance.

我的问题:如果您正在编写必须扩展/包含才能有用的代码，为什么要将其设为类?或者换句话说，你为什么不总是把它做成一个模块?

My question: if you're writing code which must be extended/included to be useful, why would you ever make it a class? Or put another way, why wouldn't you always make it a module?

我只能想到一个你想要一个类的原因，那就是如果你需要实例化这个类.但是，在 ActiveRecord::Base 的情况下，您永远不会直接实例化它.那么它不应该是一个模块吗?

I can only think of one reason why you'd want a class, and that is if you need to instantiate the class. In the case of ActiveRecord::Base, however, you never instantiate it directly. So shouldn't it have been a module instead?

推荐答案

我刚刚在The Well-Grounded Rubyist(顺便说一下，这是一本好书).作者比我解释得更好，所以我会引用他的话:

I just read about this topic in The Well-Grounded Rubyist (great book, by the way). The author does a better job of explaining than I would so I'll quote him:

没有单一的规则或公式总能带来正确的设计.但保持一个当您做出类与模块的决定时，请记住几个注意事项:

No single rule or formula always results in the right design. But it’s useful to keep a couple of considerations in mind when you’re making class-versus-module decisions:

• 模块没有实例.因此实体或事物通常是最好的在类中建模，实体或事物的特征或属性是最好封装在模块中.相应地，如第 4.1.1 节所述，类名称往往是名词，而模块名称通常是形容词(堆栈与 Stacklike 相比).

• Modules don’t have instances. It follows that entities or things are generally best modeled in classes, and characteristics or properties of entities or things are best encapsulated in modules. Correspondingly, as noted in section 4.1.1, class names tend to be nouns, whereas module names are often adjectives (Stack versus Stacklike).

一个类只能有一个超类，但它可以混入任意数量的模块.如果你在使用继承，优先创建一个合理的超类/子类关系.不要用一个类唯一的超类关系来赋予班级可能只是几组特征之一的东西.

A class can have only one superclass, but it can mix in as many modules as it wants. If you’re using inheritance, give priority to creating a sensible superclass/subclass relationship. Don’t use up a class’s one and only superclass relationship to endow the class with what might turn out to be just one of several sets of characteristics.

在一个示例中总结这些规则，以下是您不应该做的:

Summing up these rules in one example, here is what you should not do:

module Vehicle 
... 
class SelfPropelling 
... 
class Truck < SelfPropelling 
  include Vehicle 
... 

相反，你应该这样做:

module SelfPropelling 
... 
class Vehicle 
  include SelfPropelling 
... 
class Truck < Vehicle 
... 

第二个版本更简洁地对实体和属性进行建模.卡车源自 Vehicle(这是有道理的)，而 SelfPropelling 是车辆的一个特征(至少，我们在这个世界模型中关心的所有那些)——由于 Truck 作为后代而传递给卡车的特征，或者专门形式，车辆.

The second version models the entities and properties much more neatly. Truck descends from Vehicle (which makes sense), whereas SelfPropelling is a characteristic of vehicles (at least, all those we care about in this model of the world)—a characteristic that is passed on to trucks by virtue of Truck being a descendant, or specialized form, of Vehicle.

这篇关于红宝石继承与混入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！