- PR -

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

«前のページへ 1|2|3|4 次のページへ»
投票結果総投票数：49
配列に変換して返す 11票 22.45%
Listのまま返す 34票 69.39%
常に戻り値には配列を使う 2票 4.08%
常に戻り値にはコレクションを使う 2票 4.08%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。
投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-11-17 13:25
Chapters自体は読み取り専用でも、
Chaptersの中身を不変にすることはできないですよね。
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2008-11-17 13:28
引用:
rainさんの書き込み (2008-11-17 13:04) より:

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

のような読み取り専用のプロパティとして実装すべきなんじゃないかと思ったのですが、何か読み違えていますか？


おっしゃる通り、外からの変更を許可するのならば、メソッドではなくプロパティにしますね。
_________________
C#と諸々
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2008-11-17 14:07
補足します。

「読み取り専用のプロパティ」という点についてですが、僕も同じく読み取り専用プロパティにします。
rain さんもそうなのだと思いますが、コレクションが読み取り専用かどうかに関わらずコレクションのプロパティは読み取り専用にします。(フィールドレベルで readonly を付加してます。)

コレクションそのものの入れ替えができた方が好ましい場合はセッターを設けますが、そのようなケースは思い浮かばないです。
_________________
C#と諸々
ＴＡＫＡ
会議室デビュー日: 2007/06/03
投稿数: 19
投稿日時: 2008-11-17 14:26
「Listのまま返す」に１票入れました。
理由は、「使いやすいから(個人主観で)常にList」です。

「オブジェクトの外で、コレクションの変更を認めるかどうか」で、
配列・Listを使い分けるというご意見についてですが、
たとえ配列でも、Bookのメンバをそのまま返却していれば、外部での変更が
Book内部に影響を及ぼしますし、外部は、返却された配列が、
toArrayで生成されたインスタンスなのか、
Bookのメンバで保持しているインスタンスなのかは分かりません。

戻り値が配列であれ、Listであれ、
「オブジェクトの外で、コレクションの変更を認めるかどうか」は
同一インスタンスを返却するか、別インスタンスを生成して返却するか、で
決定するものと考えております。

rain
ぬし
会議室デビュー日: 2006/10/19
投稿数: 549
投稿日時: 2008-11-17 15:07
Chapters を readonly にした意図は、よこけんさんに補足してもらった通りです。

引用:

mioさんの書き込み (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());

でも良いわけですが。

元の質問も改めて読んでみました。こっちの意味のようですね。
スレを脱線させてしまったみたいですみません。

# 私なら↓こう書くかも
コード:
// GetArrayOfHoge() は Hoge[] を返す
List<Hoge> hogeList = new List<Hoge>(foo.GetArrayOfHoge());
hogeList.Insert(0, new Hoge());
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2008-11-17 16:09
引用:
ＴＡＫＡさんの書き込み (2008-11-17 14:26) より:

「オブジェクトの外で、コレクションの変更を認めるかどうか」で、
配列・Listを使い分けるというご意見についてですが、
たとえ配列でも、Bookのメンバをそのまま返却していれば、外部での変更が
Book内部に影響を及ぼしますし、外部は、返却された配列が、
toArrayで生成されたインスタンスなのか、
Bookのメンバで保持しているインスタンスなのかは分かりません。

戻り値が配列であれ、Listであれ、
「オブジェクトの外で、コレクションの変更を認めるかどうか」は
同一インスタンスを返却するか、別インスタンスを生成して返却するか、で
決定するものと考えております。


オブジェクトの外でのコレクションの変更を認めない、ということを厳密に示すには ReadOnlyCollection でしょうね。
(プロパティではなく) メソッドの戻り値が配列型ならば、Book内部に影響を及ぼすとはあまり考えないかなと思いますが、
これは主観でしかないかもしれませんね。

_________________
C#と諸々
ＴＡＫＡ
会議室デビュー日: 2007/06/03
投稿数: 19
投稿日時: 2008-11-17 17:55
引用:

(プロパティではなく) メソッドの戻り値が配列型ならば、Book内部に影響を及ぼすとはあまり考えないかなと思いますが、


すみません！勝手にBookはChapterをメンバに保持している妄想をして、書いていました。

で、「返却したインスタンスが外部で変更された時、Bookの状態に影響を与えたく無い場合は配列」という
論拠であれば、これはインスタンスの扱いの違いで、シグニチャの選択基準とはチョット違うのでは？
という反抗心でした。（List派が不利っぽかったので）

よこけん様の言われるとおり、返却したChapter自体の変更を一切禁止する目的であれば、
ReadOnlyCollectionしかなく、これも、配列 or Listのシグニチャ選択とは少し別問題かと思いますので、
やはり私は、Listが好きという主観と便利さで、「Listのまま」に1票です・・
（低レベルな意見でゴメンナサイ）
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2008-11-17 23:49
引用:
ＴＡＫＡさんの書き込み (2008-11-17 17:55) より:

勝手にBookはChapterをメンバに保持している妄想をして、書いていました。

あれ？スレ主さんの最初の投稿を見るに、「Book は Capter をメンバに保持している」で良いのでは？


引用:
ＴＡＫＡさんの書き込み (2008-11-17 17:55) より:

これも、配列 or Listのシグニチャ選択とは少し別問題かと思いますので、

僕は「Book は Capter をメンバに保持している」を前提にレスしていまして、スレ主さんが最初に挙げた例はシグネチャ選択以前の問題と捉えています。

また、次のような特定の条件を満たす要素を抽出して返すメソッドなどについては、僕は言及していません。

コード:
public Book[] FindBooksByAuthor(Author author)
{
    var query = 
        from book in this._books
        where (book.Author == author)
        select book;
    return query.ToArray(); // or ToList() ?
}



引用:
ＴＡＫＡさんの書き込み (2008-11-17 17:55) より:

やはり私は、Listが好きという主観と便利さで、「Listのまま」に1票です・・

んー、外部からの変更を想定していない (≒変更されると困る) 場合でも List を (コピーせず) そのまま返すのですか？
されると困るのに禁止しないのは危険であり不便だと僕は思います。
_________________
C#と諸々
«前のページへ 1|2|3|4 次のページへ»

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