为了将 VCL/RTL 映射到 .NET 对象层次结构，Delphi 8 引入了 Class Helpers。它们允许将方法注入现有类，而无需覆盖该类或修改原始类。后来的 Delphi 版本发现类助手得到了改进，它们被移植到 Win32。
在帮助中它说“它们不应该被视为开发新代码时使用的设计工具。”
Class Helpers 违反了传统的 OOP，但我认为这并不会使它们成为一件坏事。这个警告是否合理？
开发新代码时应该使用类助手吗？
您在开发新代码时使用它们吗？
为什么或者为什么不？
根据Malcolm 的评论：新代码意味着日常应用程序开发，其中您有一些 3rd 方库、一些现有代码，然后是您正在编写的代码。
取决于您所说的“新代码”是什么意思。
它们与您新开发的类并不真正相关，因此在这种情况下，不，它们可能不应该使用。
但是即使在一个全新的项目中，您可能仍然需要修改一个您无法通过其他方式更改的现有类（vcl 类、第三方类等）。在这种情况下，当然，我会说继续。
他们本身并不邪恶。与大多数其他事物一样，您只需要了解它们的工作原理并在适当的环境中使用它们。
在将类助手作为花哨代码的新工具之前，我认为您必须了解限制是包含。只能为一个类提供一个类助手。那么，如果您为您的类提供类帮助器，并且您的类派生自某个其他人为其提供了类帮助器的公共类，将会发生什么？
CodeGear 将类帮助器作为“黑客”引入以防止破坏事物，而不是作为一个很酷的设计功能。当您设计代码时，请在没有类助手的情况下进行设计。我知道你可以。在处理您可以控制的现有代码时，请使用重构。如果没有其他办法，请寻求班级帮手。
无论如何，这就是我的看法...
微软基于 LINQ 主要围绕他们的扩展方法。鉴于此，如果可以改进您的代码，您应该在新代码中使用 Class Helpers。请参阅类助手有什么好的用途？一些好的用途。
我经常使用它们。我使用远程对象，那里的对象是由 RO 引擎创建的，所以你不能在不从它们下降的情况下添加它们，然后再进行其他一些乱七八糟的事情。类助手意味着我可以像对待任何其他对象一样对待它们。虽然一个类只能有一个助手，但您可以下降助手类，以便获得继承的行为。
抱歉，暂时不能成为明显的队长：如果 Delphi 内部人员自己声明“不应将它们视为开发新代码时使用的设计工具”，那么根据定义，它们不应该被使用。它们只是为了自己的目的而扩展 VCL。还有谁会给你一个比写它的人更好的理由？
我同意 Vegar 的观点：将班级助手作为紧急工具。当您知道它们是在规定时间内完成工作的唯一方法时。稍后，如果有时间，请删除它们。
我曾经忘记了一个参数化的事情，如果 Delphi 2006 中不存在类助手，那将花费大量的时间..... 使用类助手，需要 6 个小时才能使 thigs 正常工作。但是，这是一种紧急情况——类助手是一种晦涩难懂的语言特性，它给新开发人员遵循程序流程带来了困难。
也许您可以使用的一个好方法是（就像我使用的那样）：
.Net Extensions 方法太相似了，并且出于完全相同的原因创建和支持：制作基类的扩展（而不是在 Delphi.Net 中进行升级而不是尝试使 Delphi 本机代码成为一种选择）与.Net代码“兼容” - 恕我直言，这太雄心勃勃了）
无论如何， Delphi 类助手在某些情况下仍然是一个相当不错的工具。
这些听起来像 C# 扩展方法。我想说，虽然当您无法修改需要扩展功能的类时，像这样的扩展方法很有用，但它们是设计您自己的代码的糟糕方法。在设计自己的代码时，您希望所有功能尽可能位于同一个代码文件中，而不是分散在不同的类中。我会说将它们用于它们的目的——基本上作为装饰器来为封闭的类添加新功能——并且不要在设计你自己的代码时使用它们。
我发现自己越来越多地将它们用作设计结构。
我使用它们的情况：
事实上，我希望 Delphi 能够接受同一个基类的多个助手——如果我没记错的话，我什至已经为此提出了请求。
我发现这篇文章很有趣。它处理 C++，但主要思想与语言无关。主要要点是，即使在 OOP 环境中，全局例程有时也比方法更可取。从这个角度来看，对类助手的需求较少。