WR blog

構造化分析・プログラミング – ひがやすを blog

先に取り上げた、いがぴょんさんのエントリに対する ひがさんのコメントと、実装スタンス。

> OCPを守るために、くーすでどうしているかというとロジック(メソッド)は常にインターフェース経由で呼び出すようにします。あるロジックが別のロジックを呼び出す必要があった場合、DIコンテナによってロジックオブジェクトをDIしてもらい、それを利用するのです。

文章だけだと、やっぱりわからない部分が残る。しょうがない。

ただ、外から見ていると、なんとなく、立ち位置や価値観が違うところもあれば、単に表現上の問題でミスマッチがおきているところもあるように感じられる。 もちろん、これは単なる勘だけど。

### 感謝したい。 あらためて思うのだけど、こういうやり取りを直接読めること、そのものに感謝したい。

少し前は、第一線で活躍する一流デベロッパの意見を聞くことは非常にむずかしかった。 イマイチ信用してよいのかどうかわからない専業ライターさんと、何をたくらんでいるのかわからないエバンジェリストもしくは社長さんぐらいからしか、情報を得ることができなかった。

われわれは幸せな時代にすんでいる。 第一線で活躍する一流デベロッパのソースを読み、開発に対する考えを聞くことができるのだから。

2005/05/09 日記: オブジェクト指向レス開発

> 「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングがなされていないと手詰まりになります。「失敗オブジェクト指向」にしてしまわない近道の一つは、「構造化」の導入であると私は確信しています。というか、そもそもオブジェクト指向においても「構造化」にまつわる概念は存在しているのですが、多くの文献や記事においては 「構造化手法」の側面は かなり薄っぺらくしか扱われていないように考えます。その実例として Java言語のパッケージ構造についての現実的な利用についての話題を ほとんど書籍や雑誌で見かけないことから現れています。(現実的な現場の多くでは適切に運用されているのですけれども…) > > そして もう一つ重要なポイントなのですが、オブジェクト指向やデザインパターンのなかの多くの技は「構造化」という観点からは リレーショナルデータベースにおける「逆正規化」に相当しているのだという点です。残念なことに、多くの人に、この点もあまり理解されていません。オブジェクト指向は ほんとうに注意深く導入しない限り、プログラムの理解を妨げ、試験をしづらくし、生産性を下げ、保守性を下げます。オブジェクト指向は間違いなく「逆正規化」に相当します。そもそもオブジェクト指向やデザインパターン適用について、これらが生産性や保守性に与える効果についての統計的な情報にほとんど出会わないことについても、これは悲しい現実であると受け止めています。

興味深い。いがぴょんさんの考え方・設計、（フレームワークより上位のアプリケーションレイヤにおいて）デザインパターンなどを駆使したいわゆるオブジェクト小僧の設計のどちらが100%間違っていて、どちらが100%正しいという問題ではないと理解している。どちらも、厳密な意味での論理性をもたない。

ただ、いがぴょんさんのおっしゃられていることは、皮膚感覚として理解できるし、 概念的なレベルでは納得ができる。 （段階的詳細化の考えに裏付けれた意味での）構造化技法は、数ある構造化の仕組みの中でもっともシンプルでパワフルである。ツリー構造＋概要→詳細方向の段階的詳細化。 （継承、包含、利用、抽象型などの考えに裏付けられた意味での）構造化技法であるオブジェクト指向技法は、パワフルであるがシンプルではない。複雑である。

シンプルなパラダイムは表現力が少なく、すくなからず制約を持つが、形式的に扱いやすい。人間によって理解がしやすく、文脈的な影響も排除できる。 リレーショナルモデルも同様。

### 逆正規化

個人的には、

> オブジェクト指向は間違いなく「逆正規化」に相当します。

の論理的な説明が聞きたいなぁ。

ところで、いがぴょんさんの日記って、トラックバック打てるのかなぁ？