西川です。
丁寧なお返事ありがとうございます。

> ・カプセル化はしない。オブジェクトとメソッド(関数)は分離して考える。
>    当然アクセス制御子などなく、全てpublic (^^;
> ・関数が主役。「オブジェクトにメソッドが従属する」のではなく、「オブジェ
> クトに関数を適用する」と考える。(ちょっと duck typing っぽい?)
> ・手続き型OOPにおける「継承」や「オーバーローディング」はない。代わりに
> 型クラスを利用する。
>
> という感じかな、と勝手に思っていたりするのですが。(めちゃめちゃ感覚的な
> コメントですいません)

うーん、やっぱりそうなりますよねえ、

> -- 図形
> class Draw a where
>   move :: Int -> Int -> a -> a  -- x,y座標を指定された分だけ移動
>
> -- 点
> data Point = Pt { x, y :: Int }
>
> instance Draw Point where
>   move dx dy Pt {x=a, y=b} = Pt (a+dx) (b+dy)
>
> instance Show Point where
>   show Pt {x=a, y=b} = "Pt{x="++(show a)++", y="++(show b)++"}"
> ------------------------------
>

そして、やっぱり上記のようになり、
そうすると、継承ライクなことができないと図形の種類を増やすたびに
Drawのメソッドを全て実装&管理する必要があるんですよねえ。

なんかの文書に関数型言語のclass概念は、
図形の種類を増やすような変更に対しては弱いが、
その代わりXXとトレードオフが書いてあったような気がするんですが、
XXが思い出せないかつ実感できないのが残念です。

なので最近は依存性は無視してとりあえず組んで、
後からclass化したくなったらする、というやり方に変えてます(前はclassを先に考
えていた)
なにか見当はずれなやり方をしている感はぬぐえないですが。

毎回あいまいかつ感覚的なコメントで申し訳ないです。


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.8/114 - Release Date: 2005/09/28



--
ML: haskell-jp / quickml.com
使い方: http://QuickML.com/