クラス ヘルパーは、スコープ内で「最も近い」ヘルパーに基づいてのみクラスに適用されるため、クラスはヘルパーが存在することを単純に認識できません。たとえば、ユニットにクラス ヘルパーを作成して、ソースのない別のユニットのクラスを「助ける」ことができます。他の単元のクラスには、ヘルパーに関する手がかりがありません。この知識があった場合、これを考慮して再コンパイルする必要があります...これは次の問題につながります。
これを考慮してください: アプリケーション全体で他の多くのユニットによって使用される 1 つの共通ユニットで宣言されたクラスを持つことができます。これらの各ユニットで、異なるメソッドと「ヘルパー」関数を使用して、この共通クラスの新しいヘルパーを宣言します。各ユニットは、独自のヘルパーを宣言している他のユニットについて何も知らないため、設計上、すべてのヘルパーを結合する方法はありません。ここで、この共通ユニットがプリコンパイル済みパッケージの境界を越えて存在することを考えてみてください。
クラスヘルパーは魅惑的な小さな異教徒です。彼らは名声と幸運を約束しますが、あまりにも多くの場合、彼らは死と破壊を降らせます... あなたが彼らの策略に屈した後もずっと。
このため、言語への導入により、非常に具体的な問題、つまり既存のフレームワークに機能を導入するために「現れる」能力が解決されました。「ヘルパーは 1 人のみ」というルールを守り、その道を外れなければ、比較的無傷で出現する可能性があります。とにかく、これらの水域をナビゲートするには、ベオウルフ、レオニダス(スパルタの)、フロド・バギンズの腸の強さを組み合わせる必要があります.
そのため、ここ RAD Studio チームでは、回避できるクラス ヘルパーを使用することを嫌います。そして、私たちがそれらを使用する場合、開始する前に適切なファランクスが形成されます...
ここにドラゴンがいる…