我要求 Ruby 这样做，但我想这个原则可以应用于每个具有多个文件的项目。假设我有一个主文件，例如application 需要一些其他模块 model1 和 model2。这两个模块都需要common 模块。我见过很多 Ruby 项目需要 common 在 application 和 not 在 model1 和 model2。如果您总是直接使用application，这可以工作，但如果您需要其他地方的模块之一，您会得到NameError。那么这可能会影响项目的模块化吗？我是否应该总是更喜欢明确要求每个文件中的所有依赖项？ （不做任何关于 哪里 需要文件的假设）
【问题讨论】：
标签： ruby dependencies require modularity
如果一个模块被设计为从不同的应用程序加载，我总是需要所有依赖项。如果model1只是一个应用特定的元素，你不需要加载已经加载的模块。
但它会看看，真正需要什么。
model1 和 model2 需要 common 还是需要 mainfile.rb？ （我不认为，在您的特定情况下就是这种情况）有时您不需要加载所有需求，如果您的需求之一（我们称之为主需求）已经加载了其他（子）需求。
【讨论】：
我将requires 放在使用required 的东西的文件中。这会将您的代码分成可移植模块。您可以在目录/命名空间之间移动文件，您可以取出部分并将它们放入其他存储库/项目中，或者将它们变成宝石。在需要时使用requireing 也可以使您的代码更具交流性，因此更易于理解。读者可以更早地了解文件中代码的责任范围。
通过将requires 放在某个上层或顶层文件中，您将嵌入高层文件与低层文件的耦合。较高级别的文件获取有关较低级别文件的功能和需要的知识。您还模糊了实际使用依赖项的位置。如果您希望删除未使用的依赖项，这会使清理更具挑战性。您无法轻易说出给定依赖项的使用位置和方式。如果将requires 放在使用它们的位置，那么当您从该文件中删除依赖项使用时，您可以从给定文件中删除require，如果它恰好是另一个文件中的required，您的应用程序不会因为拆除而破裂。如果将require放在上级文件中，则存在开发者可以从一个文件中删除使用，然后认为不再使用依赖项，并从上级文件中删除require的风险，从而破坏使用它的其他文件中的代码。
【讨论】：