- PR -

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

«前のページへ 1|2
投稿者投稿内容
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-02 11:33
引用:

kenkenさんの書き込み (2003-12-02 11:09) より:

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

今までは社員クラスのみだとFrom〜Toが解決できないな〜と
悩んでおりました。

どの様な設計を行っているのか分からないので、適切では無いかもしれませんが。
下記のような構成ではどうですか？
コード:
class 社員 {
	private 入社日 entranceDay;
		･
		･
		･
}

class 入社日 {
	private Date from;
	private Date to;
}



unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-12-02 11:41
unibon です。こんにちわ。

引用:

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

複雑な検索条件をとりまとめるクラスの作り方の話題ですよね。
デザインパターンの Strategy(か Template Method ? や Command ?)が近いような気がします。
＃あまりパターンにこだわるわけではありませんが。

たとえて言えば、
java.lang.Object.equals や java.lang.Comparable.compareTo
は一般的な比較ですが、差し替えができない(複数持たせられない)ので、
差し替えを考えた場合は java.util.Comparator.compare を使いますが、
これの拡張を意識されると良いと思います。
検索条件に「社員クラス」を流用するのは、
拡張性がないので複雑な検索条件では破綻するので、
検索条件の複雑さに応じて早めに諦められるほうが良いかもしれません。
プリンス
ベテラン
会議室デビュー日: 2003/07/05
投稿数: 78
お住まい・勤務地: 神奈川
投稿日時: 2003-12-02 11:50
Kenkenさんの作られてるシステムはどれくらいの規模でしょうか？
社員検索ということは、iOfficeのような予定表、プロジェクト管理の社内利用のグループウエアでしょうか？規模的に小さなものであれば最初はString, Date等のプリミティブなクラスで作っておいて将来引数の数が増えたらクエリー専用クラスを作成するという、XP的手法(リファクタリング)でよいと思います。
その際、クエリー専用クラスを作る場合は、独立したクラスではなくて集約(aggregation)を使用して、

class EmployeeQry {
Employee from;
Employee to;
}

class Employee {
String code;
String name;
Date start;
...
BuSyo busyo;
Project tantouPrj;
}

とすると分かりやすいと思います。

それから、Gooの検索ページを拝見しましたが、CGIベースのカテゴリー検索がほとんどで、検索パラメータが複数出てくるような感じではなかったですが？
あの程度の検索パラメータならクエリークラスを設ける必要性は無いと思います。
J2EEのチュートリアルをみても、境界条件等パラメータが少ない場合はString等でバラバラに渡しています。
業務系の検索ページでパラメータが何十個もある場合は、きちんとクラス設計したほうがぐちゃぐちゃにならないと思います。
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-02 11:54
引用:

どの様な設計を行っているのか分からないので、適切では無いかもしれませんが。
下記のような構成ではどうですか？
コード:
class 社員 {
	private 入社日 entranceDay;
		･
		･
		･
}

class 入社日 {
	private Date from;
	private Date to;
}



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

確かに設計次第ですが、入社日にFrom、Toを持っておくのは
考えておりません。
あくまでも検索画面にFrom,Toが存在しているだけだと思っています。
kenken
会議室デビュー日: 2003/09/19
投稿数: 9
投稿日時: 2003-12-02 12:09
プリンスさん返信ありがとうございます。

現在の社員管理システムは検索条件は少ししかありませんが、
他部署で行ってる業務で５０個くらいの検索条件の画面が
あり、関連していたのでここに載せてみました。

引用:

その際、クエリー専用クラスを作る場合は、独立したクラスではなくて集約(aggregation)を使用して、

class EmployeeQry {
Employee from;
Employee to;
}

class Employee {
String code;
String name;
Date start;
...
BuSyo busyo;
Project tantouPrj;
}

とすると分かりやすいと思います。


非常に分かりやすい返信ありがとうございます。
上記を見た瞬間、モヤモヤが消えました。
ありがとうございました。
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-02 12:45
解決された様ですが･･･

引用:

kenkenさんの書き込み (2003-12-02 11:54) より:

確かに設計次第ですが、入社日にFrom、Toを持っておくのは
考えておりません。
あくまでも検索画面にFrom,Toが存在しているだけだと思っています。

上記は僕の勘違いでした。
(社員クラスを検索条件クラスと思ってました、失礼)

引用:

検索条件に「社員クラス」を流用するのは、
拡張性がないので複雑な検索条件では破綻するので、
検索条件の複雑さに応じて早めに諦められるほうが良いかもしれません。

unibonさんが仰る様に社員クラスを検索条件として、使用するのは汎用的では有りません。

[画面]->[検索条件クラス]<-[検索条件作成クラス]->[社員クラス]･[その他、日付クラスなど]

の様にすると[画面]の変更が社員クラスまで及ばないので変更に強いシステムになります。
お試しあれ
«前のページへ 1|2

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