親または他のフォームからアクセスする必要があるテキスト ボックスなどのコンポーネント/オブジェクトを含む .Net フォームがある場合、このコンポーネントの修飾子を内部またはパブリック レベルの変数に「アップグレード」する必要があります。
ここで、フォーム クラスで int 型または string 型などのパブリック変数を提供している場合、Getters と (おそらく) Setters を直接提供する以外に何もしなかったとしても、これを使用することについて二度考えることはありません。変数にアクセスします。
ただし、VS デザイナーは、フォーム上のコンポーネントであるパブリック オブジェクトに対してそのような Getter/Setter を実装していないようです (したがって、適切なプログラミング プラクティスに準拠していません)。
それで、問題は次のとおりです。「正しいこと」を行うには、そのような VS デザイナー コンポーネントまたはオブジェクトをゲッターやセッターでラップする必要がありますか?
「しかし、VS デザイナは、フォーム上のコンポーネントであるパブリック オブジェクトに対して、そのような Getter/Setter を実装していないようです (したがって、適切なプログラミング プラクティスに準拠していません)。」
フォームにドラッグ アンド ドロップしているコントロールを意味する場合、これらはプライベート インスタンス メンバーとしてマークされ、フォームの Controls コレクションに追加されます。なぜそうでないのでしょうか？フォームには 40 または 50 のコントロールが含まれる場合があります。フォーム上のすべてのコントロールにゲッター/セッターを提供するのは、やや不必要で扱いにくいものです。デザイナーは、パブリック ゲッター/セッターを介して特定のコントロールへの委任アクセスを提供するかどうかをユーザーに任せます。
デザイナーはここで正しいことを行います。
これは、オブジェクト指向設計におけるカプセル化の典型的な例です。
フォームは、UI をユーザーに提示し、入力を受け入れるオブジェクトです。フォーム オブジェクトとコードの他の領域との間のインターフェイスは、フォームの内部実装の詳細を公開するインターフェイスではなく、データ指向のインターフェイスである必要があります。フォームの内部動作 (つまり、コントロール) は、使用するコードから隠されたままである必要があります。
成熟したソリューションには、おそらく次の設計ポイントが含まれます。
そしてそれは、単体テストのようなメタ開発についても言及していません。
フォーム上のコンポーネントに Getter と Setter を実装しない理由は、それらが「スレッド セーフ」ではないためだと思います.NET オブジェクトは、それらを作成したフォーム スレッドによってのみ変更されると想定されています。潜在的に任意のスレッドに対して開いています。代わりに、これらのオブジェクトへの変更が、オブジェクトを作成してそこで実行されたスレッドに委任される委任システムを実装するとします。
私はいつもそうしています。MVP 設計に従っている場合は、ビュー コンポーネントのゲッター/セッターを作成することが設計要件になります。
「優れたプログラミング手法に準拠していない」という意味がわかりません。Microsoft は、 (迅速なアプリ開発のために) Visual Studio での作成を容易にするための多くの優れたプログラミング プラクティスに違反しており、コントロールのゲッター/セッターの欠如がそのようなベスト プラクティスに違反している証拠とは思えません。