- PR -

検索一覧表示のメソッド引数について

1|2 次のページへ»
投稿者投稿内容
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-01 20:31
現在、社員管理システムのクラス設計をしてます。
ここで、社員一覧を検索する画面のメソッドで迷ってます。
画面に抽出条件があり、
あるクラスにて社員一覧取得をさせようとしてますが、
この場合、社員一覧取得メソッドの引数は
画面全部の項目を渡すのでしょうか？
それとも画面の項目と同じメンバを持ったクラスを定義し、そこにsetしクラスを
引数とするのでしょうか？
それとも別のやり方でしょうか？
引数をベタに書くのは嫌だな〜と思い投稿しました。
ぜひ、お力をお貸しください。
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-01 20:49
引用:

kenkenさんの書き込み (2003-12-01 20:31) より:

この場合、社員一覧取得メソッドの引数は
画面全部の項目を渡すのでしょうか？
それとも画面の項目と同じメンバを持ったクラスを定義し、そこにsetしクラスを
引数とするのでしょうか？
それとも別のやり方でしょうか？

画面単位に引数クラスを作るより、まとまった単位でクラスを作成して、
引数とした方が汎用性が有ると思いますよ。
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-01 21:01
ぽんさん返信ありがとうございます。

最初は社員検索だから社員クラスへセットして渡そうと思っていましたが、
入社日のFrom〜Toはどうしよう？からこの問題に直面しました。

まとまったクラスは検索用のクラスと考えてよろしいでしょうか？
概念クラスなどでは出てこないし、
クラスの関連も特にないと考えてよろしいでしょうか？
（検索するメソッドを持ってるクラスには関連するかも？）
プリンス
ベテラン
会議室デビュー日: 2003/07/05
投稿数: 78
お住まい・勤務地: 神奈川
投稿日時: 2003-12-01 21:15
引用:

kenkenさんの書き込み (2003-12-01 20:31) より:
この場合、社員一覧取得メソッドの引数は
画面全部の項目を渡すのでしょうか？
それとも画面の項目と同じメンバを持ったクラスを定義し、そこにsetしクラスを
引数とするのでしょうか？
それとも別のやり方でしょうか？

１番目の引数バラバラは非オブジェクト指向的な保守性の悪い方法です。後で項目が追加されたときに引数を追加する必要があります(シグネチャが変わる)。また、そのメソッドを利用するコードすべてを修正する必要があります。
2番目の方法は方向性はあっていますが、帳票/画面ベースでのクラス設計はお勧めできません。文脈からするとScreen001.java等の画面ベースのモデリングに感じましたが、きちんとビジネスモデルを分析して、社員クラス、部署クラス、担当プロジェクトクラス等、抽出してそれらのクラスの関係もきちんと設計したあとで、それをUIにマッピングすればよいと思います。そうすれば、UIの変更にも強いシステムになると思います。
プリンス
ベテラン
会議室デビュー日: 2003/07/05
投稿数: 78
お住まい・勤務地: 神奈川
投稿日時: 2003-12-01 21:36
引用:

kenkenさんの書き込み (2003-12-01 21:01) より:
最初は社員検索だから社員クラスへセットして渡そうと思っていましたが、
入社日のFrom〜Toはどうしよう？からこの問題に直面しました。

その入社日だけと考えるとバラバラに渡してしまってもよいかな... 引数の数が多くなった場合、クエリークラスを起こすのがよいでしょうか？
List getEmployeesByStartDate(Employee from, Employee to)
も冗長な気がしますよね？
ケースバイケースでしょうか。
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-02 09:51
引用:

プリンスさんの書き込み (2003-12-01 21:36) より:
その入社日だけと考えるとバラバラに渡してしまってもよいかな... 引数の数が多くなった場合、クエリークラスを起こすのがよいでしょうか？
List getEmployeesByStartDate(Employee from, Employee to)
も冗長な気がしますよね？
ケースバイケースでしょうか。


プリンスさん返信ありがとうございます。

ケースバイケースですかね。

今度の構築システムでは検索条件を日付、数量はかならず
From、Toで行う予定としています。
今後、検索条件も増えると予想できますので
検索条件クラスを起こしておくのが賢明でしょうか。

話はそれますが、
例えば中古車情報（gooなど）の車種検索って詳細検索では
いろいろな情報渡していると思いますが
どのように行っているのでしょうかね？

[ メッセージ編集済み 編集者: kenken 編集日時 2003-12-02 09:52 ]
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-02 10:29
引用:

kenkenさんの書き込み (2003-12-01 21:01) より:

まとまったクラスは検索用のクラスと考えてよろしいでしょうか？
概念クラスなどでは出てこないし、
クラスの関連も特にないと考えてよろしいでしょうか？
（検索するメソッドを持ってるクラスには関連するかも？）

「まとまった単位のクラス」とはプリンスさんが仰る様に、社員クラス･部署クラス･担当プロジェクトクラス等の事です。
画面に依存しないクラスを作成する事によって、画面の変更に耐えれると言う事ですね。
以上の事をふまえて、もう一度クラス設計をしてみてはいかがでしょう？
(そうすれば自ずと「From〜To」の問題も解決するかも )

引用:

今後、検索条件も増えると予想できますので
検索条件クラスを起こしておくのが賢明でしょうか。

「まとまった単位のクラス」と「検索条件クラス」は別ですのでお気を付けを。
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-02 11:09
[/quote]
「まとまった単位のクラス」とはプリンスさんが仰る様に、社員クラス･部署クラス･担当プロジェクトクラス等の事です。
画面に依存しないクラスを作成する事によって、画面の変更に耐えれると言う事ですね。
以上の事をふまえて、もう一度クラス設計をしてみてはいかがでしょう？
(そうすれば自ずと「From〜To」の問題も解決するかも )

[/quote]

ぽんさん返信ありがとうございます。

もしかして、引数に社員クラス_formと社員クラス_toといった形で
１つのクラスを２つ渡すことで解決できるのでしょうか。

今までは社員クラスのみだとFrom〜Toが解決できないな〜と
悩んでおりました。
1|2 次のページへ»

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