「配列で返す」「オブジェクトで返す」というのは、関数設計の考え方（設計思想）にも関わる重要ポイントなんです。
ここでは、実務（現場の開発）でどう使い分けるか・どんな利点があるかを、具体的なケースでわかりやすく解説します。
1. 配列で返す利点（実務でよく使うパターン）
配列は「順番に意味があるデータ」を返すのに向いています。
特に「同じ種類の値」をまとめて返すときに便利です。
✅ ケース1：座標（x, y）を返す関数
function getPosition(element) {
const x = element.offsetLeft;
const y = element.offsetTop;
return [x, y]; // 配列で返す
}
const [x, y] = getPosition(someDiv);
console.log(`座標 (${x}, ${y})`);
実務的な利点
- 座標は「順番（x → y）」が決まっているので、配列で返すほうが自然。
- 配列の方がデータが軽い（
{x: 100, y: 200}より[100, 200]の方がメモリ的に少しだけ軽い）。 - WebGL や Canvas、API などでは「配列形式のベクトル」「位置情報配列」が標準的。
📘メモ
UI座標・色データ・行列・統計データなど「構造が一定・順序に意味がある」データは、配列で返すのが自然。
✅ ケース2：複数の計算結果をまとめて返す
function calcStatistics(values) {
const sum = values.reduce((a, b) => a + b, 0);
const avg = sum / values.length;
const max = Math.max(...values);
const min = Math.min(...values);
return [sum, avg, max, min]; // 配列で返す
}
const [sum, avg, max, min] = calcStatistics([10, 20, 30]);
console.log(sum, avg, max, min);
実務的な利点
- 統計処理・数値演算系など、大量の数値をまとめて処理するときに配列形式が扱いやすい。
- そのまま別の関数へ
calcStatistics(...)[1]のようにパイプ処理（関数チェーン）できる。 - データ形式をシンプルに保てる。
📘 メモ
「型がそろっている数値・ベクトル・リスト」→配列で返す。
2. オブジェクトで返す利点（実務で非常に多い）
オブジェクトは「それぞれの値に意味（ラベル）があるデータ」を返すのに向いています。
特に業務システム・API設計・UIロジックではこちらが圧倒的に多いです。
✅ ケース1：ユーザー情報を返す関数
function getUserInfo() {
return { name: "Taro", age: 25, role: "admin" };
}
const { name, age, role } = getUserInfo();
console.log(`${name} (${age}) - ${role}`);
実務的な利点
- 可読性が高い：「この値は何か？」が明確。
- 順番を気にしなくていい（プロパティ名でアクセス）。
- APIやDBのデータ構造と親和性が高い（JSONとの相性が良い）。
- 呼び出し側のコードを変更しても影響が少ない（順番ミスがない）。
📘 メモ
「ユーザー情報」「商品情報」「設定値」など、名前付きデータは必ずオブジェクトで返す。
✅ ケース2：関数で複数の結果を返すとき
function validateUser(user) {
const errors = [];
if (!user.name) errors.push("名前がありません");
if (!user.email.includes("@")) errors.push("メール形式が不正です");
return { isValid: errors.length === 0, errors };
}
const { isValid, errors } = validateUser({ name: "", email: "test" });
if (!isValid) console.log(errors);
実務的な利点
- 「結果（isValid）」と「エラー詳細（errors）」という性質の違う値をまとめて返せる。
- 呼び出し側で
{ isValid, errors }と書くだけで直感的に意味が伝わる。 - 保守・拡張がしやすい（あとから
warningやfieldNameを追加しても壊れない）。
📘 メモ
バリデーション・APIレスポンス・フォームチェックなどは、オブジェクト返却が基本。
3. 比較まとめ（実務での判断基準）
| 比較項目 | 配列で返す | オブジェクトで返す |
|---|---|---|
| 値の意味 | 同じ種類・順序に意味がある | それぞれ意味（名前）が違う |
| 可読性 | やや低い（順序を覚える必要） | 高い（名前で意味が分かる） |
| メモリ/速度 | やや軽い | やや重い（でも誤差レベル） |
| API連携 | 数値・座標系・数列 | JSONレスポンス・設定データ |
| チーム開発 | ミスが起きやすい | 保守しやすい・安全 |
| 例 | [x, y, z], [sum, avg] | {name, age}, {ok, errors} |
4. 現場での「使い分け判断」ヒント
| シーン | 推奨 |
|---|---|
| 数値のセット（x,y,z、rgb） | 配列 |
| 検証結果・設定・情報 | オブジェクト |
| APIデータ（JSON） | オブジェクト |
| 小さなユーティリティ関数 | 配列でもOK |
| チーム開発・公開ライブラリ | オブジェクトが望ましい |
5. まとめ：現場的アドバイス
- 最初に「このデータは名前が必要か？」を考える。
- 名前が必要 → オブジェクト。
名前が不要で順序に意味 → 配列。 - 将来、返すデータが増える可能性があるならオブジェクトにしておく方が安全。
6. 応用例（どちらも現場で使う）
// 配列型：軽量な座標データ
function getRect() {
return [x, y, width, height];
}
// オブジェクト型：意味が明確な矩形データ
function getRectObj() {
return { x, y, width, height };
}
後者の方が「どの数字が何か」が分かりやすく、UI描画・API通信では主流です。