@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

オブジェクト指向設計はトップダウン的アプローチ(ドメインモデルからクラス設計),ボトムアップ的アプロー

投票結果総投票数:50
トップダウン的アプローチ(ドメインモデルからクラス設計) 29 58.00%
ボトムアップ的アプローチ(処理手順からクラス設 21 42.00%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
やまろう
常連さん
会議室デビュー日: 2003/10/13
投稿数: 35
お住まい・勤務地: 埼玉・東京
投稿日時: 2004-12-20 22:01
引用:

objectさんの書き込み (2004-12-18 12:29) より:

以上の分析が間違いなければ、少なくとも
「クラス設計」が「外延」
且つ
「クラス設計」が「内包」
となり、
「両者で全く矛盾した主張をしている」
という事にはなりませんか?
#表現がとても曖昧なので、解釈を間違っている可能性は十分にあります。


そういうことですか、なるほど。
物事が「外延」になるか「内包」になるか、それは解釈の仕方、場面、おかれる立場で変わると思います。

ですから、言い方を借りて議題を言い直すと

オブジェクト指向設計はその過程で「クラス設計」が「外延」となるやり方(トップダウン)か、「クラス設計」が「内包」となるやり方(ボトムアップ)をとりますか?

ってことです。矛盾していないと思います。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-12-21 13:14
objectです。

>やまろうさん
先ず、私が、
「やまろうさんが仰りたい事を否定しているのでは無い」
という事は、理解して下さい。

逆に、
「今の表現では仰りたい事が分からない」
から、出来たら別の表現をして頂きたかった訳です。

やまろうさんが仰ってるのは、要するに
1)要求分析から、クラスを設計
2)仕様書から、クラスを設計
という事です。
1)と2)のどういう部分が、どの様な解釈で「トップダウン・ボトムアップ」の関係になってくるのでしょうか?

私は「トップ・ボトム」をベースに「やまろう」さんの表現を少し強引に解釈しました。
特に強引だったのは、「ボトム」の
・「仕様書」が「外延」
・「仕様書」が「ドメイン空間」
の部分です。

従来の「仕様書」は
本来は「ドメイン」に関する内容を、「モデリング」無しで
「ソフトウエア空間」で「直接的に参照すべく、個人ベース」で表現された文章
だと思います。


それで、「トップ・ボトム」に関する部分は無視してお伺いしますけど、

やまろうさんが仰りたいのは、
・「ドメイン」をベースに「クラス設計」を行う -> 「ドメイン分析」による「オブジェクト指向プログラミング」
・「要求仕様」をベースに「クラス設計」を行う -> 「従来の要求仕様」による「オブジェクト指向プログラミング」
という事ではないのでしょうか?
#「クラス設計」経た「プログラミング」は、基本的には「トップダウン」だと私は思います。
やまろう
常連さん
会議室デビュー日: 2003/10/13
投稿数: 35
お住まい・勤務地: 埼玉・東京
投稿日時: 2004-12-21 17:18
引用:

objectさんの書き込み (2004-12-21 13:14) より:
やまろうさんが仰ってるのは、要するに
1)要求分析から、クラスを設計
2)仕様書から、クラスを設計
という事です。
1)と2)のどういう部分が、どの様な解釈で「トップダウン・ボトムアップ」の関係になってくるのでしょうか?


1)要求分析から、クラスを設計だと、企業のドメインを書く、それは全体を表すもの、だからトップダウン。
2)仕様書から、クラスを設計だと、コードの重複をコンポジションや継承で共通化する、そこで部分的な観点で出来上がるクラスがある、だからボトムアップ。
半分後付です(>_<)

ほんと、トップダウン、ボトムアップって言葉を選んだために誤解を招いてしまったようですみません。初めに定義をしておいたのですが、言葉のイメージって強いんですね。

上流工程からクラス設計に落としてくからトップダウン(上から落とす)、下流工程でクラス設計を作り上げてくからボトムアップ(下から組み立てる)って感じで定義したんですよ。本来の意味とニュアンスが違いますもんね。

引用:

objectさんの書き込み (2004-12-21 13:14) より:
やまろうさんが仰りたいのは、
・「ドメイン」をベースに「クラス設計」を行う -> 「ドメイン分析」による「オブジェクト指向プログラミング」
・「要求仕様」をベースに「クラス設計」を行う -> 「従来の要求仕様」による「オブジェクト指向プログラミング」
という事ではないのでしょうか?
#「クラス設計」経た「プログラミング」は、基本的には「トップダウン」だと私は思います。


仰るとおりです。「トップダウン」の本来の意味にこだわらないで下さい〜(T^T)誰かが言ってたけどおれ用語ですみませんがこのスレッドでは定義した意味でお願いしますぅ〜m(._.)m ペコッ

[ メッセージ編集済み 編集者: やまろう 編集日時 2004-12-21 18:09 ]
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-12-22 00:14
引用:

objectさんの書き込み (2004-12-18 13:52) より:


了解です。てっきり私宛の間接的な示唆かと思い確認致しましたが、
未記入さんの指摘どおり、ちょっと見苦しい感情的な表現でした。

申し訳ございません。

引用:

コブラさんの書き込み (2004-12-20 16:41) より:
そこまで打ち込む時間があったら「仕事せんかっ!!」となりかねまへんので・・・>未記入氏


いた!痛たたた。流れダマがあたった感じです。

# ツマラン突っ込みですみませんが、「入」では無く「人」だそうです。未記人さん

引用:

私の場合、書き込みは腰溜めで、文章は考えても短時間です。
無責任で申し訳無いですが、あまり推敲や見直ししない。
せやから、かなり時間が経った後で「編集」のパターンも多い。


見直しして、この程度の文書の私は、、トホホ。

議論で要求する事は人それぞれって事なんですね。
私は議論の勝敗にさほどの意義(ま〜、そりゃカチンと来る事はある。)を感じず、
自分にとっての知る事の有益性を重んじるので、それによって議論の仕方の違いは出るんでしょうね。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-12-22 12:45
objectです。

>やまろうさん
>ほんと、トップダウン、ボトムアップって言葉を選んだために誤解を招いてしまったようですみません。
>初めに定義をしておいたのですが、言葉のイメージって強いんですね。
言葉は、本当に重要だと私も思います。
自分自身との対話に於いても、言葉に依存している部分は、意外と大きいと思います。
ですから、自分以外の他人との相互理解となると、言葉の重要性は計り知れないと思います。
言葉に使われるのでは無く、自分の意思の下で使う。
これが重要だと私は思います。
#また、言葉の形式が持つ意味も大きいですね。
#何しろ、意味とは関係無く、その真偽が決まる場合がある訳ですから。

>仰るとおりです。「トップダウン」の本来の意味にこだわらないで下さい〜(T^T)誰かが言ってたけど
>おれ用語ですみませんがこのスレッドでは定義した意味でお願いしますぅ〜m(._.)m ペコッ
はい、分かりました。

以上の前提で、私の意見を少し書きます。
私は
「オブジェクト指向」=「ドメイン指向」
だと思っています。

「従来の要求仕様」に関わるプロセスを「暗算」とすると
「ドメイン分析」のプロセスは、「筆算」に相当するのではないでしょうか?
恐らく、
「筆算」は、何時の日か「代数」に発展する
と私は思っています。
しかし、
「暗算はいつまで経っても、暗算でしかない」
のではないでしょうか?

>はにまるさん
理解して頂けて、良かったです。
私の文章の硬さを冷たさとお感じになる事があると思います。
でも、それは手段として使っているのであって、決して目的とはしていません。
今後共、宜しくお願いします。
やまろう
常連さん
会議室デビュー日: 2003/10/13
投稿数: 35
お住まい・勤務地: 埼玉・東京
投稿日時: 2004-12-22 15:54
引用:

objectさんの書き込み (2004-12-22 12:45) より:
私は
「オブジェクト指向」=「ドメイン指向」
だと思っています。

「従来の要求仕様」に関わるプロセスを「暗算」とすると
「ドメイン分析」のプロセスは、「筆算」に相当するのではないでしょうか?
恐らく、
「筆算」は、何時の日か「代数」に発展する
と私は思っています。
しかし、
「暗算はいつまで経っても、暗算でしかない」
のではないでしょうか?


なるほど、「ドメイン分析」のプロセスは「オブジェクト指向の考え方を活用して仕様を導きだしている」ということですね。仕様を導き出す手段としてオブジェクト指向を活用しているというわけですね。

OOPで実装する観点からいうと「良いコード(重複がなく、簡潔明瞭で保守性が高い)を書くために使う」というのがありますよね。手続き型言語ではの呼び出される側のコードを共通化しますが、OOPではそれに加えて呼び出す側のコードを共通化出来るという。僕は実装の観点しかありませんでした。だから、せっかくukさんが薦めてくれた「アナリシスパターン」や「実践CRCカード」を本屋で見てみても、

「読む気しねぇ〜(>_<)」

ってことになってしまいました(×_×;)ukさん、m(_ _)mゴメン
「ドメイン指向」の問題意識を高めねば!!と思いました。


[ メッセージ編集済み 編集者: やまろう 編集日時 2005-01-13 14:03 ]
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-12-24 13:02
引用:

やまろうさんの書き込み (2004-12-22 15:54) より:
OOPで実装する観点からいうと「良いコード(重複がなく、簡潔明瞭で保守性が高い)を書くために使う」というのがありますよね。


「誰が見てもわかりやすく」するためには、わかりやすくメタファを使用する必要があります。
デザインパターンもメタファの一つですが、ビジネスロジックをわかりやすくするためには
ビジネスに関係したメタファを使用することが望ましいのです。

引用:

だから、せっかくukさんが薦めてくれた「アナリシスパターン」や「実践CRCカード」を本屋で見てみても、
「読む気しねぇ〜(>_<)」
ってことになってしまいました(×_×;)ukさん、m(_ _)mゴメン


「アナリシスパターン」は難解で有名な本ですし、体系的でも網羅的でもないので最初に読む
本としてはお勧めしません。「実践CRCカード」の方はもっと気楽に読めると思いますが。

引用:

「ドメイン指向」の問題意識を高めねば!!と思いました。


「より価値の高いもの」もっと端的に言うと「もっと役に立つもの」を作ろうと思うと、実は
「どう作るか」よりも「何を作るか」の方が重要である、ということに気づくと思います。
そのときに「何を作るか」をどうやったらうまく決められるのか、と考えるようになったら、
ドメイン分析などの勉強を始めたらいいのではないかと思います。

いや、本当は私も設計とコーディングだけやってた方が楽しいんですけどね。
guion
常連さん
会議室デビュー日: 2004/12/24
投稿数: 30
投稿日時: 2004-12-25 20:11
引用:

OOPで実装する観点からいうと「良いコード(重複がなく、簡潔明瞭で保守性が高い)を書くために使う」というのがありますよね。



お邪魔します。

私も実装から見るのは好きですが、
実装すなわちコードとは限らない、というか、
そういう感覚で居ます。

自分はOOP好きなんですが、
OOPから見ると、コード…狭義の「実行される処理」…の重要度は二番目であり、
オブジェクト(やそれを規定するクラス)をどう作るか?っていう視点を
最初に持ってくるかんじです。

んー。トップかボトムかという視点と、
手続き型かOOかっていう視点とは、
直交だというイメージを持っています。

クラスや、クラス間の関連を、どうするかなー?って考えながら
考えたとおりにclassの枠組みのソースを書いていく、ってのが、
私なりの、「OOPっぽい、かつ実装寄りの、作り方」ですね。

で、そういう意味だと、アナパタとかも結構すんなり入れます。
上流寄りだから毛嫌いする、とかいう感覚も特に無いです。

ただ、アナパタは、書いてること(と書き方?)自体が難しくて
挫折しました(^^;。
何年も昔に和訳されたばっかりの頃飛び付きましたが、あえなくリタイヤ…
#あの頃はたしかUMLもまだ普及してなかったよね…

あと、メタファとかについても気になっています。
何が気になるかというと、
データ類の構造についてのメタファと、
振る舞いについてのメタファとが有る
(他にも色々あるのかも知れませんが取り合えず思いつきません)
んだろうと思います。
で、それに対応して、オブジェクト指向寄りのメタファも有れば、
手続き型からすんなり行けるメタファも有る、のだと思います。
で、まあ実際には、その両方を必要に応じて使い分けるんでしょうね。

スキルアップ/キャリアアップ(JOB@IT)