ruby - 奇怪的 Ruby 类初始化逻辑？

Question

我在我的应用程序中集成的一些开源代码有一些类包含实现该效果的代码:

class SomeClass < SomeParentClass

  def self.new(options = {})
    super().tap { |o|
      # do something with `o` according to `options`
    }
  end

  def initialize(options = {})
    # initialize some data according to `options`
  end

end

据我所知，self.new 和 initialize 都做同样的事情——后者是“构建期间”，前者是“构建后”，在我看来，这是一种可怕的模式 - 为什么将对象初始化分成两部分，其中一个显然是“错误的想法(tm)”？

Answer 1

理想情况下，我想看看 super().tap { |o| 里面有什么 block ，因为虽然这看起来像是不好的做法，但也许在 initialize 之前或之后需要一些交互被称为。

如果没有上下文，您可能只是在看一些有效但在 Ruby 中不被认为是好的做法。

但是，也许单独的方法self.new和 initialize方法允许框架设计者实现框架的子类化部分，并仍然确保完成框架所需的设置，而不会出现需要特定使用 super() 的稍显笨拙的文档。 .如果最终用户仅通过子类 class MyClass < FrameworkClass 获得他们期望的功能，那么记录和外观更简洁的 API 会稍微容易一些。并且没有一些额外的注释，例如:

When you implement the subclass initialize, remember to put super at the start, otherwise the magic won't work

. . .我个人认为这种设计有问题，但我认为至少会有一个明确的动机。

可能有更深层次的 Ruby 语言原因让代码在自定义中运行 self.new block - 例如，它可能允许构造函数在返回之前切换或更改特定对象(甚至返回不同类的对象)。然而，我很少在实践中看到这样的事情，几乎总是有一些其他方法可以在不自定义的情况下实现此类代码的目标 new .

---

定制/不同的例子Class.new评论中提出的方法:

• Struct.new它可以选择采用类名并返回该动态创建的类的对象。

• In-table inheritance for ActiveRecord ，它允许最终用户从表中加载未知类的对象并接收正确的对象。

后一种可能可以通过不同的 ORM 继承设计来避免(尽管所有这些方案都有利弊)。

第一个 (Structs) 是语言的核心，所以现在必须像那样工作(尽管设计者可以选择不同的方法名称)。