当前位置：文江博客话题详情

“Ruby 方式” （混合和类重新打开）与依赖注入

发布于 2024-11-29 22:05:29 字数 760 浏览 1 评论 0 原文

在研究 mixin 与依赖注入时，我经常听到“Ruby 方式”这个短语。开发人员经常会说一些类似的话

Ruby 允许您重新打开类并重新定义方法，这意味着您可以在测试时轻松地将新引用“注入”到您的代码中。

（参见#6 http://weblog.jamisbuck.org/2007/7/29/net -ssh-revisited）

但是测试不是我主要关心的；我关心的是类的重用。我想要可以在多个企业级 Rails 应用程序中重用的类。

那么 REUSING 类发生了什么？使用 mixins 和重新打开类似乎并没有提供一种编写类的方法，使它们与特定于应用程序的细节分离，而无需进行大量额外的工作。但也许我错了。如果是的话，有人可以提供包含示例代码的文章的链接，该文章清楚地解释了如何使用 mixin 和重新打开类来正确完成此任务吗？

作为一个例子，这里的 Foo 类与 Logger 类耦合：

class Foo
  def initialize
    @logger = new_logger
  end

  def new_logger
    Logger.new
  end
end

是的，我可以重新打开 Foo 并重新定义 new_logger，但我只是不敢相信这被认为是编写可供多个 Rails 应用程序使用的可重用类的现实、标准方法。

原文

In studying mixins vs. dependency injection, I often hear the phrase "the Ruby way." Often developers say something along the lines of

Ruby lets you reopen classes and redefine methods means that you can
easily "inject" new references into your code at test-time.

(see #6 at http://weblog.jamisbuck.org/2007/7/29/net-ssh-revisited)

But testing is not my main concern; my concern is class reuse. I want classes I can reuse in multiple enterprise-scale Rails applications.

So what happened to REUSING classes? Using mixins and reopening classes does not seem to provide a way to write classes in such a way that they are decoupled from application-specific details without a bunch of extra work. But Perhaps I am wrong. If I am, can someone provide a link to an article containing sample code that clearly explains how to accomplish this properly using mixins and reopening of classes?

As an example, the class Foo here is coupled to the class Logger:

class Foo
  def initialize
    @logger = new_logger
  end

  def new_logger
    Logger.new
  end
end

Yes, I can reopen Foo and redefine new_logger, but I just cannot believe this is considered a realistic, standard approach to writing reusable classes usable by multiple Rails applications.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

水水月牙 2024-12-06 22:05:29

实际上，当我从 Java 世界来到 Ruby 世界时，我感兴趣的第一件事就是它们如何管理依赖关系。当时我在所有 java 项目中都使用 Google Guice，它巧妙的设计和易用性给我带来了很大的启发。我在 ruby 中做的第一件事是我自己的 DI 容器，它具有与 Google Guice 大致相同的功能集 - (它仍然在 github 上，但已经非常过时了）。

但现在，在使用 Rails/Ruby 两年之后，我认为这里不需要 DI。关于 ruby 中 DI 的好文章是 http://weblog .jamisbuck.org/2008/11/9/legos-play-doh-and-programming 它实际上是一篇关于为什么第一个 DI 容器的作者不需要 DI 的文章红宝石。这绝对值得一读。

回复收藏 0 原文

还如梦归 2024-12-06 22:05:29

好吧，我们可以在 Ruby 中重新打开类并不意味着我们总是必须这样做，您可以将重新打开类视为最后的手段。你有一个库，除了一个方法之外，它可以完成你需要的所有事情，而不是分叉整个库修补它并使用你的分叉，你可以简单地重新打开类，重新定义方法，然后你就可以再次开始工作了。这不是你愿意做的事情，但有能力做到这一点是非常有用的。

说了这么多，在 Ruby 中，我们有一个概念几乎总是可以很好地替代依赖注入——鸭子类型。由于没有类型检查，您可以将任何对象传递给函数，只要该对象具有函数期望的方法，一切都会正常工作。

让我们看看你的例子 - 它并不是真正有利于依赖注入的类，你不会在Java中这样写，例如，如果你想注入一些依赖项。您只能通过构造函数或 getter 和 setter 进行注入。因此，让我们以这种方式重写这个类：

class Foo
  def initialize(logger)
    @logger = logger
  end
end

更好的是，我们现在可以将记录器注入/传递到我们的 Foo 类中。让我们添加一个使用此记录器来演示的方法：

class Foo
  def initialize(logger)
    @logger = logger
  end

  def do_stuff
    @logger.info("Stuff")
  end
end

在 java 中，如果您想使用不同类型的记录器创建 Foo 对象，所有这些记录器都必须在非常字面意义上实现相同的接口（例如公共类记录器实现 Loggable），或者至少是子类。但在 Ruby 中，只要对象有一个接受字符串的 info 方法，您就可以将其传递到构造函数中，Ruby 就会继续愉快地运行。让我们演示一下：

class Logger
  def info(some_info)
  end
end

class Widget
  def info(some_widget_info)
  end
end

class Lolcat
  def info(lol_string)
  end
end

Foo.new(Logger.new).do_stuff
Foo.new(Widget.new).do_stuff
Foo.new(Lolcat.new).do_stuff

通过调用 do_stuff 方法的上述 Foo 类的所有 3 个实例，一切都会正常工作。

从这个例子中可以看出，遵守 OO 设计原则仍然很重要，但 Ruby 对于接受的内容限制较少，只要有正确的方法，一切都会好起来的。

根据您的看法，鸭子类型要么使依赖注入完全无关，要么使其比以往更强大。

Well just because we can reopen classes in Ruby doesn't mean we always have to, you can think of reopening classes as the method of last resort. You have a library which does everything you need except for one method, rather than forking the whole library patching it and using your fork, you can simply reopen the class, redefine the method and you're in business again. This is not something you would do willy-nilly, but having the ability to do this is extremely useful.

Having said all of that, in Ruby we have a concept that can almost always be a good substitute for dependency injection - duck typing. Since there is no type checking you can pass any object into a function and as long as the object has the methods that the function would expect, everything will work fine.

Let us look at your example - it is not really class that is conducive to dependency injection, you would not write it like this in Java, for example, if you wanted to inject some dependencies. You can only inject through the constructor or through getters and setters. So let's rewrite this class in that way:

class Foo
  def initialize(logger)
    @logger = logger
  end
end

Much better we can now inject/pass in a logger into our Foo class. Let's add a method that would use this logger to demonstrate:

class Foo
  def initialize(logger)
    @logger = logger
  end

  def do_stuff
    @logger.info("Stuff")
  end
end

In java if you wanted to create Foo objects with different types of loggers, all those loggers would have to implement the same interface in very literal sense (e.g. public class logger implements Loggable), or at least be child classes. But in Ruby as long as the object has an info method that accepts a string, you can pass it into the constructor and Ruby keep chugging along merrily. Let's demonstrate:

class Logger
  def info(some_info)
  end
end

class Widget
  def info(some_widget_info)
  end
end

class Lolcat
  def info(lol_string)
  end
end

Foo.new(Logger.new).do_stuff
Foo.new(Widget.new).do_stuff
Foo.new(Lolcat.new).do_stuff

With all 3 of the above instances of the Foo class calling the do_stuff method, everything will work fine.

As you can see from this example adhering to the principles of OO design is still important, but Ruby is somewhat less restrictive about what it will accept, as long as the right methods are there everything will be fine.

Depending on how you look at it duck typing either makes dependency injection totally irrelevant or makes it more powerful than ever.

回复收藏 0 原文

孤蝉 2024-12-06 22:05:29

简单的答案是，Ruby 语言中没有任何东西可以阻止您编写可重用的类。使用混合和类重新开放的常见方法并不一定会促进它，但该语言实际上并不会阻止其他方法。将“Ruby Way”视为“Ruby 可以做的事情”的子集。

也就是说，我知道通常最好使用语言构造来强制执行设计决策，并且据我所知（我会警告您在这个主题上还远未完成）DI 目前并不是核心的 Ruby 主义。不过，我在 Google 上找到了一些关于这个主题的文章，这让我相信，如果您愿意的话，可以找到一些库可以将 DI 添加到 Ruby（尽管它们似乎受到了许多 Rubyists 的批评）。内容丰富的文章包括这些两个，和这个问题。希望有帮助。