关键是要看你所谓的“新代码”是什么意思。
对于新开发的类来说，它们并不是相关的，所以在这种情况下，不应该使用它们。
但即使在全新的项目中，你可能仍然需要修改一个现有的类，而无法通过其他方式进行更改（vcl类，第三方类等）。在这种情况下，我认为可以使用。
它们本身并不是邪恶的。像大多数其他事物一样，你只需要了解它们的工作原理，在适当的上下文中使用它们。
Microsoft在LINQ中大量使用了扩展方法。因此，如果使用类助手可以改善您的代码，您应该在新代码中使用它们。请参见什么是类助手的好用途？以获取一些好的用途。
我经常使用它们。我使用远程对象和由RO引擎创建的对象，因此您不能在不从它们下降然后进行其他操作的情况下添加到它们中。类助手意味着我可以像处理任何其他对象一样处理它们。虽然一个类只能有一个帮助程序，但您可以下降帮助程序类，以便获得继承的行为。
抱歉，我必须明确一点：如果内部的Delphi人员自己声称“它们不应被视为在开发新代码时使用的设计工具”，那么根据定义，它们不应该被使用。它们只用于扩展VCL以满足他们自己的目的。谁比编写它的人更能给出更好的理由呢？
我同意Vegar的观点：类助手是一种紧急工具。当你知道它们是在规定时间内完成任务的唯一方式时，可以使用它们。稍后，如果有时间，就可以将它们删除。
曾经有一次，我忘记了一个参数设置，如果Delphi 2006中不存在类助手，将花费大量的时间......有了类助手，只需要6个小时来让事情正常运作。但是，这是一种紧急情况 - 类助手是一种模糊的语言特性，对于新开发者来说，跟随程序的流程会造成困难。
这些听起来像是C#扩展方法。我会说，虽然这样的扩展方法在你没有能力修改需要扩展功能的类时很有用，但它们并不是设计自己代码的好方法。在设计自己的代码时，你希望所有功能尽可能地位于同一个代码文件中，而不是分散在不同的类中。我会建议将它们用于它们的预期用途--作为装饰器来向封闭类添加新功能--而不要在设计自己的代码时使用它们。
我发现自己越来越多地将它们用作设计构造。
我使用它们的情况：
事实上，我希望 Delphi 能够接受同一基类的多个助手 - 如果我记得正确的话，我甚至已经提交了这个请求。
我觉得这篇文章非常有意思。它讨论了C++，但主要思想是独立于语言的。主要观点是在面向对象的环境中，全局程序有时比方法更可取。从这个角度来看，类帮助程序的需求会减少。
