Delphi 8引入了类助手，用于将VCL / RTL映射到.NET对象层次结构。它们允许将方法注入到现有类中，而不会覆盖类或修改原始类。更高版本的Delphi发现改进了类助手，并将它们移植到Win32。
在帮助中，它说“在开发新代码时，不应将它们视为一种设计工具。”
班级助手违反了传统的OOP，但我认为这不会使他们成为一件坏事。这个警告是否合理？
开发新代码时是否应该使用类助手？
开发新代码时是否使用它们？
为什么或为什么不呢？
Per Malcolm's comments：新代码意味着每日应用程序开发，您可以在其中拥有一些第三方库，一些现有代码，然后是您正在编写的代码。
答案 0 :(得分：15)
取决于“新代码”的含义。
它们与您新开发的类并不相关，所以在这种情况下，不，它们可能不应该被使用。
但即使在一个全新的项目中，您仍可能需要修改一个您无法以其他方式更改的现有类（vcl类，第三方类等）。在这种情况下，当然，我会说继续。
他们本身并不邪恶。像大多数其他事情一样，您只需要了解它们如何工作并在适当的环境中使用它们。
答案 1 :(得分：8)
在将课程助手作为花哨代码的新工具之前，我认为您必须了解其中包含的限制。只能为一个类提供一个类助手。那么如果你为你的类提供类助手会发生什么呢？你的类派生出一个公共类，其他一些类已经提供了类助手？
CodeGear将类帮助程序作为“黑客”来防止破坏，而不是一个很酷的设计功能。在设计代码时，请在没有类助手的情况下进行设计。我知道你可以。处理您可以控制的现有代码时，请使用重构。如果没有其他办法，请联系上课助手。
无论如何都是我的意见......
答案 2 :(得分：6)
基于Microsoft的LINQ严重依赖其扩展方法。有鉴于此，如果改进了代码，你应该在新代码中使用Class Helpers。有关一些好的用途，请参阅What are good uses for class helpers?。
答案 3 :(得分：3)
我经常使用它们。我使用远程对象和RO引擎创建的对象，所以你不能添加它们，而不是从它们下降，然后其他一些乱七八糟的东西。班级助手意味着我可以像对待任何其他对象一样对待他们。虽然一个类只能有一个帮助器，但是你可以下降辅助类，这样就可以获得继承的行为。
答案 4 :(得分：2)
对不起，我不禁会成为Obtain上尉：如果内部Delphi人员自己声明“他们不应该被视为开发新代码时使用的设计工具”，那么根据定义他们不应该用过的。他们只是出于自己的目的扩展VCL。还有谁会给你一个比写作人更好的理由？
答案 5 :(得分：2)
我同意Vegar的观点：作为紧急工具的课堂助手。当你知道他们是在提供的时间内完成任务的唯一方法。之后，如果有时间，请删除它们。
我有一次忘记了一个参数化的东西，如果在Delphi 2006中不存在课程帮助，那么它将耗费大量的时间.....对于课程助手，需要6个小时才能使这些工作正常。但是，这是一个紧急情况 - 班级助手是一个模糊的语言功能，它给新开发人员制造难以跟踪程序的流程。
答案 6 :(得分：2)
也许你可以使用的好方法是（因为我使用它）：
.Net Extensions方法过于相似，并且出于完全相同的原因创建和支持：在Delphi.Net中扩展基类（而不是升级）不是一个选项为了尝试使Delphi本机代码与.Net代码“兼容” - 恕我直言，这太雄心勃勃了）
无论如何，在某些情况下， Delphi Class助手仍然是一个非常好的工具。
答案 7 :(得分：1)
这听起来像C＃扩展方法。我会说，虽然这些扩展方法在您无法修改需要扩展功能的类时非常有用，但它们是设计自己的代码的一种不好的方法。在设计自己的代码时，您希望所有功能尽可能位于同一代码文件中，而不是分布在不同的类中。我会说将它们用于它们的用途 - 基本上是为封闭类添加新功能的装饰器 - 并且不要在设计自己的代码时使用它们。
答案 8 :(得分：1)
我发现自己越来越多地使用它们作为设计构造。
我使用它们的情况：
事实上，我希望Delphi能够为同一个基类接受多个帮助者 - 如果我记得正确的话，我甚至已经提出了这个请求。
答案 9 :(得分：1)
我发现this article非常有趣。它涉及C ++，但主要思想是语言无关的。主要要点是，即使在OOP环境中，全局例程有时也更适合于方法。从这个角度来看，对课助手的需求较少。