日々の破片

_ 緑の国のぴっぴたん

がーそ

_ 大黒柱

新しいアプリケーションを設計する際には、将来的に窒息死しやすいように設計するということだ。

っていうのを読むと、何で読んだか忘れたが昔の家は大黒柱と束石の間にくさびを入れるだかくさびを抜くかだかするとぱらぱらと家が自然と解体できるようにできていた（うそ臭いな）というようなことが想起される。

_ なんだかわからないが音が届いている

ヒカリというギタリスト兼ヴォーカル兼ソニックデザイナーがいる（いた？）んだが、あれは一体なんだったんだろう？ グーグルで検索してもオークションに出ているのが見えるだけでそれ以外に何もない。と思ったけどHIKARIで検索すりゃいいのか。まあ、でもカタカナにしておくか。

確かにグッド・バイ・スプートニックというCDが手元にあるし、Laoxだと思ったけどテクノがどうしたとか手書きポップも覚えている。ギターでテクノか、XTCみたいなのかな、とか思った(全然これは外れていた。XTCみたいなキンキーな要素は無い。すさまじく滑らかだ)記憶も残っている。髪は金色で宇宙服みたいなのを着ていてはっきり言ってかっこわるいルックスなのだが基調の青とスプートニクという言葉の選び方にツボを突かれてつい買ってしまったのであった。

聴いてみると歌いかたも僕が嫌いなギターをギツァーと発音するようなタイプなんだが、メロディーラインの作り方がうまいし、音の混ぜ方がきれいで、しかも言葉の選び方がうまいからとても心地よい(スプートニクとかライカとかの固有名詞によってもたらされるイメージってあるわけだ)。描かれているのはスペキュラティブなサイファイ(たとえば過去と未来を行ったり来たりしながら伝説を作っていく僕たち2人の出会いと別れの風景を描くJesusとか。わけわかんねぇな)で、軽薄といえばこれ以上ないほど軽薄なのだが、声と音の軽さとあいまってそれが——つまり心地よく響く。気に入っている。

前回聴いたのは2003/9/8らしいな。

_ 君はオレになる、オレはネコになる

こんだパンタか。（iPodでランダムに聴いているのであった）

_ 00（マネ）

シングルトンのビジネスロジックが山ほどあるとする。これはOOとしてどうなのよ？

コードってなんだろう？

コードは振る舞いを規定するものだ。あたりまえ。

コードはデータを持つか？ ——持つ。なぜならば、コードによって表現されているものには条件判断するためのデータがあり、ループするためのデータがあり、フロー制御するためのデータがある。それらのデータは外部から与えられる場合もあるが、コードに内在している場合もある。さらに言えばコードはそれ自体がデータだ。

コードは振る舞いを持ち独自のデータを持つ。すなわちオブジェクトの要件をある程度まで満たしている。しかしJavaの場合コードそのものにはアイデンティティが無い。このため、コードはそれだけではオブジェクトとして扱うことはできない。

言い換えると、Javaではコードはメソッドとして実現されているからそれ自体をインスタンスとして扱うことはできない。あるクラスのインスタンスのメソッドとしてはじめてインスタンス化される。コードそれ自体は本来的にスタティックであるがオブジェクトの多態性（交換可能性を満たすために必要）を実現するためには、インスタンスメソッドとして実装する必要がある。

まとめるとこのようにして実装されたコードにとってクラス#メソッドシグネチャがアイデンティティなのでスタティックメソッドでも良いのだが、さらにストラテジとして(多態に)扱えるようにするにはスタティックではなくインスタンスメソッドとしなければならない。また、可変なパラメータは外部からメソッド呼び出し時に与えることが可能なためシングルトンでよいことになる。

結局

ArrayList fooList = new ArrayList();
...
for (Foo f : fooList) {
    f.bar();
}
...

として扱うことができるFooのインスタンスはもちろんオブジェクトだということだ。

ここで

class Foo {
  public Foo() {
      ...
  }
  public void bar() {
      ...
  }
  ...
}

というようにFooが定義されているとOOで

interface Foo {
    void bar();
}
...
public FooImpl implements Foo {
    static FooImpl singleton = new FooImpl();
    private FooImpl() {...}
    public static Foo get() { return singleton; }
    public void bar() {
        ...
    }
    ...
}

ならOOではなく「シングルトンいくない」というようなことを言い出すとしたらそれは森を見ていないことになる。あるいはメソッドをオブジェクトとして扱うということが理解できていないかだ。

最終的にこういったシングルトンは

...
fooList.add(FooImpl1.get()); // FooImpl1のシングルトンの取得
fooList.add(FooImpl2.get()); // FooImpl2のシングルトンの取得
...

となり、個々のインスタンス毎に振る舞いとデータを持ったオブジェクトとして動くからだ。Javaの表現としてはメソッドをオブジェクトとして扱うためには単一のクラスとそこから生成される複数のインスタンスではなく、複数のクラスによるそれぞれのインスタンスとなるということである。

まとめるとビジネスロジックというのは、それ（ビジネスロジックを提供するメソッド。クラスではなく）自体が抽象度が高いオブジェクトである。そしてそれをJavaで実現するには、シングルトン(ロジカルにはそのクラスの複数のインスタンスを作成する意味はない。なぜならばこのクラスはメソッドを提供すること以外に意味がないからだ）が良く（同一アイデンティティのオブジェクトが複数生成されるのは気味悪いでしょという感覚的な理由と、生成コストがまったく無駄になるという現実的な意味の両方から）、外部から与えられるパラメータと必要に応じて処理中に利用される外部のエンティティにのみ影響を与えるのだからステートレスであるべきだということになる(実装の都合でインスタンス変数を複数の内部的なメソッドでの共有資源としてグローバルに扱う必要がゼロになるとは言わないが、意味的にはインスタンス変数は不要である。なぜならばコードそのものにデータがあるからだ)。