我在专业环境中定期在R中编程,我也为客户或同事编写包.这里的一些程序员具有Java背景,并坚持使用S4方法以面向对象的方式做所有事情.另一方面,我的经验是,在尝试让代码按照您希望的方式执行操作时,S4实现通常会更糟,并且会导致更多的麻烦.
我绝对同意,在某些情况下,您必须能够以受控方式构造复杂对象或附加现有对象.但大多数时候,S4实现也可以使用经典列表轻松完成,没有像定义standardGeneric,方法,构造函数,初始化器等那样麻烦.
你什么时候考虑为R编写S4实现？
编辑:为了清楚起见,我非常感谢R.OOP中的答案和关于OO的讨论可以在R中以多种方式完成,但我的问题实际上是针对特定使用S4方法的附加值.
Jos*_*ich 26
我的经验与你的一致,所以我只使用S3.
澄清一下:S4有一些光滑的功能(例如,多个参数上的调度和插槽类型检查),但我没有遇到功能超过成本的情况.成本的示例包括:任何插槽更改都需要完整的对象副本,并且(可能更糟)需要对S4方法进行持续更改.
简而言之,我喜欢S4背后的想法,但在我自己的代码中使用它之前,我会等待它成熟.
geo*_*try 25
我假设这并不直接适用于你,但如果你正在开发包Bioconductor的有使用S4的激励,因为他们积极鼓励它的使用,现在已经有十年的大部分时间 - 所以所有的核心包大量使用S4.
我发现所有额外的开销都很痛苦 - setGeneric,setMethod,处理NAMESPACE等等.话虽如此,我发现它所强加的结构,可扩展性和其他类似的东西都值得.与所有事情一样,需要进行权衡.我认为它可以更清晰 - 我不喜欢S3方法如何简单地通过命名约定(foo.class)来伪装.所有这一切,我倾向于避免在我自己的代码中大量使用S4,除非我被告知这样做.
好问题!我希望它会产生一些深思熟虑的讨论......
我从未使用它,也不打算出于以下原因:
我喜欢suguar,我能说什么!
我学习了S4以扩展动物跟踪数据的Spatial(sp)类.它是可用选项中最好的选择(最一致,通用且与许多GIS定义紧密匹配),以避免从头开始编写所需的所有内容.我发现S4并不像许多人所说的那样繁重,但我现在习惯于探索像这样的物体的基础结构.性能也很好,我认为它可以很好地完成,但是当表现不佳时会有性能陷阱.
如果您感兴趣的是空间数据,那么spatstat就是如何在S3中执行大量类似事务的一个很好的例子(尽管看起来一切都是空间......),不同软件中的数据结构之间几乎没有清晰的类比.
S4类在空间统计(sensu包sp)中发挥着重要作用,从一种类型的数据到另一种类型的转换似乎是无缝的.这个问题的缺陷就是调试,根据我的经验,调试最多也是乏味的.到目前为止,我已经使用S3管理,但可能会考虑将来使用S4.
随着时间的推移,随着事情的发展,我相信它们将至少在R的各个领域的核心特征中发挥重要作用(可能是空间分析,计量经济学,环境学......)
不要忘记还有R.oo(在CRAN上)它提供了在R中执行OO的第三种方式.在我看来,这提供了一个OO系统,对于从其他系统迁移的程序员来说可能更熟悉 - 特别是没有通用函数(所以print(foo)然后必须在foo类上调度)方法绑定到对象,所以你要做foo $ print() - 就像在python或C++中你做的那样foo.print ().
曾几何时，Roxygen2 不喜欢 S4 方法。截至 2017 年（至少），他们一直在合作。
我很不幸地创建了一些需要方法来处理 S3 和 S4 类的函数。多年来保持这些代码正常运行是非常痛苦的，因为 R-core 多次更改了这些系统如何交互、命名空间如何工作以及 Rcmd 检查如何工作的细节。
如果您不喜欢 Google 的风格指南，请考虑R-help上此线程中这些著名 R 包开发人员的评论
Frank Harrell “如果您热爱计算机科学胜过珍惜自己的时间，请使用 S4。”
Terry Therneau 写道： 对于我所做的 90% 的事情，我强烈喜欢松散的 (S3) 而不是严格的 (S4) 课程......我对 S4 与 S3 的总结
S4 在以下方面有较大增量： 1. 编写麻烦 2. 调试困难 3. 能够编写非常晦涩的代码 4. 设计
S4 增益： 5. 直接自动转换的能力 6. 验证类对象的内容