在Ruby的其他模块中包含模块意味着什么？

Question

module Fabrication
  module Syntax

    # Extends Fabrication to provide make/make! class methods, which are
    # shortcuts for Fabricate.build/Fabricate.
    #
    # Usage:
    #
    # require 'fabrication/syntax/make'
    #
    # User.make(:name => 'Johnny')
    #
    #
    module Make
      def make(*args, &block)
        overrides = Fabrication::Support.extract_options!(args)
        klass = name.underscore.to_sym
        fabricator_name = args.first.is_a?(Symbol) ? "#{klass}_#{args.first}" : klass
        Fabricate.build(fabricator_name, overrides, &block)
      end

      def make!(*args, &block)
        overrides = Fabrication::Support.extract_options!(args)
        klass = name.underscore.to_sym
        fabricator_name = args.first.is_a?(Symbol) ? "#{klass}_#{args.first}" : klass
        Fabricate(fabricator_name, overrides, &block)
      end
    end
  end
end

Object.extend Fabrication::Syntax::Make

Answer 1

It is essentially namespacing. You could do the same thing with just module Fabrication::Syntax::Make . For whatever reason, nesting them is what most well-known gems/projects do, and for that unknown reason I do too. I would love to get some insight as to why people generally prefer nesting over the more direct method.

Answer 2

As you in your last line. If you define module inside of other module , it will be namespaced. So with your code Make module will be accessible from outside Fabrication module definition with its namespace:

Fabrication::Syntax::Make

This allows you to define module Make in root namespace without naming conflict.

Answer 3

Namespacing. you can drill into nested namespaces with the :: operator.

Check this out:

module Galaxy
  module StarSystem
    module Planet
    end

    Galaxy     # references Galaxy
    StarSystem # references Galaxy::StarSystem
    Planet     # references Galaxy::StarSystem::Planet

  end
end

Galaxy                     # references the Galaxy module
Galaxy::StarSystem::Planet # References the Planet module declared above.
Planet                     # Exception! No constant Planet exists in this namespace

As you can see, this allows you structure your code in a manner that keeps things modular. You can write a component that uses man different classes and modules, but are all housed under a single namespace. From within that code you can easily access any constant declared in it's own namespace or that of a parent namespace. But other code cannot see these constants unless you explicitly drill into them.

The result is well organized and structured components, which can be easily mixed with other components because they exist entirely within a single name that is unlikely to conflict with other code in the project.