日々の破片

_ TableAdapter

TableAdapterって、ADO.NETじゃないのか……（System.Dataネームスペースじゃないし）

でも下層には、SqlDataAdapterがいるから、ADO.NETっていっても間違いじゃないよね？ と、誰とも無く同意を求めてみたり。

_ なんで？

匿名メソッドはやめれ

もしかして、「アノニマスメソッド」と呼べ、という意味だったりするわけはないだろうから、文字通り、使うな方面の意味なんだろうけど（追記：ではなく、無名メソッドじゃなきゃおかしいだろう、ということでした。うむ、それはそうですね。でも待てよ、と書いた先からシステム付与のとんでもない本名を匿名化したもの、と解釈してみるとか。と考えてみると、delegateというキーワードを匿名に利用している、つまり「〜というメソッドを提供するdelegateさん（仮名）」という感じなのではないかな、と。実際問題として関数名としてdelegateと書いているわけだし）。

#もちろん、まずい使い方はいくらでも考え付くけど、悪用は善用に転化できるけど、使われなければそれまでだ。

例）カプセル化

class Foo {
    int counterValue;
    public int Counter {
        get { return counterValue; }
    }
    public void bar() {
        Baz baz = new Baz();
        baz.doSomethingWithFoo(this);
    }
}
class Baz {
    public void doSomethingWithFoo(Foo foo) {
        ...
        if (foo.Counter == 0) {
            ...
        }
        ...
    }
}

に対して

と、ここまで書いて、この例だと何も匿名メソッドを使うまでも無く、次の書き方で良いことに気づいたので、この例はやめた。

class Foo {
    int counterValue;
    public bool IsFirstVisit {
        get { return counterValue == 0; }
    }
    public void bar() {
        Baz baz = new Baz();
        baz.doSomethingWithFoo(this);
    }
}
class Baz {
    public void doSomethingWithFoo(Foo foo) {
        ...
        if (foo.IsFirstVist) {
            ...
        }
        ...
    }
}

で、別の例を考え付くまで、一回休み（というか、普通にイベントハンドラを書けば良いのだが）。

#おれはTell Don't Ask原理主義者だから、Tellのネタを与える方向は常にOK

とりあえず最初の一歩としては、外部へは常に振る舞いのみを与えて、属性は（プロパティのような仮想化されたものですら、属性そのものとしては）見せないってこと。

でも、さらに考えると、Fooのインスタンスに対しての最初の呼び出しであれば、何をするか、というのはFooの所有ではないかとか、と思ったけど上の例は、Fooに連動して動作するBazなので、クリーンなFooを与えられたときのBaz自身の動作がifのブロックの中に入るのでこれで良い。次のように書くのはさすがにやり過ぎだろう。

class Foo {
    int counterValue;
    public bool InitializeBaz(Baz baz) {
        if (counterValue == 0) {
            baz.Initialize();
        }
    }
    public void bar() {
        Baz baz = new Baz();
        baz.doSomethingWithFoo(this);
    }
}
class Baz {
    public void doSomethingWithFoo(Foo foo) {
        ...
        foo.InitializeBaz(this);
        ...
    }
    public void Initialize() {
        ...
    }
}

でも待てよ。こっちのほうがチャーミングだな。こっちのほうが良さそうだ。（条件判断がメソッド全体を覆うものに変形できているというのが、チャーミングな理由）

追記：っていうか、アトミシティ原則（っていう名前じゃなかったかも。ステートの問い合わせを処理と分離するな）からもこっちが良いというか、場合によってはこっちでなければならない。

_ fact

「保守不能なコードを書く大原則とは 可能な限り多くの場所において可能な限り多くの方法で 事実を明確にすることである」

DRYの反対。そこら中で繰り返せ（しかも複数の方法/アスペクトで）、ってことでは。