什么是跟踪开发状态和/或可视化所有 R 包如何相互链接（及其“第三方”依赖项）的好方法？

我通常会尝试应用“分而治之”的策略，到现在 - 5 年后 - 导致相当多的包具有明确的功能范围。但是我已经达到了一种状态，事情已经（明显地）变得如此分散，以至于我无法理解所有的依赖关系，并且“我在实际项目中需要的乐高积木在哪里”：-/

所以我想我正在寻找

1. 所有包依赖项的映射表示
2. 一些占用空间最小的“包开发管理”框架/策略

REP我很难理解和之间的区别CRP。有没有人有一个最好的例子直观的解释？

到目前为止我发现了什么：

REP (Reuse-Release-Equivalence-Principle)：复用的粒度就是发布的粒度。包中的类应该在内容方面相关，并服务于更高级别的主题。

CRP (Common-Reuse-Principle)：组件不打算依赖于它们不需要的类。一起使用的类应归为一个组件。

我不明白的是为什么REP要告诉包容性原则（包裹变大）和CRP排他性原则（包裹变小）？此外，如果某些东西在内容（REP）方面属于一起，那么它不是也一起使用（CRP）吗？

REP如果我只根据和CRP忽略来设计我的包，为什么我会因为太多的组件修改而遇到麻烦CCP (Common-Closure-Principle)？

动机

我正在开发一个 R 包（调用它pkg），它在运行缓存中收集一些由其函数调用生成的对象。list将缓存实现为命名空间中的对象（调用它.cache）非常简单pkg。但是，我想防止用户直接干扰缓存，它总是可以通过:::语法暴露：pkg:::.cache.

也就是说，我想保护.cache类似于面向对象编程中的私有字段。所有操作.cache都应由内部辅助函数完成，这些辅助函数由@export具有“API 风格”的 ed 函数专门调用。

问题

因此，我有在命名空间中定义一个environment对象（称为它.vault）的想法，所以我可以......把 my.cache放在我的.vault.

我的困惑是，像这样的环境.vault是 R 中为数不多的通过引用起作用的东西之一。所以我担心pkg:::.vault会暴露.vault其内容或对其内容进行修改和查看。我可以改变我的访问器功能，pkg:::.get_cache()这样它们.vault就不会启用这种暴露，但是如果可以直接就地修改，所有这些努力都是徒劳的。

别跑

例如，考虑下面这个危险的(?) 代码。首先，我从、 到“识别目标”检查内部.S3MethodsClasses环境：dplyr

然后我检查该rowwise_df对象并认为它是一个有价值的“目标”：

最后，我利用了这样一个事实，即与dplyr命名空间中的大多数对象不同......

...一个像.S3MethodsClasses 点引用这样的环境，所以它的内容可以很容易地就地修改：

就这样，“金库”被抢劫了！

怀疑

我怀疑答案可能就在这里，lockEnvironment()和朋友一起，但应用程序有点超出我的能力。也许我可以做一些事情.onLoad来设置.vault环境，然后它会被lock*()编辑——它.vault本身和其中的绑定——但不是在和一个访问器函数之间建立一个活动绑定之前，它将填充在命名空间中。.cache.get_cache()pkg

笔记

我已经在开发一个功能来终止（帮助）函数，比如.get_cache()当它们在命名空间的同伴函数之外被调用时pkg。因此，曝光pkg:::.get_cache()不会让用户.get_cache()手动操作或在他们自己的自定义功能中操作。

正规

我特别感谢 R 开发人员的建议，他们有足够的经验提供一个规范的答案（如果有的话）。