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