4

我发现自己在与深度命名空间（> = 4 的深度）作斗争，即使它们在逻辑上是有意义的，以避免它们引起的一些烦恼。

首先，我希望我的代码能够很好地适合文本编辑器窗口，而不必过宽。尽管 2 sp 的 ruby​​ 常规缩进肯定有帮助，但这促使我使用范围运算符来避免所有嵌套缩进。但另一方面，使用范围运算符会带来一系列问题......

首先，要在当前命名空间上下文的上游某处使用常量，您必须使用该常量的完整命名空间以便 Ruby 找到它。而且由于当我使用范围运算符时，命名空间深度很深，因此引用常量和类会变得很长。

require 'a/b'
class A::B::C
  FOO = 'hi'
end
class A::B::C::D
  # FOO # can't do this. raises NameError: uninitialized constant; would work fine if classes used nested format, but then the extra indent makes for wide code.
  A::B::C::FOO # must use full reference when using scopes, ugh. Depending on the real names of A,B,C, this could be rather long as well.
end

其次，我遇到了一种情况，我必须在我的类定义之后需要文件，我不想这样做（我喜欢顶部的 require 语句），就像这样。

# File: a/b/c.rb
require 'a/b'
# require 'a/b/c/d' # can't put it here, otherwise you get uninitialize const A::B::C when a/b/c/d.rb is getting interpreted.
class A::B::C
  def initialize
    @d = A::B::C::D.new 
  end
end
require 'a/b/c/d' # it bothers me putting requires anywhere but at the top

# File: a/b/c/d.rb
require 'a/b/c'
class A::B::C::D
end

有些东西必须付出。也许我只需要放弃并扩大我的编辑器并坚持嵌套，或者我不了解如何最好地使用范围运算符在命名空间的上下文中工作。

有人对我应该如何处理管理这些问题的深层命名空间有任何建议吗？1. 通过最小化缩进来降低代码宽度 2. 当常量定义在当前上下文的上游时，能够仅使用常量名称 (FOO) 来引用常量 3. 将所有 require 语句保留在源代码文件的顶部

4

1 回答 1

0

你自己在你的问题中回答了你的问题:-)

您试图避免代码中范围过长的问题。

简单地看一下——如果你引用了一个在你的范围层次结构中很深的常量——你可以在技术上做什么：

使用 Ruby 的力量

如果你有一个模块 A 和常量 B ，你可以尝试使用 include A 并访问常量 B 而不引用模块命名空间。

但这可能不是您正在寻找的 - 因为在这种情况下您将包含该模块，但它已经在那里定义了。

寻找根源

看看你是否必须引用命名空间 A::B::C::D 中的常量可能你的系统设计错误？OOP 的目标通常是使数据和方法尽可能接近。

你有两个选择：

  1. 如果您感觉到气味，请改进您的系统设计。
  2. 使用长引用，无论它们在您的编辑器中如何出现 - 只需重复简单的口头禅：“我在这里有这个长引用，因为它应该在那里并且看起来像这样。”

问题就会消失。

您不必使用类似于 Java 的基于包的命名空间。您可以选择一个更方便和简单的命名空间。

于 2012-10-30T20:34:28.077 回答