@IT会議室は、ITエンジニアに特化した質問・回答コミュニティ「QA@IT」に生まれ変わりました。ぜひご利用ください。
- PR -

適切なインスタンスの作成方法について

1
投稿者投稿内容
toto
常連さん
会議室デビュー日: 2005/10/18
投稿数: 46
お住まい・勤務地: 岡山
投稿日時: 2009-02-06 14:16
連続的に投稿していますが、気になったので質問します。

自分で作ったクラスのインスタンスを作成する時に皆さんはどのような方法を取られていますか?

コード:

'■1つ目の方法
Using UserControl As New Control.User
datatable = UserControl.GetData()
End Using



コード:

'■2つ目の方法
datatable = (New Control.User).GetData()



僕は今まで1番目の方法を使用していましたが、他の人が2番目の方法を使用していました。
確かに2番目の方法だとコードは1行ですっきりするのですが、Disposeされないんじゃないか?っと思っています。

皆さんはどのような方法を使われていますか?
また、その方法を利用する理由も聞かせていただけれ幸いです。
この他にも「もっとこんな方法があるよ!」っというのもあればぜひ。

よろしくお願いします。

[ メッセージ編集済み 編集者: toto 編集日時 2009-02-06 14:21 ]
よねKEN
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2009-02-06 15:05
ご提示の例に関して言えば、どちらも私としては有り得ません。
コントロールは利用者にUIを提供するためのものです。
ですので、データの取得のためだけにコントロールが利用されている、
という例のコードはおかしいと思います。

提示の例のようなコードを書かないとdatatableにセットしたい値を取得する方法がないとしたら、
データの取得ロジックとUIが一緒くたになっているということですからそれは設計がまずいのではないでしょうか。

例はあくまで例だとして、Disposeしないといけないオブジェクトに対しての処理としては、1つ目の方法の方が好ましいとは思います。
toto
常連さん
会議室デビュー日: 2005/10/18
投稿数: 46
お住まい・勤務地: 岡山
投稿日時: 2009-02-06 15:24
よねKENさん

回答ありがとうございます。

引用:

ご提示の例に関して言えば、どちらも私としては有り得ません。
コントロールは利用者にUIを提供するためのものです。
ですので、データの取得のためだけにコントロールが利用されている、
という例のコードはおかしいと思います。

提示の例のようなコードを書かないとdatatableにセットしたい値を取得する方法がないとしたら、
データの取得ロジックとUIが一緒くたになっているということですからそれは設計がまずいのではないでしょうか。

例はあくまで例だとして、Disposeしないといけないオブジェクトに対しての処理としては、1つ目の方法の方が好ましいとは思います。



質問の趣旨とは外れてしまいますが、Controlと言うクラスは決してサーバーコントロール(UI)を生成するクラスではありません。
今回、
Entity・・・データを格納するための入れ物
Manager・・・DBとのアクセスを担当するクラス(UIから操作不可)
Control・・・UIから操作可能な独自クラス。DBからのデータの取得など。
と言う構成を取りました。
もしかしたら、構成が適していないかもしれませんし、そもそもControlといネーミングが悪いかもしれませんが。。。

この辺についてもぜひ皆様の意見を伺いたいのですが、今回の質問の趣旨とは異なるのでまた別の機会に。
紛らわしくてすいません。

引用:

例はあくまで例だとして、Disposeしないといけないオブジェクトに対しての処理としては、1つ目の方法の方が好ましいとは思います。



そうですか。
やはり2番目の方法ではDisposeされないということですかね?
ありがとうございます。
よねKEN
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2009-02-06 18:15
引用:

totoさんの書き込み (2009-02-06 15:24) より:
質問の趣旨とは外れてしまいますが、Controlと言うクラスは決してサーバーコントロール(UI)を生成するクラスではありません。



Control、UserControlというネーミングからてっきりWindowsアプリのUserControlなのかと勘違いしていました。
早とちりで的外れなコメントで申し訳ありません。

引用:

Control・・・UIから操作可能な独自クラス。DBからのデータの取得など。



独自のクラスにIDisposableインタフェースを実装させることは私はあまりやりませんが、そのControl.UserクラスのDisposeは何をやっているのでしょうか?
DBからのデータ取得というとDisposeはコネクションからの切断などをやっていたりするのでしょうか。その場合、Disposeをきちんと呼ぶように作ってないと困ることになりますね。

引用:

やはり2番目の方法ではDisposeされないということですかね?



呼び出していないものは呼び出されません。
Disposeメソッドを呼び出すか、UsingステートメントでDisposeメソッドが呼ばれるようにする必要があります。


Finalizeメソッドを適切に作成してあれば、通常は、Disposeメソッドがまだ呼ばれていない場合に、そのFinalizeメソッド内部でDisposeに当たる処理を行うので、いつかは呼ばれます。
FinalizeメソッドはGCがオブジェクトを回収するタイミングでたいていは呼ばれますが、GCがいつオブジェクトを回収するかはわからないため、重要なリソースを握ったまま(例えばファイルをオープンしっぱなし)だと非常にまずいです。
デューン
大ベテラン
会議室デビュー日: 2004/04/21
投稿数: 174
お住まい・勤務地: Tokyo
投稿日時: 2009-02-06 23:24
クラスによるかと思います。

日付の文字列を取得したいだけならDateTimeで、2番目の方法でいいでしょうし、
streamReaderなどではtry〜Finallyもつかうでしょう、
DBサーバへのコネクションなどではusingを使った方がいいでしょうし

IDisposableを実装していないクラスにusingを使うことはできませんし
だからといってなにもしないIDisposableを実装するのかと言えばそれは間違い出だと思います。
場合によってGetDataメソッドはstaticメソッドで済む場合もあったりしますし
ケースバイケースなのでは?
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2009-02-07 13:12
Dispose されるかどうかの心配の前に、Dispose しなければならないかどうかを吟味してみては?
アンマネージ リソースを使わないなら、Dispose する必要はありません。
「Dispose されないのでは?」と書いてあるので、私も UI を持ったユーザー コントロールのことだと思いました。
toto
常連さん
会議室デビュー日: 2005/10/18
投稿数: 46
お住まい・勤務地: 岡山
投稿日時: 2009-02-09 09:58
よねKENさん
デューンさん
Jittaさん

引用:

よねKENさん
クラスのDisposeは何をやっているのでしょうか?



今は自クラスのFinalizeを呼び出しています。
じゃあ、自クラスのFinalizeはと言うと特に記述はしていません。
クラスのメソッド内で、Try Catch Finallyでコネクションの切断、ファイルクローズなどは行っています。
なので、自作クラスのDisposeまたはFinalizeで必要な処理は自作クラスではほとんど無い?はずです。

コード:
Sub Dispose() Implements IDisposable.Dispose
    MyBase.Finalize()
End Sub



引用:

デューンさん
ケースバイケースなのでは?



そうでよね。。。

引用:

Jittaさん
Dispose しなければならないかどうかを吟味してみては?



Disposeが必要かどうかはあまり考えずに、自作クラスには全てIDisposableを実装していました。
社内でDisposeする習慣を浸透させようとしての判断だったのですが。。。
必要がないのに、実装することは逆に使う側から見ると混乱を招くのかもしれませんね。。。反省

必要なところで必要な分だけ実装するのように心がけます。
1

スキルアップ/キャリアアップ(JOB@IT)