- PR -

配列 vs コレクション(戻り値)

投票結果総投票数:49
配列に変換して返す 11 22.45%
Listのまま返す 34 69.39%
常に戻り値には配列を使う 2 4.08%
常に戻り値にはコレクションを使う 2 4.08%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
rain
ぬし
会議室デビュー日: 2006/10/19
投稿数: 549
投稿日時: 2008-11-14 10:22
戻り値には、あまり余計な機能(List<T> だと Add() とか Find() とか Sort() とか)はついていないほうがよいと思っています。
なので List<T> か配列か、と聞かれたら配列を推します。
メソッドを呼んだ人が結果を加工したいのであれば、呼びだした側の処理で List<T> に詰め込むなりしてあげればよいわけです。
# という考えをどんどん推し進めていくと、IEnumerator<T> になるのかな??

…といいつつも、実際は呼び出した側が何に使うのかがあらかじめ分かっている場合(private メソッドとか)は、呼び出した側に都合がいいように戻り値の型を決めてしまうことも多々あったりします。
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2008-11-14 11:54
Chapter のリスト をそのまま返すということは、SplitIntoChapters メソッドを呼び出す側で Chapter のリストに変更を加えることができてしまうということですよね?
それでも良い場合はそのまま返しますが、それでは困る場合は配列にしたり ReadOnlyCollection でラッピングしたりします。
ということでケースバイケースです。ただ大抵の場合、外部で変更できてしまうのは困ると思います。
_________________
C#と諸々
platini
大ベテラン
会議室デビュー日: 2002/12/03
投稿数: 193
投稿日時: 2008-11-14 12:13
ケースバイケース派ですが、
VB6だと
絶対に要素があることが自明の場合、配列
(一応Ubound=-1の配列が定義できたことを承知の上で)

要素がゼロ個の場合あるかも?
の場合、Collection(List系)

のように使い分けてました。

DBアクセスした結果を配列にとったりするとき、
Where条件によってレコードがゼロ個の場合、
配列に取るコードを書くと、何か不自然になってしまう気がしておりまして。
(⇒私見です)

.NET からは要素数ゼロの配列が定義できるようになったので、
可変個数か固定個数かで、単純にList系、Array系に
しています。
かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2008-11-14 12:29
オブジェクトの外で、コレクションの変更を認めるかどうかで決めています。
たいていは、コレクションを内包するオブジェクトの場合、変更をオブジェクトに委譲させるべきと思っているので、配列で返しています。

System.Window.Forms.Controlの様に、子孫コントロールの変更を外部に認める場合は、IListか、または専用のインターフェースやプロキシを返すでしょうね。
Shane
大ベテラン
会議室デビュー日: 2003/06/06
投稿数: 132
お住まい・勤務地: Vancouver, BC
投稿日時: 2008-11-15 03:16
なるほど、ケースバイケース派の方たちの意見で、オブジェクトの外で(呼び出し側で)コレクションの変更を認めるかどうかどうかで決めるという意見がありますね。確かにそれはリーズナブルだと思います。勉強になります。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-11-17 11:51
.NETは門外漢なので、不適切かもしれませんが、Java的な観点で。。。

IListを返したところで、追加メソッドや削除メソッドが、
正しく実装されている保障がないわけですよね。
殆どがArrayListだったりするとは思いますけど。

なので、自分の場合は、publicメソッドではListを返したりせずに、
配列を返すことが多いですが、使い方を限定できるprivateなメソッドでは、
どの実装が返ってくるのかが分かるので、Listを返したりします。

クラスのフィールドにあるListを、そのまま返したりすると、
インスタンスの内部状態を外部から変更できてしまうので、
自分の場合は大抵詰め替えを行いますが、
その際に配列に詰め替えることが多いです。
rain
ぬし
会議室デビュー日: 2006/10/19
投稿数: 549
投稿日時: 2008-11-17 13:04
話を眺めていたのですが、1つわからないことがあります。
「オブジェクトの外で(呼び出し側で)コレクションの変更を認める」というお話が出てきていますが、それはどういったことを指していますか?

もし、SplitIntoChapters() というメソッドがコレクションを返して、コレクションの要素に変更を加えた結果が元の Book オブジェクトへ反映されるというのであれば、それは SplitIntoChapters() というメソッドではなく、
コード:
public List<Chapter> Chapters { get; }


のような読み取り専用のプロパティとして実装すべきなんじゃないかと思ったのですが、何か読み違えていますか?
mio
ぬし
会議室デビュー日: 2005/08/25
投稿数: 734
お住まい・勤務地: 神奈川県
投稿日時: 2008-11-17 13:19
List<Hoge> hogeList = foo.getHoges();
hogeList.insert(0, new Hoge());

という話でしょう。

List<Hoge> hogeList = new ArrayList<Hoge>();
hogeList.add(new Hoge());
hogeList.addAll(foo.getHoges());

でも良いわけですが。

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