日々の破片

_ ゴッホ

昨日行った。コンテキスト（原風景とはすごい訳だな）と関連した作品。

1888〜1890までにとにかく画を書きまくったってことに感心する。でっかな画をとにかくがんがん描いているのだな。

点描からジャポネスクを通じて（パリで描いた本のとこで和紙に影響されたと説明された筋が出てくるのが初出なのかな）例のうねうねしたものが出てきて、スタイルが確立されていくということなのかな。

苦悩するおっさんの書き直しがすごく良い感じだった。色が青っぽくなるとこ。ズボンの皺が横から縦に変化。書き直しってのは重要だな。

ミレーの模写が妙に灰色で不思議だったがこれは後でプログラムを見たら雪景色と勘違いしてたらしいとか書いてあってちょっとがっかり。死の灰かと思ったよ。そんなわけないけど。

初めて年譜をまともに見たが、なんか若い頃のエピソードとか宮沢賢治みたいだな、と思ったり。

_ POJO

同時並行でいろんな立場のいろんな考え方の人たちが、それでもなんとなく同じような方向を向いてうまいやり方を考えている、という楽しい状況に今いるのだ、という前提で。

したがっていろんな言葉がいろんな意味で使われて混乱を招く部分もあるように思う。

POJOとはなんだ？ 特別なコンテナが不要ということだ。特別なコンテナというのは、そのコンテナに入れるためには例えばEJBObjectインターフェイスを実装しなければならないとか、抽象クラスでなければならない、とかの制約をコンポーネントに対して要求するコンテナのことだ。ほとんどの場合、それは現時点のEJBコンテナを意味している。それに対して特別ではないコンテナというものが対置される。特別ではないということは、特殊なマーカー（アノテーションだったりインターフェイスだったり）を持たないコンポーネントを格納できるということで、それは軽量コンテナ（この方向だけでは必ずしもDIが必要かどうかは無関係である）と呼ばれるものだ。

POJOは、特殊なインターフェイスを持たず（非機能要件を基本的には持つ必要がなく）、極めて具象的な、つまりTestUnit派生クラスがnewで作ることが可能なオブジェクトのことだ。

最後の点がとても重要で、普通に作りながらユニットテストができる、あるいは検証しながら作ることができる。テストファーストとかテスト駆動開発とこの方法論を呼び、トライ＆エラー開発の過程をソースで記録化しようという試みでもある（そればかりじゃない。というかそれ「だけ」が目的だったらちょっと困るな）。

O/Rマッピングしたオブジェクトやそれに毛を生やしたDAOも、もちろんPOJO（特別なマーカーを持たない具象クラス）であるが、こっちはテストしながら開発したりしない。というかそういう開発を不要とさせるように考える。自動生成させるのが方向性である。その意味ではテストを同様に考えないCMPの直接の置き換えでもある。

ここまでで、2種類のPOJOが出てきた。テストファーストで開発する（開発可能な）POJOと、O/Rマッピングした（人間がテストファーストで開発するのではなく、機械が生成する）POJOだ。ここでまた意味合いが微妙にぶれるが話を単純にするために後者をDAOと呼んで前者のPOJOと区別することにする。

これはEJBの2種類のオブジェクト、セッションビーンとエンティティビーンに大体において対応する。

「大体」なのは、EJB3未満のEJBワールドとPOJOワールドでは方向が異なるからだ。EJB3未満のEJBワールドではCMPにビジネスメソッドを追加する方向で進んだのに対して、POJOワールドではDAOからは振る舞いを除外してPOJOに持たせる方向に進んでいるからだ。

ただし、別のPOJOワールドもある。データアクセスをそれ専用の特殊なクラス（テーブルモジュールやアクティブレコード。以下ひとからげにDTU――データアクセスユーティリティと今こしらえた造語で呼ぶことにする）に持たせ、その特殊なクラスに対する操作の集合を持たせたDAOを別に作成する方法論である（だが上で書いたPOJOワールドと区別しにくいのでDAOと言わずにBDO――ビジネスデータオブジェクトとでも呼ぶべきかも）。この方法論は良い面、悪い面あるが、SQLを記述することの開発者の慣れ具合に依存するんじゃなかろうか。僕はO/Rマッピングよりこちらが好きだし、極端に言えば、（Javaの場合では）JDBCそのものを「専用の特殊なクラス」と見なしてしまえば良いのではないかと考えるが、それはこの流派の亜種だろう。ここではPOJO―BDO―DTUという構造となる。POJOとBDOを同じクラスにしてしまうと何のことはなく普通の（層化させない）プログラムとなる。（メモ：BDSという用語があったがなの略なのか思い出せない。）

ここまでで、EJBワールド（SB―CMP。ただしCMPがビジネスメソッドを持つEJB2ワールドとCMPがビジネスメソッドを持てない初期EJBワールドの2種類がある。初期EJBワールドではクライアントが直接CMPを操作するのは実行時のオーバーヘッドが高くなり過ぎるのでSBをファサードとして置く必要があり、それによって操作するSB、操作されるCMPという配置がベストプラクティスとなり、結果的にトランザクションスクリプトパターンが促進された面があるように思う。EJB2でもその配備はベストプラクティスとして踏襲されたために、ステートレスセッションビーンの比重が高くなったのではないかな。セッションビーンの元の発想での主流派はステートフルによる特殊処理だけだったように感じるが、このへんは相当あいまい。いろいろな設計手法を取れるように3種類のビーンが用意されているわけだから、人によりけりだろう）、POJOワールド（POJO―DAO）、別のPOJOワールド（POJO―BDO―DTU）の3種類が出てきた。

出てきたが、これらにはすべてクライアントがいるという点が重要でもある。ここで呼ぶクライアントはWebシステムでのブラウザーのことではなく、Webサーバー上のアプリケーションである。上でPOJO―DAOとか書いていたのはすべて、アプリケーションサーバー上のアプリケーションだからだ。

ただし、このアプリケーションサーバーというのがくせもので、必ずしもWebサーバーと異なるネットワーク上のノードである必要はないし、それどころかWebアプリケーションと異なるJVM上に存在する必要すらない。

そういった物理的な分離とは無関係に論理的には異なる層であるため、層間の通信が必要となる。異なるアプリケーション同士が通信する場合には、通信相手の探索、発見、接続、データ送受信が必要となる。

コンテナはここでは層間通信のためのミドルウェアとして機能する。

いかなるシステムであっても通信には通信先の名称が必要となる。また、1つのアプリケーションが対話する相手先は少ないほど良い。

DIコンテナが解決するのは、この層間通信の探索、発見、接続の部分で、それはEJBコンテナと変わらない。ただし、層の向こうでも同様に探索、発見、接続が必要となると見なし、すべてを繋げた上でクライアントに対話相手を与えるところがとてもおもしろい。

この結果、クライアントは直接の対話相手の名前（もちろんデータ転送に利用するメソッドシグネチャを知っているのは当然だが）だけを知っていれば良いことになる。

ここで、クライアントが複数のアプリケーションを操作することも可能であるが、それはクライアントが知るべきことが増えてしまう。

最初のEJBでは層間通信の実際に発生するオーバーヘッドを避けるためにベストプラクティスとなったファサードパターンがここでは、クライアントとサーバー間の通信を単純化し、サーバー側処理の複雑さを隠すための、つまり元々のパターン名が意味する通りのファサードとして、意味を持つ。

このファサードはDAOを操作し、必要であればさらに別のオブジェクトを呼び出してクライアントからの要求に応える。

単純なマスターメンテナンスは知らないけれど、クライアントから与えられたデータに対して検証、加工、追加が必要ならばそれを実行する。検証はともかく、加工や追加はファサードの仕事ではなく、それを行うためのビジネスの仕事だ。

ファサードクラスが、ファサードメソッド（通信のポイント）だけでなく内部にビジネスメソッドも実装するか、それともファサードメソッドをトランザクションスクリプトとして実装していろいろDAOを操作するか、それとも単に（論理的な）アプリケーションサーバー内で他のビジネスメソッドを実装したビジネスオブジェクト（DAOそのものかも知れないし、別の普通のオブジェクトかも知れないし、ユーティリティクラスからも知れないし、それは設計に依存していろいろなんでも良い）を呼び出すだけのデリゲータとして振舞うのか（呼ばれるビジネスオブジェクトをnewで作る必要はなくて、ここでもDIコンテナが役に立つ可能性が高い）、それはアプリケーションサーバー内の設計に依存する。いずれにしても、Web上の（物理的には同一JVMかも知れないが、それは全然関係ない）アプリケーション（Strutsを使うのであればActionに相当する）の知ったことではない。

えーと、長々書いたが、POJOと叫ぶとき、CMPうぜーの意味なのか、テストファーストで開発したいの意味なのか、によって変わってきて、後者の場合、ファサードがビジネスロジックを持つかどうかは関係なく、ビジネスロジックを持てばテスト駆動で開発する対象となる、持たなくてもフロー制御をするのであればやはりテスト駆動で開発するかも知れない（与えられたデータによってフローが変わるわけなので検証すべきでしょう）、ということが言いたいのである。この場合、セッションビーンがPOJOとして記述できえるということがCMPの運命よりはるかに重要なのだ。

#書いていてつくづく思ったが、おれは実装技術、実装設計が好きなんだな。

#最初賢いデータは必要なのかへのトラックバックとして記述していたが、例によって途中でぶれまくったのでやめた。

_ メモ

平たいデータ（レコード）を立体的に処理する。

立体とは何か？

立体とは複数の次元からの操作のことだ。

オブジェクトは象を撫でている4人の盲人。

データは象。

レガシーシステムは象だ。

象に対して複数のビューを与える。

トランザクションのAを守ることで、群盲が象を触っても大丈夫なように設計する。

ファサードが4人の子分に命令する。触れ。触った結果をまとめて1つにする。そしてコミットする。