Поскольку помощники класса применяются только к классу на основе того, что помощник является «ближайшим» по объему, класс просто не может знать, что помощник существует. Например, вы можете создать помощника класса в вашем модуле, чтобы «помочь» классу из другого модуля, для которого у вас нет источника. Класс в другом подразделении понятия не имеет о каких-либо помощниках. Если бы у него было это знание, то его пришлось бы перекомпилировать, чтобы учесть это ... что приводит к следующей проблеме;
Учтите это: у вас может быть класс, объявленный в одном общем модуле, который используется многими другими модулями в вашем приложении. В каждом из этих модулей вы объявляете нового помощника для этого общего класса с различными методами и "вспомогательными" функциями. Поскольку каждый юнит не знает ничего о других юнитах, которые также объявляют своего собственного помощника, по замыслу нет способа каким-то образом объединить всех помощников. Теперь учтите, что этот общий модуль теперь находится за границей скомпилированного пакета.
Помощники класса - соблазнительные язычники. Они обещают славу и богатство, но слишком часто они обрушиваются на смерть и разрушение ... еще долго после того, как ты отдаешься их хитрости.
По этой причине их введение в язык решило очень специфические проблемы, а именно способность «появиться» для введения функциональности в существующую среду. Пока вы придерживаетесь правила «только один помощник» и не отклоняетесь от этого пути, вы можете оказаться относительно невредимым. Несмотря на это, вам понадобится объединенная кишечная стойкость Беовульфа, Леонидаса (Спарта) и Фродо Бэггинса, чтобы перемещаться по этим водам.
Учитывая, что здесь, в команде RAD Studio, мы не хотим когда-либо использовать помощника класса, где его можно избежать. И когда мы их используем, соответствующая фаланга формируется еще до того, как мы начинаем ...
Здесь будут драконы ...