自社オブジェクトが請求書発行メソッドを実行すると,顧客オブジェクトにメッセージを送るよ。あなたは何を買ったの?あなたの支払い条件はどんなだった?
2012-05-06 23:52:52@twtshi 顧客が何を買った/自社が何を売った、というのは双方が参加する契約なので、どちらかのオブジェクトに包含させるのはマズいでしょ、とマジレスしてみるw
2012-05-06 23:56:29@twtshi 契約もオブジェクトにしていいと思います。ERモデルでも顧客と自社の間に契約エンティティを作るはず(契約情報の管理は普通売った側がやりますが、実際は中立の第三者がやっても良い)。オブジェクトは必ずしもアクターじゃなくていいと思います
2012-05-07 00:06:33@twtshi @nouvellelune 顧客と製品は、具象物(もの)です。一方、契約は抽象物(こと)です。これは、典型的な(もの)-(こと)-(もの)パターンですね。
2012-05-07 00:18:52@twtshi @nouvellelune twtshiさんは、具象物しかオブジェクトにできないと思われている(昔の私もそう思っていたときがあります)かもしれませんが、人間が認知した対象は、何だってオブジェクトになり得ますので、オブジェクト指向と言えると思います。
2012-05-07 00:20:27@twtshi @nouvellelune それがオブジェクト指向なのかどうかは見方や立場次第だと思いますが、契約オブジェクトと顧客の間の双方向的な関係に矛盾が起きないように誰かが実装しなければいけないところが、オブジェクト指向の「領域によっては」イマイチなところだと思います。
2012-05-07 00:24:40@foobardam @nouvellelune 認知したモノは具象であれ抽象であれ,データと手続きで表現できるとは思っています。問題はなぜデータと手続きを分離不可能にする必要があるのか?そこに疑問を感じています。
2012-05-07 00:25:57@twtshi @nouvellelune ちなみに、保険商品とか金融商品とかになってしまうと抽象物といわざるを得ない気がしますが、その辺は目をつぶってください(汗)。その場合でも、(もの)-(こと)-(もの)パターンと、私はみなしてますが。
2012-05-07 00:28:06@twtshi @pokarim @foobardam OOとして正しいかどうかより、設計したモデルを意図した通り表現できてナンボだと思います。原理主義な方には怒られるかもしれませんけど。
2012-05-07 00:28:50@nouvellelune @pokarim @foobardam データ指向であれば原理も応用も一致するのです。これでよいではありませんか?
2012-05-07 00:31:16@twtshi @foobardam これについては最近「(これからは)手続きもデータに含めればいいんじゃね」派になりつつあります
2012-05-07 00:34:36@twtshi @nouvellelune @pokarim 要求が満たされる限りデータ指向でもオブジェクト指向でも、どっちでもいいとは思います(汗)、個人的には。まあ、思うことはいろいろありますが。
2012-05-07 00:40:36@twtshi @foobardam 現在主流のオブジェクト指向言語って、データを(基本型にせよ構造体にせよ)値として見る性格が強いなあと。最近ちょっと関数型ブームで、手続きもファーストクラスオブジェクトとして扱える向きが出てきたと思います
2012-05-07 00:42:40@twtshi @nouvellelune @foobardam 自分は @twtshi さんの意見に近いと思います。ちなみにデータ指向をどんな意味で使われているか詳しく知りたいです。
2012-05-07 00:47:49@nouvellelune @foobardam @pokarim 私たちは「現在主流のオブジェクト指向を鵜呑みにしていない」という点が共通しているのではないでしょうか?
2012-05-07 00:48:29@nouvellelune @twtshi 自分も関数型には興味があります。Haskellをちょっとかじった程度ですが。業務分野にどれくらい応用できるのかなと。「関数プログラミングの楽しみ」を立ち読んで、金融商品への応用ができると知ってへーと思いました。
2012-05-07 00:52:30