- PR -

配列 vs コレクション（戻り値）

投票結果総投票数：49
配列に変換して返す	11票	22.45%
Listのまま返す	34票	69.39%
常に戻り値には配列を使う	2票	4.08%
常に戻り値にはコレクションを使う	2票	4.08%
投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。

投稿者

投稿内容

ＴＡＫＡ: 会議室デビュー日: 2007/06/03; 投稿数: 19

投稿日時: 2008-11-18 00:44

うーん、うまく伝えられずに申し訳ありません・・・

引用:
Shaneさんの書き込み (2008-11-15 03:16) より: なるほど、ケースバイケース派の方たちの意見で、オブジェクトの外で（呼び出し側で）コレクションの変更を認めるかどうかどうかで決めるという意見がありますね。確かにそれはリーズナブルだと思います。勉強になります。

上記あたりの「配列に変換して返す」派の方々の根拠を、私は以下のように受け取りました。
-----------------------------------------------------------------------------
(1)BookはList<Chapter>をメンバで保持している。
(2)Listのまま(コピーせず)返却すると、外部で値変更された場合、Bookに影響を与えてしまう。
(3)ToArrayすれば、外部で値変更されても問題ない。

⇒だから、外部で変更を認めない場合は、配列とすべきである。
-----------------------------------------------------------------------------

上記に対して、私は、
-----------------------------------------------------------------------------
・(2)と(3)の違いは、インスタンスの扱い方の違いであって、配列かListかのシグニチャに依存するものではない。
・(2)と(3)のいずれも、返却したオブジェクト自体を変更不可にする制約ではない。

⇒だから、「外部で変更を許可しない場合は配列」理論には疑問を感じる。
　なので、配列・Listを混在させるより、利便性・統一性から「Listのまま」に１票。
-----------------------------------------------------------------------------
という意見です。

ですから、

引用:
よこけんさんの書き込み (2008-11-17 23:49) より: んー、外部からの変更を想定していない (≒変更されると困る) 場合でも List を (コピーせず) そのまま返すのですか？されると困るのに禁止しないのは危険であり不便だと僕は思います。

については、「No」で

引用:
ＴＡＫＡさんの書き込み (2008-11-17 14:26) より: 戻り値が配列であれ、Listであれ、「オブジェクトの外で、コレクションの変更を認めるかどうか」は同一インスタンスを返却するか、別インスタンスを生成して返却するか、で決定するものと考えております。

上記で記述したとおり、配列・Listに限らず、外部からの変更を想定していない (≒変更されると困る) 場合は、
コピーした別インスタンスを返却します。
（たぶん、この点は、よこけん様と同意見です）

認識違いで、スレを混乱させていたら、本当にゴメンナサイ。

Shane: 大ベテラン; 会議室デビュー日: 2003/06/06; 投稿数: 132; お住まい・勤務地: Vancouver, BC

投稿日時: 2008-11-18 02:50

多分、僕の出した例があまり適切ではなかったと思います。

僕が問題として提起したかったのは、public メソッドのシグニチャに焦点を当てたもので、もっと例をシンプルにしてしまうなら、１冊の本を何らかの基準で複数の本に分割してしまうメソッド（例えば Split()）のシグニチャをどうするかといったイメージです。

最初に浮かんだのは、String クラスの Split() メソッドです。実際にソースコードを読んでみましたが、String の Split() では、内部で ArrayList のコレクションを生成し、最後に配列を作成して戻り値としています。つまり今回の投票でいう「配列に変換して返す」選択肢になります。

ただ、これはどなたかがおっしゃっていたようにシステムレベルのデザインなので、アプリケーション開発レベルでのデザインとは考え方が違う気がしたので、Book というクラスでの例を挙げ皆さんに意見を伺ったという経緯です。

[ メッセージ編集済み編集者: Shane 編集日時 2008-11-18 02:57 ]

よこけん: 大ベテラン; 会議室デビュー日: 2006/01/31; 投稿数: 216

投稿日時: 2008-11-18 16:17

引用:
よこけんの書き込み (2008-11-17 23:49) より: 僕は「Book は Capter をメンバに保持している」を前提にレスしていまして、スレ主さんが最初に挙げた例はシグネチャ選択以前の問題と捉えています。

上記の、前回の書き込みでも書きました通り、僕は主にインスタンスの扱いに着目して発言をしていました。
この時メソッドかプロパティかということもあまり考慮していません。(その結果、rain さんから質問が挙がりました。)
その上で、僕が別インスタンスを用意する際は配列や ReadOnlyCollection に変換する場面が多い (ReadOnlyCollection は特にプロパティで使用することが多いです) ので最初の書き込みであのように書きました。
この時 List に変換という考えは出てこなかったのですが、TAKA さんの意見を聞いて納得しています。

引用:
ＴＡＫＡさんの書き込み (2008-11-18 00:44) より: 配列・Listに限らず、外部からの変更を想定していない (≒変更されると困る) 場合は、コピーした別インスタンスを返却します。

そういうことでしたら、僕からは特に何もないです。
IEnumerable や IList という意見も最初に挙がっていますので、List をこのスレの結論とするのかどうかには僕は関与しませんが^^;

引用:
ＴＡＫＡさんの書き込み (2008-11-18 00:44) より: 認識違いで、スレを混乱させていたら、本当にゴメンナサイ。

いえ、僕の最初の書き込みで、言葉が足りてなかったこと・List を度外視していたことが原因だと思います。
すみませんでした。

_________________
C#と諸々

Shane: 大ベテラン; 会議室デビュー日: 2003/06/06; 投稿数: 132; お住まい・勤務地: Vancouver, BC

投稿日時: 2008-11-19 08:35

引用:
よこけんさんの書き込み (2008-11-18 16:17) より: IEnumerable や IList という意見も最初に挙がっていますので、List をこのスレの結論とするのかどうかには僕は関与しませんが^^;

私の出した例が悪かったと思います。ポイントはスレッドのタイトルにあるように、「配列」か「コレクション」かという点です。

«前のページへ 1|2|3|4

＠IT SpecialPR

配列 vs コレクション（戻り値）

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