Ruby中extend self工具模块的实例变量相关技术问询

First, let's recap the example code for context:

module ExampleModule
  extend self

  @my_instance_variable = "Hello from module"

  def do_thing
    puts "**** #{@my_instance_variable}"
    @my_instance_variable
  end
end

1. Why does this scheme work? How can a module method (without instantiation) access an instance variable? #

In Ruby, every object—including modules and classes—can have instance variables. Here's the breakdown:

• When you define @my_instance_variable directly inside the module (not inside a method), you're assigning it to the ExampleModule object itself (the module is an instance of the Module class).
• The extend self line adds all the module's instance methods to its own singleton class. This means methods like do_thing become callable directly on the module (e.g., ExampleModule.do_thing).
• When do_thing runs, self refers to the ExampleModule object. So @my_instance_variable in the method is accessing the instance variable of the module object, not an instance of the module.

Ruby's core documentation clarifies that modules are first-class objects with their own state and methods. Instance variables on modules are part of this object-oriented design—they belong to the module instance itself, not any objects that include or extend the module.

2. What are the applicable scenarios for this pattern? #

You're right that using instance variables on a module feels counterintuitive at first, since we usually associate instance variables with class instances. But this pattern makes sense in specific cases:

• Singleton-like modules with encapsulated state: When you need a utility module that maintains state between method calls, but don't want to create a singleton class or use global variables. For example, a configuration module that stores app settings specific to the module, or a cache that persists between calls to the module's methods.
• Avoiding global scope pollution: Unlike global variables, the module's instance variables are only accessible to the module's own methods, keeping state encapsulated.
• Simplified API: Since you don't need to instantiate the module, the API stays clean (e.g., ExampleModule.do_thing instead of creating an instance first).

That said, this pattern should be used sparingly. If your module needs complex state management, a dedicated singleton class might be more readable and maintainable.

3. Should we replace instance variables with class variables? Rubocop flags @@foo as a code smell. #

No, class variables are not a better alternative here, and Rubocop's warning is justified. Here's why:

• Class variables (@@) are shared across the entire inheritance hierarchy. If your module is included in another class, that class (and any subclasses) will share the same class variable value as the module. This can lead to unexpected side effects and bugs when state leaks between unrelated parts of your code.
• In contrast, the module's instance variable (@) is strictly tied to the ExampleModule object itself. It's not shared with any classes that include or extend the module, so state remains encapsulated and predictable.

If you want to make the state more explicit, you could use a class instance variable (which is essentially what this pattern uses) or even a constant (if the state doesn't change). But class variables introduce unnecessary coupling and are best avoided here.

内容的提问来源于stack exchange，提问作者Toni K.