class Element

  class Div < Element

  end

  class Paragraph < Element

  end

end

class Element

end

module Elements

  class Div < Element

  end

  class Paragraph < Element

  end

end

module Element

  class Base

  end

  class Div < Base

  end

  class Paragraph < Base

  end

end

class Element

end

class DivElement < Element

end

class ParagraphElement < Element

end

解决方法

这方面的官方消息来源不多;但是,使用模块来包含库,代码和类组是一种风格.

超类中的子类

优点：

>自包含：整个类系统包含在一个名称下

缺点：

>不自然：谁会想到在超类中查找子类？

将子类置于超类中实际上取决于具体情况.但是,该方法的任何好处也可通过模块方法实现.但实际上,这还没有完成.类在这里包含方法,实例变量,类方法等.但是类可以被认为是最后一级嵌套 – 除非是非常特定的情况,否则类中没有类.

我能想到这个有意义的一种情况是,使用子类的唯一方法是通过超类,例如具有内部子类(如XML,PDF等)的Formatter类.假设您只使用这些类通过做Formatter.new(：xml)之类的事情.但是如果我们这样做,子类应该是私有的,无论如何都不能被外界访问.在这一点上,继承是一种非常方式,而不是Rubyish.

基类外部模块,子类内部

优点：

>我想不出任何

缺点：

> Implies Non-conected：如果Element与其子元素不在同一个命名空间中,超出名称的内容告诉我它甚至是相关的？

这种方法非常不自然.它使得它看起来好像Element与它的孩子没有任何关系,或者如果用不同的方式看,它的子项是内部实现细节,不需要处理.无论哪种方式,它看起来像破旧,草率命名和糟糕的代码结构规划.如果我使用它来阅读代码,我必须查看Elements模块的内容,看看Element是否已经被子类化了 – 这不是最自然的事情.

模块中的类和子类(最佳解决方案)

优点：

> Contained：超类和所有Element类都包含在一个名称空间中,允许它们轻松导入,需要,迭代等.还有助于元编程.
> Includable：这些类可以很容易地包含在任何代码中.
>清除：Element和子类之间存在明显的关联.它们显然是一组功能.

缺点：

>鼓励懒惰的命名：这确实鼓励你为像Base这样非常模糊的类命名.

这是最好的方法.它使类成为一个整洁的包,同时仍然显示一个明显的关联和明显的“在这里,使用我的Div类”(而不是类中的子类策略).此外,这对于元编程非常有用,其中包含模块中的所有内容对于使事情有效至关重要.最后,这适用于autoload,require_relative,include等构造.这些表明这是语言的设计方式.

强制命名约定

优点：

>简单：这里没有复杂性.
>消除歧义：通过将它们转换为DivElement和ParaElement来消除Div或Para等短名称的歧义.

缺点：

> Archaic：组类或方法的命名约定只应存在于没有更好方法的语言中,例如C或Objective-C.一旦获得名称空间,C就会删除它.
>没有编程分组：这些命名约定虽然对人类很清楚,但是对于元编程代码来说,类结构非常混浊,并且使得程序无法作为一个组来处理类.
>污染全局命名空间：这会在全局命名空间中创建许多名称,这总是一个坏主意.

这是一个非常非常糟糕的解决方案.它包含了编写草率,C风格的代码,几乎没有组织和意义.这些命名约定只能用于没有更好解决方案的语言,Ruby有很多更好的解决方案.即使定义数组中的所有类也比命名约定更好.

注意：但是,如果您真的想要,可以在Div或Para等短名称上定义命名约定,只要您仍然将它们保存在模块中,这样它就是Elements :: DivElement.但是,这违反了DRY,我不会建议.

结论

所以,你真的有两个选择.把所有东西放在一个模块中：

module Elements
  class Element; end
  class Div < Element; end
  #etc...
end

或者,将所有内容放在具有命名约定的模块中：

module Elements
  class Element; end
  class DivElement < Element; end
  #etc...
end

为了清晰,使用标准方法和元编程原因,我采用前者.