我经常在专业环境中使用 R 编程，我也为客户或同事编写包。这里的一些程序员有 Java 背景，坚持以面向对象的方式做所有事情，使用 S4 方法。另一方面，我的经验是，当试图让代码做你想做的事情时，S4 实现的性能通常会更差，并且会引起更多的头痛。
我绝对同意，在某些情况下，您必须能够以受控方式构造复杂对象或附加现有对象。但大多数时候，S4 实现也可以使用经典列表轻松完成，而无需像定义标准泛型、方法、构造函数、初始化程序等那样麻烦。
您何时考虑为 R 编写 S4 实现？
编辑：为了清楚起见，我确实很欣赏 R 中关于 OO 的一般答案和讨论。OOP 可以在 R 中以多种方式完成，但我的问题实际上是针对专门使用 S4 方法的附加值。
我的经验和你的一致，所以我只使用 S3。
澄清一下：S4 有一些巧妙的功能（例如，在多个参数上调度和插槽类型检查），但我还没有遇到过功能超过成本的情况。成本示例包括：任何插槽更改都需要完整的对象副本以及（可能更糟）对 S4 方法的持续更改。
简而言之，我喜欢 S4 背后的想法，但我会等待它成熟后再在我自己的代码中使用它。
我假设这并不直接适用于您，但是如果您正在为 Bioconductor 开发软件包，则有使用 S4 的动机，因为他们积极鼓励使用 S4，并且现在已经使用了十年的大部分时间 - 所以所有核心软件包大量使用 S4。
我发现所有额外的开销都是一种痛苦——setGeneric、setMethod、处理 NAMESPACE 等等。话虽如此，我发现它强加的结构、可扩展性的潜力和其他类似的事情都是值得的。与所有事情一样，需要权衡取舍。我认为它可以更干净 - 我不喜欢 S3 方法如何通过命名约定（foo.class）简单地伪装。尽管如此，我倾向于避免在我自己的代码中大量使用 S4，除非有人告诉我这样做。
好问题！我希望它会引起一些深思熟虑的讨论......
我从未使用过它，也不打算使用它，原因如下：
我喜欢suguar，我能说什么呢！
我学习 S4 是为了扩展动物轨迹数据的空间 (sp) 类。这是可用选项中的最佳选择（最一致、通用且与许多 GIS 定义最匹配），以避免从头开始编写所需的所有内容。我并不觉得 S4 像很多人说的那样繁重，但我现在已经习惯于像这样探索对象的底层结构。性能也不错，我觉得可以做的很好，但是做的不好会有性能的陷阱。
如果您对空间数据感兴趣，spatstat 是一个很好的例子，说明如何在 S3 中做很多与 sp 类似的事情，尽管（就像看似所有空间的东西......）在不同软件中的数据结构之间几乎没有清晰的类比.
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 包开发人员在R-help上的此线程中的评论
Frank Harrell “如果您热爱计算机科学胜过珍惜自己的时间，请使用 S4。”
Terry Therneau 写道： 对于我所做的 90% 的事情，我强烈喜欢松散的（S3）而不是严格的（S4）类......我对 S4 与 S3 的总结
S4 在以下方面有很大的提升：1. 编写麻烦 2. 调试困难 3. 编写非常晦涩的代码的能力 4. 设计
S4 收获： 5. 指导自动转换的能力 6. 验证类对象的内容