トップ «前の日記(2004-04-27) 最新 次の日記(2004-04-29)» 編集

日々の破片

著作一覧

2004-04-28

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

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

というようなことを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

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

本日のツッコミ(全2件) [ツッコミを入れる]
_ taedium (2004-04-28 08:51)

はじめまして。おおむね好意的な意見なのですね。artonさんのような方から見たら結構突っ込みどころ満載なのかなぁと思ってました。>分析・設計工程ではOOより在来手法に軍配

_ arton (2004-04-28 12:59)

うーん、あの文書はネガティブな方向から突っ込んでも余り得るものが無さそうなんですよね。とりあえず後編の図6は間違っているとは思うんですが、あそこに示された「機能」でクラスに分けていって経験を積む(あの文書の対象は構造化設計者/プログラマなので)ってのもありなのかなと。少なくてもあの分割であれば妙な実装継承も生まれなそうだし(テンプレート化はされるかも知れませんが、あの内容のテンプレートには危険が少なそう=継承が1段階で収まる、と書いていて思ったけど、こういう場合はテンプレートではなく細粒度のストラテジにするほうが良いのかも)、堅実なアプローチではないでしょうか。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ジェズイットを見習え