- PR -

クラス設計について

1
投稿者投稿内容
ダメ猫
常連さん
会議室デビュー日: 2004/02/20
投稿数: 45
投稿日時: 2004-08-20 13:41
こんにちわ。

最近はオブジェクト指向のクラス設計で考え込むことが多いです。
どこまでをクラスでどこまでをメソッドとして考えて良いのか・・・・
現在は「パラメータを持ち処理のあるもの」と「他のクラスでも同じコードを使うもの」
をクラスとして分けています。
クラスはどこまで詳細に落として良いのか・・・・
aa
ぬし
会議室デビュー日: 2004/01/08
投稿数: 299
投稿日時: 2004-08-20 20:31
私もオブジェクト思考設計でよく悩んでいます。
モデルのオブジェクト化＝＞interfaceの抽出　ってな具合です。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-08-20 22:53
unibon です。こんにちわ。

引用:

ダメ猫さんの書き込み (2004-08-20 13:41) より:
どこまでをクラスでどこまでをメソッドとして考えて良いのか・・・・
現在は「パラメータを持ち処理のあるもの」と「他のクラスでも同じコードを使うもの」
をクラスとして分けています。


「OOPがよくわかりません」
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=2931&forum=12
で、つぎのように書いたことがあります。

引用:

unibonさんの書き込み (2002-12-09 16:42) より:
処理(メソッド)を中心に据えて考えていることに大きな問題があると思います。
状態(フィールド)をまず中心に考えて、そのつぎにそれらフィールドが属するクラスを考えて、
処理(メソッド)は最後に考えたほうが良いと思います。

これが必ずしも正しいわけではありませんが、状態(フィールド)の片鱗だけでも思考のどこかに現れていないと、クラス設計はおぼつかないと思います。
かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2004-08-23 13:03
私は、ユースケース記述のフローを元に抽出します。
ユースケース記述のフローは通常、アクターが、何に対して、何をすると記述します。何に対してをクラス候補、何をするを責務の候補として抜き出します。

また、ユーザーの入力や見てくれに関わる部分をBoundaryクラス[B]、ロジックに相当する部分をControlクラス[C]、データの保持を行う部分をEntityクラス[E]とし、B-B, B-C, C-C, C-E, E-E間での結びつきがあるとき、コラボレーションの候補として抜き出します。

抜き出したクラス、責務、コラボレーションを使って、シーケンス図を書き、検証するといった、レビューを繰り返して、構成を洗練させていきます。

責務やコラボレーションという名称は、聞きなれないものかもしれませんが、とりあえずは、責務はメソッド、コラボレーションは委譲と考えてもらえばいいです。

かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2004-08-23 14:47
私は、ユースケース記述のフローを元に抽出します。
ユースケース記述のフローは通常、アクターが、何に対して、何をすると記述します。何に対してをクラス候補、何をするを責務の候補として抜き出します。

また、ユーザーの入力や見てくれに関わる部分をBoundaryクラス[B]、ロジックに相当する部分をControlクラス[C]、データの保持を行う部分をEntityクラス[E]とし、B-B, B-C, C-C, C-E, E-E間での結びつきがあるとき、コラボレーションの候補として抜き出します。

抜き出したクラス、責務、コラボレーションを使って、シーケンス図を書き、検証するといった、レビューを繰り返して、構成を洗練させていきます。

責務やコラボレーションという名称は、聞きなれないものかもしれませんが、とりあえずは、責務はメソッド、コラボレーションは委譲と考えてもらえばいいです。

1

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