日々の破片

_ ロシアの伝説モノを購入

ロシア・ピアニズム名盤選-4 ベートーヴェン:ピアノ・ソナタ第30/31/32番(ベデルニコフ(アナトリー))

ロシア・ピアニズム名盤選-9 スクリャービン:黒ミサ/プロコフィエフ:思考、他(ヴェデルニコフ(アナトリー))

ロシア・ピアニズム名盤選-17 伝説のスクリャービン・リサイタル(1960年2月2日)(ソフロニッキー(ウラジーミル))

最後のソフロニッキーってのも初耳（しかし女婿とか書いてあるな）だが、詩曲やアルバムリーフが収められているので一緒に購入。

_ 契約によるプログラミング

コンポーネント間の結合は契約が守られていることを前提とする。そのため、外部入力を扱うコンポーネントに関してはファイアウォールが必要になる。すべてのコンポーネントがファイアウォールを持たなければならないとしたら、その状態が既に不正。あんまりうまい要約じゃないな。

というようなことをakonさんという方が思い出させてくれたのだが、それについて言及されているのを発見してなんか妙な感じ。

UMLを使い始めた頃に購入したUML表記法ガイド（版が違うのかAmazonには見当たらない）の著者の方だったのか。

_ ！似てる

通りかかったd(タイポしてた、ごめんなさい)taediumさんの日記から。

分析・設計工程ではOOより在来手法に軍配

続

ふーむ、何だか似ているな。

3人のアミーゴって、何か勘違いしているだろうという突っ込みは別として、そんなに悪くはない。用語が異なるだけでストラテジパターンのことを言っているわけだし、実際にトップレベルではそのように作ることになるだろう。後は、ここからどういう実装が出てくるかだな。

機能に落ち着くのも妥当だろう(*)。属人性に対する指摘に対してここまできれいに開き直っているのは初めて見たが、この考えは好きだ。

で、最初のところから巨大クラスなのかと思うと、言語を問わず小さく分割すれば楽勝ということで、機能分割していく。それを「機能」と言わずに「責務」と呼べば、それはそれで正しい設計の出来上がりではある。

ただ、なんか本質的にオブジェクトという言葉の意味するものが違う感じがする。なんか妙に粗くて、それはオブジェクトじゃないだろう、という印象を受ける。多分、抽象化されていないからだな。具象クラスが5個くらいという感じだ。また、インスタンスが見えない点が違和感の正体かな。そういう意味では途中で設計が終了してしまっているようだ。

(*)機能はfunctionだが、procedureと対になるfunction（関数）とごっちゃにしているのかなと感じるものを時々見る。

追記：なんでこっちに書かずにコメントのほうに長々と書くのかな。

これは僕の経験値なので、もっと異なるうまいものがあるかも知れないけど、OLTPを前提とすると（この前提が共通点）、1トランザクション境界で「何をやるか」は在来分析だろうが、プロセス分析だろうが、DOAだろうが、同じ結論になるはず。ならなければ、そのトランザクション（ACID特性を満たす）はトランザクションでは無い。データの持ち方から変えてしまう場合は別だけど。後はどの方法が1番要求を吸い上げて正確に定義できるか、の問題だと思う。で、あの文書は在来手法でも平気ですよ、と言っているわけでそれは正しいのではないか、と思う。

そこから先の実装設計が、あちらはトップダウン、こちらはOOだから異なってくるのは当然だけど、そこに至るまでの上流工程については手法が流用できるという点に関しては同意できるというのが大きいかな。

もっとも図6をクラスダイアグラムとして渡されたら怒るとは思うけど、以前COBOLプログラマにJavaを覚えさせるにはどうすれば良いかを考えた時に、クラス＝機能の固まりとして、ストラテジで組ませるのが1番良さそうだと思ったのと大体同じような結論になっていたので、それもそんなもんだろうと納得してしまったし。

OOで実装設計ができる人は後編を読んでも、そういうアプローチもあるんですなぁという感想の他に得るものは無いでしょう。

さらに追記：うむ、見てもしょうが無いところは読み飛ばしていたようだ。前編の大半はクソ(=妙な誤解を刷り込む)ですな。むしろ、後編のほうが良いのか。後編は具体性が出てくるからヘンなところに落ち込んでいないからだろう。たとえば、アプリケーション層を1つの巨大なトランザクションスクリプトとして記述すれば、この著者の考えとフィットするだろうし。

ただ、実装が全然わかっていないってのは間違いない。平気でOOでのメッセージパッシングと実装レベルでのメソッド呼び出しを混同しているような記述もあるし。その一方で画面については何か勘違いしている（ASP.NETのサーバーコントロールをイメージしているのだと思う）が、Taglib作ったりすれば実際にはこの人の言っていることもあながち的外れではないかも。

_ 属人性ってのはやっぱり妙だよね。

さて上の従来技法でGOの人は、OOAから見れば属人性があるかも知れないが、それの何が悪い。属人性大いに結構、まさにデザイナー冥利に尽きると放言している。

うにゃ？

DOAの人は、OOAの人を属人性があるからだめだめですなぁ、と書いているのだが……

だからといってDOA>>>>>OOA>>>>>従来＝属人性 なんていう矢印が書けるわけはないだろう。というか上に書いたように、（あくまでもOLTPに限定すれば）最終的なトランザクション境界に属人性もへったくれもあるわけがない。あったら、トランザクションじゃないんだから。アトミシティが分析手法に依存して変化するわけないじゃないか。で、今、問題にされているのは業務システムへの適用であり、そこにトランザクション抜きで何か言ってもしょうがなかろう……かなぁ？ 実装寄りの見方過ぎるかも。そのキライはあるだろうな。しかし、そりゃしょうがないな。実装寄りで見ることが持ち味なんだから。別の見方は別の人が提供すれば良い。

#Transaction Oriented Approach = TOAというのを思いついた。

というわけで、そんなもん気にしてもしょうがなかろう。という意味では、開き直っている従来技法の勝ちでは無いかと思った次第。

_ F

……なるほど、そういう手もありましたね。