- - PR -
クラス設計について。
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2006-11-16 09:36
絶対に「こうしなさい」っていうのはないでしょうが、一般的にはどのようにしているのか気になったので投稿させていただきます。
機能で分けるというのは分かるのですが、 RegistAction DeleteAction UpdateAction SearchAction というように分けるのと UserRegistAction ArticleRegistAction CommentRegistAction という風に分けるのはどちらが一般的なのでしょうか？ 個人的にconfirm→regist→finishという流れがすぐ分かるUserRegistActionという分け方のほうが良いように思っています。 RegistActionだと保守性の部分で劣るかと思います。 皆さんはどのようにしているでしょうか？ _________________ | ||||
|
投稿日時: 2006-11-16 10:11
具体例）
画面Ａ ：社員マスタ ボタン１：検索ボタン ボタン２：新規追加ボタン ボタン３：更新ボタン ボタン４：削除ボタン があるとして、 検索ボタンだけを例に取り上げます。 僕だったら、 EmployeeSearchAction もしくは EmployeeMasterSearchAction ってするでしょうね。 [以下、つらつらと思索。長文のため、無視して構いません] 命名規約を作成して、 一人の基準でコミットメントをし続けるというのがデメリットです。 でなければ、名前がばらばらになって、同じ名前を登録したいんだけど・・・ って現象を引き起こします。 もうひとつ、Javaの一般的な命名規約に10〜20文字でクラス名を作成するというのがあったりして、 こいつに違反することが請け合いです。（笑） あとは、ソースコードが横に伸びるので、呼び出すクラス側で見にくくなったりもしますね。 この辺がデメリットです。 正しい命名が後手に回ると、全てが台無しになりますからね。 通常その辺の命名規約とその運用については 共通部品の管理者か、ＰＬの仕事になると思います。 あとは、開発コードを先頭に付与して、名称を考えさせない様にすると言うやり方もあります。 M0001_SearchAction みたいな感じです。 見た目はこっちのがきれいだから、こっちを好む人も居ます。 package.htmlを用意して、こいつにその開発コードが何かを書かせれば良いだけですしね。 そんなのは、画面の まぁ、同じ画面に対するモジュールは同じパッケージの内部で管理しますからね。 逆に言うと、画面が違えば管理するパッケージを変えるってことでしょうか？ そんなに気にする程の問題ではないですよ。 問題は、たぶん、JSPの置き位置をどうするかですけど、 こいつも階層ごとに分けてやると良いのかな・・・？ １メニュー機能の塊ごとに１パッケージでもいいし、 踏み込んで、１画面１パッケージでも。 前者は読みやすさを提供するし、 後者はBusinessLogicのパッケージ構成と同じになるし。 設計において大事なことは、コンセプトをメンバー全員で共有することです。 明確なコンセプトで意思を明示するために 設計が必要なのだと思っています。 そこから考えると、少し些細なことに拘っておられるのかな・・・？と。 回答になっているでしょうか？ | ||||
|
投稿日時: 2006-11-16 11:15
Strutsかなにかを使っている前提でその場合のいわゆるActionクラスでしょうか。 各処理は命名から登録、削除、更新、検索、 ユーザ登録、文章の投稿、コメントの登録なのは推測できますが、 どういう範囲の処理を対象にしているのかわからないのでなんとも言えません。 前者のクラスってどういう処理をするのですか？ たとえばRegistActionってのは登録処理は全部そのクラスに書かれるのでしょうか？ 少なくともWebアプリケーションの機能性で分離できないのは保守性に乏しいと思いますよ。 ユーザの登録処理と文章の投稿処理が癒着してるのは気色悪い。 | ||||
|
投稿日時: 2006-11-16 12:43
クラスの分け方の話ではありませんが、私なら UserRegisterAction といった名前にします。
・alc 英辞郎 on the web- regist http://www2.alc.co.jp/ejr/index.php?word_in=regist&word_in2=%82%A0%82%A2%82%A4%82%A6%82%A8&word_in3=PVawEWi72JXCKoa0Je ・alc 英辞郎 on the web - register http://www2.alc.co.jp/ejr/index.php?word_in=register&word_in2=%82%A9%82%AB%82%AD%82%AF%82%B1&word_in3=PVawEWi72JXCKoa0Je [ メッセージ編集済み 編集者: インギ 編集日時 2006-11-16 12:45 ] | ||||
|
投稿日時: 2006-11-16 12:47
こんにちは。
ちょっと独り言なので、あまり気にしないでください。
クラス設計っていうことは、オブジェクト指向設計(OOD)ですよね？ 「機能分割」っていうと、どうも構造化技法をイメージし オブジェクト指向設計っぽくない気がしてしまいます。 | ||||
|
投稿日時: 2006-11-16 13:10
るぱんです。
Σ Strutsとして考えて・・・って前提すら外れるのか！？ そもそもOODとStrutsって相容れる考えなのか・・・？ | ||||
|
投稿日時: 2006-11-16 13:25
Webアプリケーションとオブジェクト指向は相性が良くないですね。 そもそもWebアプリケーションの開発は纏めようがないものを 並列に大量に作るというケースが多いのでオブジェクト指向が 活躍できる場が少ない感は否めませんね。 Webシステムって再利用性が低いと思いますね。 あんまり部品化が進まない。 HTMLとデータをやりとりする部分がどうしようもなく 泥臭くなるのが問題なのでしょうか…？ | ||||
|
投稿日時: 2006-11-16 14:39
>クラス設計っていうことは、オブジェクト指向設計(OOD)ですよね？
今回の場合の質問内容は単に機能をどう分割するか、という点に尽きるのではないでしょうか？ Web システムに限らず、オブジェクト指向設計は基盤部分で完結して、具体的なロジックを記述部分は横展開になることが多いのではないでしょうか。 Struts を使う場合は Struts 自身はオブジェクト指向に設計されていますが、そこから先、ActionForm や Action クラスは OO 設計をしなくても書けるようになっていると思います。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。