我是否应该明确要求每个文件中的所有依赖项？
我对 Ruby 提出了这个要求，但我想这个原则可以应用于每个具有多个文件的项目。假设我有一个主文件，例如 application，它需要一些其他模块 model1 和 model2。这两个模块都需要 common 模块。我见过许多 Ruby 项目在 application 中需要 common，而在 model1 和 model2 中不需要。虽然如果您始终直接使用application，则此方法有效，但如果您需要来自其他地方的模块之一，则会收到NameError。那么这可能会影响项目的模块化吗？我是否应该总是更喜欢明确要求每个文件的所有依赖项？ （不做任何关于需要文件的位置的假设）
I am asking this for Ruby, but I guess this principle can be applied to every project with multiple files. Say I have a main file e.g. application that requires some other modules model1 and model2. Both those modules need the common module. I've seen many Ruby projects that would require common in application and not in model1 and model2. While this works if you always use application directly, if you require one of the modules from elsewhere, you get a NameError. So maybe this impacts the modularity of the project? Should I always prefer requiring explicitly all the dependencies from every file? (By not making any assumption about where the file is required from)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果模块设计为从不同的应用程序加载，我总是需要所有依赖项。如果
model1只是应用程序特定的元素，则无需加载已加载的模块。但还是要看看，真正需要的是什么。
model1和model2是否需要common还是需要 mainfile.rb？ （我不认为，您的具体情况就是这种情况）有时，如果您的要求之一（我们称之为主要求）已经加载了其他（子）要求，则您不需要加载所有要求。I would always require all dependecies if a module is designed to be loaded from different applications. If
model1is only an application specific element, you don't need to load already loaded modules.But it would take a look, what's really needed.
Does
model1andmodel2needcommonor does require the mainfile.rb? (I don't think, that's the case in your specific case) Sometimes you don't need to load all requirements, if one of your requirements (let's call it main-requirment) already loads the other (sub-)requirements.我将
require放置在正在使用require内容的文件中。这会将您的代码分成可移植的模块。您可以在目录/命名空间之间移动文件，并且可以取出部分并将它们放入其他存储库/项目中，或者将它们变成 gem。在需要的地方进行require的做法也使您的代码更具沟通性，因此更容易理解。读者可以尽早了解文件中代码的职责范围。通过将
require放在某个上层或顶级文件中，您就嵌入了上层文件与下层文件的耦合。较高级别的文件获取有关较低级别文件的用途和需求的知识。您还模糊了实际使用依赖项的位置。如果您希望删除未使用的依赖项，这会使清理工作变得更具挑战性。您无法轻松判断给定依赖项在何处以及如何使用。如果require放在使用它们的地方，那么当您从给定文件中删除依赖项使用时，您可以从该文件中删除require，并且如果它恰好是require在另一个文件中，您的应用程序不会因为删除而中断。如果将require放在更高级别的文件中，则存在开发人员可以从一个文件中删除使用情况，然后认为不再使用依赖项，并删除require 的风险来自更高级别的文件，从而破坏使用它的其他文件中的代码。I place the
requires in the very files that are using the things that are beingrequired. This sections off your code into portable modules. You can move files among directories/namespaces, and you can pluck parts out and put them into other repositories/projects, or turn them into gems. The practice ofrequireing where needed also makes your code more communicative, and therefore easier to understand. A reader is better-informed early on about the area of responsibility of the code in the file.By putting the
requires up in some upper- or top-level file, you are embedding the coupling of the higher-level file with the lower-level one. The higher-level file acquires knowledge about what the lower-level file does and needs. You also obscure where dependencies are actually used. This makes cleanup more challenging, should you desire to remove unused dependencies. You can't tell as easily where and how a given dependency is used. Ifrequires are put where they are used, then you can remove arequirefrom a given file when you remove the dependency usage from that file, and if it happens to berequired in another file, your app will not break because of the removal. If you putrequirein the higher-level file, there is risk that a developer can remove the usage from one file, and then think that the dependency is no longer used, and remove therequirefrom the higher-level file, thereby breaking the code in other files that use it.