Delphiフレームにネストされたプライベートコンポーネントフィールド

Question

ここでは、Delphiのコンポーネントとフレームを簡単に比較して、最後に私の質問です。

利点デルファイのコンポーネント：彼らはうまくカプセル化されている

• 。コンポーネントを使用するソフトウェアは、コンポーネントの属性としてpublicおよびpublishedにのみアクセスできます。
• すべての内部イベントハンドラは、親フォームのデザイン時に使用できます。

欠点デルファイの成分：彼らは、いくつかのパッケージでインストールする必要が

パッケージは、成分が内部アプリケーション固有であっても、複数のアプリケーション間で共有される

利点デルファイフレーム：

• 彼らはちょうど
• 彼らpublishedプロパティは、フォームで調整することができるコンポーネントと同様に、フォーム上に配置することができ
• 彼らは、アプリ内のみであり、使用できません彼らが属していないアプリの残り
• すぐに利用できます。インストールする必要はありません。

欠点デルファイフレームの：

• その内部の構成要素のすべてが親フォームで直接利用可能です。 publishedセクションからコンポーネントを移動すると、フレームデザイナーでもデザイン時のカスタマイズが壊れます。
• フレーム内のResizeメソッドをオーバーライドすると、すべてのアレンジが実行時にのみ使用可能になります。設計時にアレンジは行われません。
• 新しいpublishedプロパティを導入した場合は、オブジェクトインスペクタで使用できません。
  • 良いカプセル化：私はしたいと思うパートナーはどのよう

  は共生ものです。親フォームから使用できる内部コンポーネントはありませんが、内部コンポーネントはすべて、実行時または設計時に完全に機能します。

• すぐに入手可能インストールする必要はありません。
• アプリ内のみ。他のアプリとの共有はありません。
• 公開されたプロパティはフォームで調整できます
• デザイン時に、すべてのメソッドオーバーライド（特にResizeメソッド）が使用できます。

これらの要件を満たすものをお勧めしますか？それとも、私が知らなかったフレームを扱うための驚くべき方法かもしれませんか？

必ずしもフレームまたはコンポーネントである必要はありません。他のいくつかのVCLクラスがこれらの要件を満たしていれば、私は感謝してそれを受け入れます。