設計：「オブジェクト指向」で設計する事について

参照元記事 | 同じ記事を参照しているスレッド一覧

1|2|3 次のページへ»

投稿者

投稿内容

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-03-19 13:44

はにまるです。

まだ「オブジェクト指向」で設計する事は御勉強中なのですが、
参照の記事を読み、霧が晴れた気がしました。
# 今まで、オブジェクト指向言語に適した設計ばかり求めていました．．．

「オブジェクト指向」で設計する事の真髄は「設計根拠を設計する」の所に感じました。
（暗黙値を形式値にですね。）

例えば下記の「売上伝票入力画面」の設計構成図でどれが親ですか？と問われた場合、

コード:


　売上伝票入力画面
　　│
　　├入力機能
　　│　├入力値チェック
　　│　├情報保存
　　│　└入力結果
　　│
　　├画面機能
　　│　├起動
　　│　└閉じる
　　│　
　　└売上情報
　　　　├売上明細
　　　　├

私にとって既存の設計概念では、「売上伝票入力画面」が親でしたが、
オブジェクト指向の設計概念では、「入力機能」「画面」「売上情報」が親になる。

言葉で説明すると、

コード:

・「売上伝票入力画面」の設計は、「入力機能」「画面機能」「売上情報」の
　設計概念から構成されている。

　・「入力機能」設計概念（理念）は、ＩＰＯの考えから
　　(1)システム内部の整合性を保つ為、不正データを「入力値チェック」で弾き
　　(2)システムで入力値を保持する為、「情報保存」を行い。
　　(3)システムで入力値を保持した事を、「入力結果」で明示する必要がある。

　　・「入力値チェック」設計概念は、．．
　　・「情報保存」設計概念は、．．
　　・「入力結果」設計概念は、．．

　・「画面機能」設計概念は、ユーザインタフェースの考えから．．

　・「売上情報」設計概念は、業務の考えから．．

そして、「売上伝票テキスト取込」機能が追加された場合、
「入力機能」、「売上情報」の設計概念を再利用し
「画面機能」の換わりに「バッチ機能」の設計概念を摘要する。
と言う事になると思います。

今、振り返れば、既存の設計では設計根拠が明記されていなかったり、
第１階層だけ設計根拠のみを記述している状態で、
「センス」と言う言葉を利用して「設計の技術化」から逃げていたと思います。
これが、
「設計技術を後輩へ継承し難い、勉強し難いという考え」に繋がっていると思います。
# これれでは、設計技術が向上し難いですね。＾＾；

ここでやっと、オブジェクト指向設計の入口に立ったかなと思う所です．．．

で！ここまでズラズラ／タラタラと書いたのは、
オブジェクト指向の設計概念と方針は合っていますか？
と言う事を聞きたかったからです。

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2004-03-21 00:47

>ここでやっと、オブジェクト指向設計の入口に立ったかなと思う所です．．．

>で！ここまでズラズラ／タラタラと書いたのは、
>オブジェクト指向の設計概念と方針は合っていますか？
>と言う事を聞きたかったからです。

入口だけ表記されて、上にかかれていつようなことを問われてもぜんぜんわかりません
なおかつ　どこがオブジェクト指向設計なのかも判らないです。
ＩＰＯの手法を用いて　モジュールの分割　機能の分割をしている所まではＯＫ
それ以降の記述に関しては、オブジェクト指向設計に関することは見当たらないように
感じるのですが.....設計概念を再利用というあたりがそれっぽいですが、
オブジェクト指向設計を使わなくてもできると思うのですが...

興味のあるテーマではありますが、なんとなく独り善りというか、何を伝えようとしているのか
いまいち判らないです。

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2004-03-21 19:03

unibon です。こんにちわ。

引用:
はにまるさんの書き込み (2004-03-19 13:44) より: 「オブジェクト指向」で設計する事の真髄は「設計根拠を設計する」の所に感じました。（暗黙値を形式値にですね。）

これは契約(Contract)の概念でしょうか。すなわち DbC(Design by Contract) のことでしょうか。

引用:
はにまるさんの書き込み (2004-03-19 13:44) より: 私にとって既存の設計概念では、「売上伝票入力画面」が親でしたが、オブジェクト指向の設計概念では、「入力機能」「画面」「売上情報」が親になる。

「親(子)」の概念はとても汎用的なので、どの観点における親子なのかで意味が違ってくるかもしれません。
上記の、「売上伝票入力画面」を親とするのは、集約の面から見た場合かと思います。一方、「入力機能」「画面」「売上情報」を親とするのは、単に矢印の向きが逆に表記しただけのことに相当するような気もする一方で、それとも集約とは別の概念なのかな、とも思いますが、ちょっと良く分かりませんでした。
ちなみに、DB だと、マスターテーブルのことを「親」と呼びますよね。

＃以下、あとで追加。
参照元記事の著者のかたのホームページにはいろいろな資料があり、参考になりますね。

[ メッセージ編集済み編集者: unibon 編集日時 2004-03-21 19:08 ]

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2004-03-21 19:21

るぱんです。
いつもながら個人的な意見、かつ、雑感です。

引用:
# 今まで、オブジェクト指向言語に適した設計ばかり求めていました．．．「オブジェクト指向」で設計する事の真髄は「設計根拠を設計する」の所に感じました。（暗黙値を形式値にですね。）

設計根拠を設計する・・・って設計自体の本質なのではないかと・・・。
オブジェクト指向設計に限らず・・・って思います。

設計段階では何か行動を起こすには全てに理由があって、
それを明示してみる事が一番なのではないかと。

最近手続き型でも設計してますが、
頭の中での設計は、文字に起こしたり声に出す事柄の３倍以上はやってるんだな
って思いました。

うまく説明できていないときは、自分の直感と感性が
その仕様を求めている。。。って考えて、「じゃぁなんでだろう・・・？」

って考え直すようにしています。でも、難しいですよ～。
言葉にならない（できない）言葉が頭の中を駆けずり回って、
しかも、答えが出てこないんですから。

それと、親をどこに取るかって、難しいですよね。
全然関係ない個人的な手法ですが、
１．データオブジェクト群（入出力データ群）
２．コントローラー
３．モデル内部処理機構
４．JDBC窓口とDB
５．ヒューマンインターフェースとしてのGUI

とかって分類してますね・・・。

GUIからコントローラーは経由するのみで、
モデル内部で処理されてDBに入り込むと言う前提で、
どこのプロセスの設計なのかが問題なのか？じゃないですかね。

コントローラーのシーケンス図下部がGUIと言うひねた見方も出来そうですが・・・。

結局抽象化した全体・概要のどの辺りかが意識のしどころなのかな・・・？
なんて。

皆さんのご意見を募集したいですね。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-03-22 19:32

はにまるです。

　返答ありがとうございます。
　個人的に「オブジェクト指向の専門用語は、極力利用しない方針」で議論させて頂きます。

　まず「オブジェクト指向」で設計するとは、どういう事でしょうか？
　私は多分こうだ！と言う意味で、「設計根拠を設計する」という短い言葉にマトメました。

　結論の経過を記述すると、
　まず下記２つが私にとってオブジェクト指向の設計を考える基点としました。
　
　　　１．シミュレーションが元と成っている。
　　　２．認識学が元と成っている。

　私がシミュレーションを考えた場合、
　　　事象の存在は見とめるが、理屈が解らない事がある。
　　　複数の事象から１つの共通点（理屈）を見出す事がある。
　　　１つの理屈から他の理屈を見出す事がある。

　私が認識学を考えた場合、
　　　理屈が解らないものを解き明かす。
　　　理屈を理解する事でより適切な方法を求める。

　この２つから
　　　(1)事象を洗い出し関連を求める。
　　　(2)事象の理屈を考えて、理屈を洗い出す。
　　　(3)理屈から最適な事象を求め直す。

　補足：
　(1)について、データ中心設計と似ていますがデータ以外に業務や手順も対象。
　(2)について、ここが肝と思い「設計根拠を設計する」の言葉にしました。
　(3)について、ここでやっと、オブジェクト指向で設計するメリットが来ると思います。

中途半端ですが、今日は考え疲れたのでここまで、(^^;
続きを時間があれば明日記述致します。

[ メッセージ編集済み編集者: はにまる編集日時 2004-03-23 12:57 ]

こくぼ: 大ベテラン; 会議室デビュー日: 2003/08/11; 投稿数: 229; お住まい・勤務地: 国境の南、太陽の西。

投稿日時: 2004-03-23 09:19

こんにちは。

http://jibun.atmarkit.co.jp/lskill01/rensai/hagimoto04/hagimoto01.html
この記事によると、

引用:
オブジェクト指向技術の本質的な効果は、開発者間でソフトウェアの構造を共有できることだ。

とあります。
開発者サイドの見方だと思いますが、自分的にへぇ～っと納得しながら読みました。

何のためにシュミレーションや認識学を応用させるかと言えば
それはやはり人間に理解しやすくするためなのかな、と思いました。

りばぁ: 大ベテラン; 会議室デビュー日: 2003/11/26; 投稿数: 130; お住まい・勤務地: 愛知県

投稿日時: 2004-03-23 10:26

こんにちわ。
ものすごくどうでもいいことに反応してしまいますが＾＾；

シュミレーションって、simulationのことですよね？
カタカナ表記をするなら、せめてシミュレーションにした方が・・・。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-03-23 12:55

はにまるです。

　七味唐辛子さん、unibonさん、るぱんさん、こくぼさん

　返答ありがとうございます。
　ど～、やって議論するか悩んでいました。
　そこで、あるイレギュラーな手段を用います。

　今日の晩あたりに行動します。

りばぁさんへ
　ご指摘ありがとうございます。
　どっちが正しいか調査するのが面倒くさいので、ご指摘のまま直しておきます。　

1|2|3 次のページへ»

設計：「オブジェクト指向」で設計する事について

スキルアップ／キャリアアップ（JOB@IT）