元ネタは「公開されたフィールドは存在が悪であるということ」
でも、そこに到達した元ネタは「Automatic Properties(C#3)」
レベルがわんくまーな方にもわかりやすいように噛み砕いた説明にトライします。
オブジェクト指向の重要な概念にカプセル化(*1)というのがありますが、C#やVB.NETではカプセル化をスマートに実現するための方法としてプロパティ(*2)というのがあります。
カプセル化を守るため、フィールドはすべてカプセル化して外部からアクセスできないようにします。外部からのアクセスが必要なものに関しては対応したプロパティを定義するというのがクラス設計の常套手段です。
しかし、プロパティって書くの面倒くさいのですよね。
たとえば、C#で書くと、
public class hoga
{
public int X;
}
と書けば、外部から自由に使える整数型のXが作れますが、これをプロパティにすると。
public class hoga
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
と、書かなくてはいけません。
ご覧のとおり、コード量がとっても増えます（VBだと、さらにもう少しだけコードが増えます）。
だとすると、エラーチェックとか当面想定してないデータならば、面倒くさいからpublicなフィールドにしちゃって、エラーチェックとかが必要になった時にプロパティに切り替えればよい。という安易な考えが首をもたげます。
私も今まではそれでもよいかも。と、思っていました。修正はクラス定義部分だけで、利用者側はフィールドとプロパティの名前が同じである限り、コード変更する必要は全くないと思っていたので。
ところが、私のこの考えはまったく浅はかでした。フィールドをたとえ同じ名前のプロパティに置き換えただけだとしても、利用者側で再ビルドが必要になるそうです。
なんでも、フィールドとプロパティはコードレベルでは互換があっても、バイナリレベルで非互換であるため、利用者側でも再コンパイルが必要とのことです。
これって大問題ですよね。
汎用的に様々なアプリで使用されるようなクラスにとってはまさに致命的です。
なので、やっぱり、フィールドは確実にカプセル化せにゃいかんのだなぁ。と思いました。
【おまけ】
でも、プロパティ書くんめんどくさい。って時に便利なのがAutomatic Propertiesってことですね。
これならチェック処理が必要になった段階で実装を含む記述に書き換えるだけでOK。バイナリ互換も保たれるってわけですね。
*1 カプセル化 ･･･ クラス内部のフィールド(変数)を外部(クラス利用者)から全く見えないようにすること。
*2 プロパティ ･･･ クラス利用者にとってはフィールド(変数)を直接扱っているように利用できるものだが、実際には処理を経由してフィールド(変数)にアクセスさせている。処理を経由するため、エラー値を排除したり、不適切な操作を防止することができる。