2008年08月24日

インターフェース設計における、要素指向と関係指向

オブジェクト指向設計においては、独立性の高いプログラム部品(オブジェクト)の集合としてシステムを構成します。そのため、システム内部の部品と部品の間の役割分担を適切に設計することが大変重要です。このような役割分担は多くの場合「インターフェース」によって表現されます。

オブジェクト間のインターフェースを設計する上でのポイントのひとつは、「相手に対して必要以上のことを期待しない」ということです。
インターフェースする以上、相手に何らかの期待を持つことは必然です。しかし期待に応えるにはコストがかかります。必要以上のことを期待するとその期待が相手方の負担となります。ですからインターフェースは必要最小限の期待を表現するよう設計するのが適切だというわけです。今回は、そうした観点から、ツリーのように、複数の要素からなり要素と要素の間に関係がある構造[*1]を表すインターフェースについて、設計アプローチを検討してみます。

(なお、末尾にサンプルソースコードの圧縮ファイルをつけています)

[*1] ツリーの場合、要素=ツリーのノード(枝の分かれ目)、要素間の関係=ノード間の親子関係となります。


続きを読む
posted by keis at 14:08| Comment(0) | TrackBack(0) | プログラミング | このブログの読者になる | 更新情報をチェックする

2007年07月30日

サルでもわかるIOモナドB−アクションはモナドの夢を見るか

 少し間が空いてしました。前回はアクション(IO操作の仕様書)とモナドが何とかつながったところで終わりました。 今回は両者の関係をもう少し緻密に検討してみましょう。


続きを読む
posted by keis at 00:22| Comment(1) | TrackBack(1) | プログラミング | このブログの読者になる | 更新情報をチェックする

2007年07月13日

サルでもわかるIOモナドA−逐次実行とモナドの登場

 前回は、「アクション」のご説明をしました。 Haskellのプログラムは、自分自身がIO操作をするかわりに、IO操作の指示書である「アクション」を返し、 処理系にIO操作という「汚れ仕事」を押し付けているのでしたね。だからHaskellプログラムは「副作用」という罪に染まらず、 ピュアでいられるのでした(考えようによっては偽善者ですね)。

 しかし、その説明の中ではモナドがほとんど登場しませんでしたね。 僕は、「モナドとアクションの微妙な関係が出てくるのは、IO操作の実行順序を確実に指定できるアクションを作ろうとした時なのです」 とか、苦し紛れの言い訳じみたことを言って、皆さんの気を持たせただけでした。

 さてこの道は本当に、モナドに通じているのでしょうか。

 それでは、続きをどうぞ。


続きを読む
posted by keis at 20:59| Comment(0) | TrackBack(1) | プログラミング | このブログの読者になる | 更新情報をチェックする

2007年07月08日

サルでもわかるIOモナド@−副作用の除去

 このところ、仕事の手が空いたときに、Haskell というプログラム言語を勉強しています。Haskellは僕がふだん使っているJavaなどとはかなり趣きが異なるので、 考えさせられる点が多く、気分転換にはぴったりです。

 とはいえ、最初はさっぱり理解できない点もありました。「IOモナド」です。 Web上の色々な資料を読んでいるうちにだいたいのところは理解できたのですが、そうなってみると、今度は、 最初に読んだ何冊かの入門書やWeb記事でのIOモナドの説明の仕方が気になってきました。
こうした記事は、素人向けに易しくIOモナドを説明しようとして、その結果、かえって読者を煙に巻いてしまっている面があるんじゃないかと思います。

 IOモナドは、Haskell の鬼門とか呼ばれているようですが、わかってみるとさほど難しいものではありません。であれば、僕自身がきわめて素人くさくIOモナドを理解した仕方をご説明するのも、どなたかの役に立つかもしれません。

 というわけで、この記事です。


続きを読む
posted by keis at 11:25| Comment(1) | TrackBack(1) | プログラミング | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。