Delphi 8 では、VCL/RTL を .NET オブジェクト階層にマッピングする目的でクラス ヘルパーが導入されました。クラスをオーバーライドしたり元のクラスを変更したりせずに、既存のクラスにメソッドを注入できます。それ以降のバージョンの Delphi では、クラス ヘルパーが改善され、Win32 に移植されました。
ヘルプには、「新しいコードを開発するときに使用する設計ツールと見なすべきではありません」と書かれています。
クラス ヘルパーは従来の OOP に違反していますが、それが悪いことだとは思いません。この警告は保証されますか?
新しいコードを開発するときにクラス ヘルパーを使用する必要がありますか?
新しいコードを開発するときにそれらを使用しますか?
なぜですか、そうでないのですか？
Malcolmのコメントによると: 新しいコードとは、いくつかのサード パーティ ライブラリ、いくつかの既存のコード、そして作成中のコードがある日常的なアプリケーション開発を意味します。
「新しいコード」の意味によって異なります。
それらはあなたが新しく開発しているクラスにはあまり関係がないので、その場合、いいえ、おそらく使用すべきではありません。
しかし、まったく新しいプロジェクトであっても、他の方法では変更できない既存のクラス (vcl クラス、サードパーティ クラスなど) を変更する必要がある場合があります。この場合、確かに、先に進むと思います。
それら自体は悪ではありません。他のほとんどのものと同様に、それらがどのように機能するかを理解し、適切なコンテキストで使用する必要があります.
派手なコードの新しいツールとしてクラス ヘルパーを採用する前に、インクルードの制限を理解する必要があると思います。1 つのクラスに対して 1 つのクラス ヘルパーしか提供できません。では、自分のクラスにクラス ヘルパーを提供し、そのクラスが、他の誰かがクラス ヘルパーを提供している共通クラスから派生した場合はどうなるでしょうか?
CodeGear はクラス ヘルパーをクールなデザイン機能としてではなく、壊れないようにするための「ハック」として導入します。コードを設計するときは、クラス ヘルパーを使用せずに設計します。私はあなたができることを知っています。制御できる既存のコードを扱う場合は、リファクタリングを使用します。他に方法がない場合は、クラスヘルパーに連絡してください。
どう見ても私の意見です…
Microsoft ベースの LINQ は、拡張メソッドに重点を置いています。その観点から、コードを改善する場合は、新しいコードでクラス ヘルパーを使用する必要があります。クラス ヘルパーの適切な使用方法を参照してください。いくつかの良い用途のために。
よく使います。私はリモートオブジェクトを使用しており、そこにあるオブジェクトはROエンジンによって作成されているため、それらのオブジェクトから降りて、他のビットをいじり回さずにオブジェクトに追加することはできません。クラスヘルパーとは、他のオブジェクトと同じように扱うことができることを意味します。また、クラスに含めることができるヘルパーは1つだけですが、ヘルパークラスを降順にして、継承された動作を取得することができます。
申し訳ありませんが、しばらくの間キャプテンを自明にするしかありません。Delphiの内部の人々自身が「新しいコードを開発するときに使用する設計ツールと見なすべきではない」と述べている場合、定義上、使用すべきではありません。それらは、VCLを独自の目的でのみ拡張するためにあります。それを書いた人々よりも他に誰があなたに良い理由を与えるつもりですか？
たぶん、あなたが使用できる良いアプローチは（私が使用しているように）です：
.Net 拡張メソッドは非常に似ており、まったく同じ理由で作成およびサポートされている場所:基本クラスの拡張を作成します ( Delphi.Net でのアップグレードは、Delphi ネイティブ コードの種類を作成するためのオプションではありませんでした)。 .Netコードとの「互換性」の-IMHOこれは野心的すぎました）
とにかく、Delphi クラス ヘルパーは、状況によっては依然としてかなりのツールです。
緊急ツールとしてのクラス ヘルパー。提供された時間内に物事を成し遂げるための唯一の方法であることがわかっている場合。後で、時間があれば、それらを削除します。
私はかつてパラメータ化のことを忘れていました.Delphi 2006にクラスヘルパーが存在しなかった場合、膨大な時間がかかりました.....クラスヘルパーを使用すると、正しく動作するようになるまでに6時間かかりました. しかし、これは緊急事態でした。クラス ヘルパーはあいまいな言語機能であり、新しい開発者がプログラムの流れをたどるのが困難になります。
この記事はとても興味深いと思いました。C++ を扱いますが、主なアイデアは言語に依存しません。主な要点は、OOP 環境であってもグローバル ルーチンがメソッドよりも好まれる場合があるということです。この観点からすると、クラス ヘルパーの必要性は少なくなります。
私はそれらをデザイン構造としてますます使用していることに気づきました。
私がそれらを使用する状況：
実際、Delphi が同じ基底クラスに対して複数のヘルパーを受け入れてくれることを願っています。私の記憶が正しければ、この要求を提出したことさえあります。
これらは C# 拡張メソッドのように聞こえます。このような拡張メソッドは、機能を拡張する必要があるクラスを変更できない場合には便利ですが、独自のコードを設計する方法としては不十分です。独自のコードを設計する場合、さまざまなクラスに分散するのではなく、すべての機能をできるだけ同じコード ファイルに配置する必要があります。基本的には、クローズド クラスに新しい機能を追加するためのデコレータとして使用し、独自のコードの設計には使用しないでください。