日々の破片

_ 代替ストリーム

伊原さんのメモ（追記：イの字を間違えてました。ごめんなさい）。

これいろいろ使い道があるはずなのだが、FDへコピーした瞬間に消失しちゃうという問題があったけど、今はFD使わないしな（でもFTPしたらやはり消えるだろう）。

#ゾーン情報の保存に使うというのは思わず納得。

・メタデータ

・構造化記憶

_ VB.NETの怖い話

// I like C#
public class Foo {
    protected int facility;
    public int Facility {
        get { return facility; }
    }
    ...
}

継承したクラスはフィールドを直接アクセスすることで設定可能。それ以外の利用者にはread onlyとして提供。

これは、VS2005 RCではVB.NETで継承するとエラーになる。

元々CTSには違反している（はず）これはCLS準拠違反(確認しました。多謝)。VB.NETはケースインセンシティブだ。したがって、これは矛盾しているので×。

VS2005 ベータまでは、VBからはプロパティしか見えていなかったのに。

では、どうするのが正解か？

(1) protected int m_facility;
(2) protected int _facility;
(3) protected int facility_;

どれも標準コーディング規約に違反している。

(4):
protected int facility;
public int getFacility() {
    return facility;
}

うむ。八方丸く収まった。

か？

しょせん、他人事とあまり深くは考えていなかったけど、結構、やっかいであるなぁ。コメントにはああ書いたけど、プロパティのセッタとゲッタでアクセス指定子を変えるなんて細かいことはできるんだっけ？ というのが1つと(.NET 2.0でできるようになったから−とLady.BUGさんのコメントではなっている−コンパイルエラーにするようにしたのかも)、それはそれとしてprotectedフィールドを利用したいという場合もあり得る点。

#継承関係があるクラスは、もう、どうしようもなく密結合しているんだから、それを前提として設計して良いと思っている。

たとえばpublicなセッタではレンジチェックするが、直接フィールドをさわることで、特権的な設定をサブクラスには許可するというような場合。

protected void setFacilityWithoutCheck(int x);
とか
protected void setFacilityCheatly(int x);
とか

あくまでも変なメソッドを用意しても良いかも知れないけど、外部インターフェイスで機能仕様そのものなpublicなメソッドと違って、あくまでも内部処理の延長なprotectedなアクセスであれば、そこまでムキになって変なバイパス用メソッドを用意する必要もなかろう。

つまり、問題は、フィールドに対して透過的なプロパティのあるべき名前は何か？ ということ（あるいはその逆）。

Javaだと何も考えずに

int facility; 
public void setFacility(int newFacility) {
    facility = newFacility;
}
public int getFacility() {
    return facility;
}

と書けるけど、C#/VB.Netではその手は利用できない/あまり利用しない方が良いのではないかということ。だからといってm_facilityとか_facilityとかfacility_とか nFacilityってのはいやなこった。

スロットとか？

public class Foo {
    protected static readonly FACILITY = 0;
    protected int[] attributes;
    ...
    public int Facility {
        get { return attributes[FACILITY]; }
    }
    ...
}

#これもダメじゃん……。enumにして名前空間を区切れば良いのか? Javaと違って数値だったはずだし。