- - PR -
クラスのスタティックフィールドに全てのインスタンスを保存??
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-01-31 21:57
設計について質問です。
オブジェクト指向の入門書を一冊買って読んだのですがその入門書には、 「クラスの静的メンバとして、そのクラスのインスタンス全てを保持しておく」と書いてありました。 例えばビデオレンタルシステムを作成するとして、以下の2つのクラスがあるとします。 ・ビデオクラス ・客クラス 2つのクラスは、静的フィールドとして"全てのインスタンス"を保持しておきます。(インスタンス生成のたびに必ずこのフィールドに追加する。) また、客クラスにはインスタンスフィールドとして"借りてる全てのビデオ"を持たせます。 "客A"が借りてるものは"客A.借りてる全てのビデオ"から取得しますが、 "ビデオX"というビデオを現在借りている"客クラス"インスタンスを取得するには、"客クラス.全てのインスタンス"を取得し、"客クラスインスタンス.借りてる全てのビデオ"に"ビデオX"が含まれている客クラスインスタンスを導き出すと書いてありました。 どうも、全てのインスタンスを静的なフィールドとして保持しておくという所(あとインスタンス生成後に必ず全インスタンス属性に追加する処理を行うというところ)に違和感を感じるのですが、オブジェクト指向開発ではこのやり方は一般的(頻繁に利用されるもの)なのでしょうか? | ||||||||
|
投稿日時: 2006-01-31 22:11
こんばんは。
一般的じゃないんじゃないでしょうか? 少なくとも私にはそのようなやり方は見たことないですね。 別にビデオレンタルシステムの例でも、 自分自身のクラスにインスタンスを集約で保持する必要が感じられませんし… 客クラスのインスタンスは、 例えば”店クラス”とか”顧客リストクラス”とか、 別のクラスに集約しているほうが自然な気がします。 | ||||||||
|
投稿日時: 2006-01-31 22:40
なんという本か書かれても良いと思いますよ。
世界観の問題でしょう。この世にひとつしかないものならば、static やグローバル変数の類を使っても良いと思いますが、しかし、プログラムのコーディングで、常に拡張性を意識すると、やはり複数のインスタンスの存在を想定せざるを得ないことがほとんどです。したがって、よっぽどの理由がない限り、安易に static を使うのは好ましくないです。 かならずひとつしかないものの例としては、たとえば、デバッグ用のロギングには static を使うことも多いと聞きます。でも、個人的には static にしなくて済むのならばそうしたいところです。 | ||||||||
|
投稿日時: 2006-01-31 23:13
それって然るべき例があってなら賛成できるんですが、 それが普通と言われると賛成しかねます。
この例では、ちょっと厳しいかな。 どうしても管理しなくてはいけないなら、別でコレクションを作ります... 個人的にはそのクラスに所属しなくてはいけないんだけれども、 インスタンス メンバを必要としないものを static として明示化するのが .NET 流かと。 NCL を見てもそんな感じで、無駄がないです。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2006-01-31 23:49
みなさん、返答ありがとうございます。
>Tdnr_Symさん <QUOTE>一般的じゃないんじゃないでしょうか? 少なくとも私にはそのようなやり方は見たことないですね。</QUOTE> やはりそうですよね。 店クラスや顧客リストクラスに保持するのはとてもしっくりきます。 店クラス.ユーザー登録(new 客クラス)って感じで追加処理を自然な形で実現できますしね。 >unibonさん 書籍名を載せるのはちょっと気が引けたので伏せておきました^^; <QUOTE>この世にひとつしかないものならば、static やグローバル変数の類を使っても良いと思いますが、しかし、プログラムのコーディングで、常に拡張性を意識すると、やはり複数のインスタンスの存在を想定せざるを得ないことがほとんどです。</QUOTE> この世にひとつしかないというのは、シングルトンなクラスという解釈でよろしいでしょうか? >じゃんぬねっとさん <QUOTE>それって然るべき例があってなら賛成できるんですが、それが普通と言われると賛成しかねます。</QUOE> 書籍には『クラスへの操作として、特に制限を設けたり隠蔽しない限りは「すべてのインスタンス集合を返す」、「インスタンスを引数で指定して追加する」、「インスタンスを引数で指定して削除する」ことは必ず行えることでしょう。』と書いてありました・・・、鵜呑みにしないでよかったです。 えっと、また疑問点が浮かび上がってきました。 全ての客クラスインスタンスを店クラスの属性として保持させると、"ビデオXを現在借りている客"を取得する処理は、 「"客クラス.全てのインスタンス"を取得し、"客クラスインスタンス.借りてる全てのビデオ"に"ビデオX"が含まれている客クラスインスタンスを導き出す」という処理から、 「"店クラスオブジェクト.全ての客クラスインスタンス"を取得し、"客クラスインスタンス.借りてる全てのビデオ"に"ビデオX"が含まれている客クラスインスタンスを導き出す」という処理になります。 そうするとビデオクラスオブジェクトは店クラスオブジェクトの参照ができなければなりません。つまり、ビデオクラスオブジェクトは店クラスオブジェクトを保持しておくことになるのでしょうか?? あと、シングルトンパターンだとprivate static Hoge instanceで唯一のインスタンスを保持してpublic static Hoge GetInstance()でインスタンスを取得しますよね?この静的メソッドでどこからでもインスタンスにアクセスできるわけですが、これってグローバル変数のように使用して(色々なクラスで、このメソッドを通してインスタンスにアクセスして)いいんですか? | ||||||||
|
投稿日時: 2006-02-01 06:28
私の勘違いかも知れませんが、何となく「本来ならファイルやDBなどに保存しておくべきところを、オブジェクト指向の入門書ということでその部分を省略したくて静的メンバにしますよ」ってことのような気がします。
その本を読んでないので、真偽の程は定かではありませんが。 書名を教えていただければ、昼休みにでも立ち読みするかもしれません(近くの本屋においてあればの話ですが) | ||||||||
|
投稿日時: 2006-02-01 09:43
実装方法にもよるでしょうけど基本的にはそうなるかと思います。(もちろんそのメソッドのスコープを限定すればその限りではない) シングルトンという響きが何か正しい設計のように聞こえますが、結局はグローバル変数なのです。シングルトンは、どうしても必要になったときの最後の手段ぐらいの感じで、最小限に使用するのが良いかと。 この例の場合、1号店しか存在しないっていうのならば「店オブジェクト」はシングルトンでもいいのかな?(安易に^^;) _________________ 囚人のジレンマな日々 | ||||||||
|
投稿日時: 2006-02-01 20:33
みなさん、返答ありがとうございます。
>まいるどきゃっとさん
今更言ってもどのみち遅いのですが、書籍名を書くのはやはり気が引くので・・・すみません^^; >囚人さん
なるほど、シングルトンパターンを最近覚えたてで、使えるところでは使いまくって行こうなどと考えてましたが、シングルトンパターンの多用は避けるよう気をつけたいと思います。 |