サンプルコードも、オブジェクト指向を意識しております。操作することが可能だったりします。私はそういうことはしないようにしております。その理由を以下に述べております。インスタンスを生成することで得る安全性インスタンスを生成することで、確実に初期化されたものを扱うことができます。同じものを複数扱う時にはインスタンスを複製することで簡単に可能ですから安全です。ところが、インスタンスを生成せず、直接操作してしまうとそうはいきません。アプリケーションを終了しない限りは、初期化されているという保証がありません。暗黙的にインスタンス化された唯一のフォームを、参照している場所をすべて把握するのは困難です。オブジェクトだろうと何だろうと、変数はなるべく局所的にすべきです。同じものを制限なく呼び出せるというプログラム設計は、不具合の温床になります。フォームはクラスであるフォームはメソッドなどにアクセス修飾子が設定できますのでクラスであると言えます。関与してはいけないことになります。関する処理を記述するのは、カプセル化の概念を壊していることに他なりません。処理はフォームでやるのが定石です。プロパティを通してアクセスフォームがクラスであるということは、フォーム内のコントロールはメンバとなります。困ったことにこのコントロールは直接触ることが可能ですが、それはやめましょう。外部から値を参照したい場合は、プロパティを通すようにするべきです。プロパティが定義されていることで、外部から参照されていることを「明示化」できるからですクラス内のメンバは隠蔽化されるべきですから、当然といえば当然です。公開するという行為はあってはいけないことです。昨今、そんなソースを見かけることがありますが、イベントの概念を壊すようなことはしないでください。起こすのであれば、それはメソッドにするべきプロシージャであり、わざわざイベントにしてまで概念を壊すこともないでしょう。厳密には手続き型言語ですが、オブジェクト指向言語に近いコーディングをすることが可能です。生産性が良いと言われているにも関わらず、デバッグなどに時間を浪費することがあります。意識して組んでいない場合だったりしないでしょうか?特に他人のソースは、なおさらに時間がかかってしまいます。オブジェクト指向における継承やインターフェースの実装は大変便利ではありますが、必須条件ではありません。カプセル化による隠蔽化こそが必須条件であり、本当の恩恵なのだと考えます。モジュールひとまとまりの機能をクラスに集約することで、他人が見ても見やすいです。それは、外部から参照するべきもの、内部だけで処理するものが明確に分けられているからです。使用する側が意識しなくても良いものは隠蔽化することで、何をどう使えば良いか明確になります。これは実生活でも同様です。家電製品のリモコンは、よく使う機能が前面にあり、あまり使わない機能は隠されています。モジュールで実装し、欲しい機能だけを公開するのが良いと考えます。モジュールでやれば良いというものではありません。単発で使用するような汎用関数などは、標準モジュールなどを利用した方が賢明です。標準モジュールは静的クラスのように使う標準モジュールでもアクセス修飾子は指定できますから、静的クラスのように使用できます。いえ、モジュール名を省略できてしまうのが、つらいところです。いう公開された関数があるとします。呼び出せてしまうのです。モジュール名を省略してしまうと、どの位置にある関数なのか明確でなくなるので省略しない方が良いでしょう。いって、ハンガリアン記法のような「basDateTimeHelper.GetServerDate」と表記しても可読性が良くないです。静的クラスのように使うのであれば「DateTimeHelper.GetServerDate」のように表記したいものです。使うメリットはないでしょう。そもそも、変数を局所的に使用する設計であえば、ハンガリー記法は必要ありません。ついてハンガリー記法は、どの位置まで有効なアクセス修飾子なのか明確でなくなるような設計である場合に必要になる記法です。傾向にあるため必要ないです。ローカル変数の場合は普通に管理できるでしょうから、なおさらに必要ありません。(と言いつつこのサイトでは使っていますが)それでも使うとなれば、コントロールで使うことになるでしょう。様々な方にもお話を伺いましたが、やはり皆さんも同じ考えで、コントロール以外で使用することはないそうです。関連するリファレンス準備中です。reserved.当サイトはリンクフリーです。