- PR -

オブジェクト指向とUMLの研修について

«前のページへ 1|2|3|4|5|6|7|8 次のページへ»
投稿者投稿内容
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-01-23 13:16
unibon です。こんにちわ。

引用:

米山＠クロノスさんの書き込み (2004-01-23 13:04) より:
一部「オブジェクト指向」を「銀の弾」に仕立て上げようとしているような節も見られますが。

＃チャチャ(冗談)ですが、コストが高そうですね(銀は鉛より高価なので)。

引用:

米山＠クロノスさんの書き込み (2004-01-23 13:04) より:
オブジェクトは「状態」と「振る舞い」を有し、オブジェクト同士がメッセージ･パッシングを行いながら時間軸は進んでいく。。。
オブジェクトにはロール（役割）や責務があり、インターフェイス（無意識レベルで）を介してやり取りを行っている。。。

現実世界あるいは人間の思考は限りなく「オブジェクト指向」だと思いませんか？

しかし、システム構築初期段階の要求仕様は概して「振る舞い」だけにこだわって、「状態」は構わないことがほとんどですよね。システムを作らない人(使う人)にとっては「オブジェクト指向」で思考しないわけであり、それが作る人とのギャップになり、これを解消しないことには「オブジェクト指向」で作るメリットが薄れると思います。
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2004-01-23 13:35
※UMLとは全く違う話題になってしまってますねぇ。
　いやぁ、話を変なほうに膨らませているようで恐縮しております。

引用:

ukさんの書き込み (2004-01-23 12:07) より:

分析:
システム(または業務)を、「オブジェクト(または責務)」の視点で捉えるか、「機能とデータ」
の視点で捉えるか。

設計・実装：
システムを「オブジェクト(または責務)」の視点で分割するか、「機能とデータ」の視点で
分割するか。

これは、アプローチ手法としてのPOAとDOAの違いのような気がします。
DOAであってもデータモデリング等のオブジェクト指向要素が入って来るので、
ちょっと切り口が異なるかと．．．

引用:

米山＠クロノスさんの書き込み (2004-01-23 13:04) より:
こんにちは。米山＠クロノスです。

オブジェクトは「状態」と「振る舞い」を有し、オブジェクト同士がメッセージ･パッシングを行いながら時間軸は進んでいく。。。
オブジェクトにはロール（役割）や責務があり、インターフェイス（無意識レベルで）を介してやり取りを行っている。。。


おっしゃる通りなんですが、「これがオブジュクト指向だ」と定義すると、昔からC言語でも
VBでも、DOSの頃からでも同じようなことをやっている訳ではないですか。
（C/Sの３階層構造プログラミングなんて構造化の代表のようなものですが、これとて
　上記のようなことですよね？）

オブジェクト指向を「銀の弾」だとは全然思っていないのですが、何かこれまでの事とは
決定的に違うというような説明（定義）ができないのかなぁと思うのですよ。
（実装レベルとしてクラスが使えるとかどうとかではなく、「オブジェクト思考」として。）

※ところで実装レベル（アーキテクチャでもかまいませんが）としての考え方としては、
　UNIX/Linux、Windows等のOSそのものとしては、オブジェクト指向と言うことができる
　のでしょうかねぇ？
米山@クロノス
大ベテラン
会議室デビュー日: 2003/06/10
投稿数: 103
お住まい・勤務地: 大阪市淀川区西中島4-13-22 新大阪淀川ビル5F
投稿日時: 2004-01-23 14:17
unibonさんこんにちは。米山＠クロノスです。

引用:

unibonさんの書き込み (2004-01-23 13:16) より:
＃チャチャ(冗談)ですが、コストが高そうですね(銀は鉛より高価なので)。


高いですよ〜。
と、それはさておき

引用:

しかし、システム構築初期段階の要求仕様は概して「振る舞い」だけにこだわって、「状態」は構わないことがほとんどですよね。システムを作らない人(使う人)にとっては「オブジェクト指向」で思考しないわけであり、それが作る人とのギャップになり、これを解消しないことには「オブジェクト指向」で作るメリットが薄れると思います。


確かにユーザーとのやり取りとなる上流工程では、非オブジェクト指向で進めたほうがうまくいきますね。
そもそも、ユーザーにオブジェクト指向の理解を強要することは無理じゃないかと思います。
上流工程から下流工程までシームレスに、というのはなかなか難しいですね。

[ メッセージ編集済み 編集者: 米山＠クロノス 編集日時 2004-01-23 14:21 ]
米山@クロノス
大ベテラン
会議室デビュー日: 2003/06/10
投稿数: 103
お住まい・勤務地: 大阪市淀川区西中島4-13-22 新大阪淀川ビル5F
投稿日時: 2004-01-23 14:26
Beatleさんこんにちは。米山＠クロノスです。

引用:

Beatleさんの書き込み (2004-01-23 13:35) より:


引用:

オブジェクトは「状態」と「振る舞い」を有し、オブジェクト同士がメッセージ･パッシングを行いながら時間軸は進んでいく。。。
オブジェクトにはロール（役割）や責務があり、インターフェイス（無意識レベルで）を介してやり取りを行っている。。。

おっしゃる通りなんですが、「これがオブジュクト指向だ」と定義すると、昔からC言語でも
VBでも、DOSの頃からでも同じようなことをやっている訳ではないですか。
（C/Sの３階層構造プログラミングなんて構造化の代表のようなものですが、これとて
　上記のようなことですよね？）


いえ。違うということを言いたかったのですが。。。
そもそもVBにインターフェイスの概念はないですよね？
顔爺
ベテラン
会議室デビュー日: 2003/10/03
投稿数: 52
投稿日時: 2004-01-23 14:35
横から失礼します。

引用:


いえ。違うということを言いたかったのですが。。。
そもそもVBにインターフェイスの概念はないですよね？



VB5 以降にはあります(VBA にはない)。
こんな感じです。

' Class Parent の定義
Option Explicit

Public Sub DoHoge

End Sub


' Class Child の定義
Option Explicit
Implements Parent

Public Sub Parent_DoHoge()
' DoHoge の Child 用の実装
End Sub


' 使用例
Dim p As Parent

Set p = new Child
p.DoHoge
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2004-01-23 16:39
引用:

米山＠クロノスさんの書き込み (2004-01-23 14:26) より:

いえ。違うということを言いたかったのですが。。。
そもそもVBにインターフェイスの概念はないですよね？



顔爺さんの書き込みのように「あるバージョンから出来るようになった」ので
すが、私が問題にしたかったのがここなんですよね。

言語そのものに概念が無い⇒それをいろいろな手法を屈指して実現する

例えば、VBそのものに概念は無くとも、インターフェイス概念にあたる部分を別の
もの（API、ActiveXとか）で実現するといったことも含めてオブジェクト
指向なのではないかと．．．
もしそうであるならば、より設計思想側に「オブジェクト指向」としての考え
方の主要因があるのではないかと思うわけです。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-01-23 16:46
objectです。

>ukさん
恐らく、一般的に「オブジェクト」として認識出来るもので、「責務」等単独の概念で表現出来るものは無いと私は思います。
最低限、「データ」と「機能」がセットとして必要で、これらは基本カテゴリだと思います。
#ukさんの「責務」は、暗黙に役割を包含していないでしょうか？

米山＠クロノスさんが、
「オブジェクトにはロール（役割）や責務があり」
と少し言及されてますが、正確には
ロール（役割）と責務であり、
結局
データ　<->　役割（ロール）
機能　　<->　責務
という対応関係になると思います。
「役割」無き「責務」は、考えられないと私は思います。

それでは、機能と責務の違いは何かというと、
機能　<->　必要な振る舞い
責務　<->　必要十分な振る舞い
という違いではないでしょうか？

「データ」と「機能」を切り離し、単独で扱っても一般的には意味が無いと私は思います。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-01-23 17:15
引用:

objectさんの書き込み (2004-01-23 16:46) より:
#ukさんの「責務」は、暗黙に役割を包含していないでしょうか？
データ　<->　役割（ロール）
機能　　<->　責務
という対応関係になると思います。

えーと、責務の定義は私が勝手にしたものではなく、一般的なテクニカルタームです。
＃それと「オブジェクト=責務」とも言っていないはずですが。

objectさんは「責務=振る舞い」と考えてらっしゃるようですが、「情報(データでも
状態でもいいです)を知っていること」も責務になります。

役割と責務を結びつけるとすれば役割は責務の集合に名前を割り当てたものといえるかと
思います。
«前のページへ 1|2|3|4|5|6|7|8 次のページへ»

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