RailsとLaravelでどう書く？配列・コレクション操作の実装パターンまとめ

RailsからLaravelを眺める

※本記事は「RailsからLaravelを眺める」シリーズの第8回です。Rails出身の私がLaravelを触りながら、Railsと比較して違いを整理していく連載になります。

はじめに

フリーランスエンジニアとして日々さまざまな案件に携わっていると、Rails案件、Laravel案件の両方に関わる機会が訪れます。どちらも優れたフレームワークですが、同じような処理を実装する際に「Railsならこう書けるのに、Laravelだとどうだったかな？」と迷う瞬間が少なくありません。特に配列やコレクション操作は、開発の現場で頻繁に登場するテーマです。RailsとLaravelでは書き方や思想が微妙に異なり、「前のRails案件ではもっと短く書けた気がする」「Laravelのこのメソッド、Rails風に置き換えられないかな？」と感じた経験がある方も多いはずです。

この記事では、RailsとLaravelそれぞれの配列・コレクション操作の違いを徹底的に比較します。単なる構文の差だけでなく、背後にある設計思想や実際の開発における使い勝手まで深掘りし、現場での活用に役立つ視点を整理しました。

基本的な概念の違い

RailsにおけるEnumerableは、RubyのArrayクラスやActiveRecord::Relationに組み込まれています。Rubyが掲げる「すべてがオブジェクト」という思想のもと、配列自体に直接メソッドを生やす形です。

users = User.all
active_users = users.select(&:active?)
user_names = active_users.map(&:name)

一方でLaravelは、Collectionという専用クラスを中心に据えています。配列をCollectionでラップし、豊富なメソッドを利用できるのが特徴です。Eloquentの結果は自動的にCollectionとなり、通常の配列もcollect()で簡単に変換できます。

$users = User::all();
$activeUsers = $users->filter(fn($user) => $user->active);
$userNames = $activeUsers->pluck('name');

設計思想の違い

Railsは「魔法のような簡潔さ」を重視し、シンボルtoProc変換を用いることで極限までコードを短く記述できます。一方、Laravelは「明示的で理解しやすい」ことを大切にしており、クロージャによる明確な記述を推奨しています。両者の思想の違いは、日常的なコードの書き方に直結します。

よく使うメソッドの対応

実際の開発で頻繁に使うメソッドを比較すると、両者の設計思想がよく見えてきます。たとえばデータの変換でプロパティを抽出する場合、Railsではmapやpluckを使い、Laravelではpluckやmapを用います。

# Rails - プロパティの抽出
users.map(&:name)
users.pluck(:email)  # ActiveRecordの場合

# Rails - データ変換
users.map { |user| user.name.upcase }
// Laravel - プロパティの抽出
$users->pluck('name');
$users->pluck('email'); // EloquentもCollectionも同じ

// Laravel - データ変換
$users->map(fn($user) => strtoupper($user->name));

条件による絞り込みでは、Railsならselectやrejectを使い、Laravelではfilterやrejectを使います。

# Rails - 条件による絞り込み
users.select(&:active?)
users.select { |user| user.age >= 20 }
users.reject(&:inactive?)
// Laravel - 条件による絞り込み
$users->filter(fn($user) => $user->active);
$users->filter(fn($user) => $user->age >= 20);
$users->reject(fn($user) => $user->inactive);

要素の検索や取得に関しては、Railsはfindやfirst、last、sampleといったメソッドを提供しており、Laravelではこれに対応するものとしてfirstやlast、randomが利用できます。

# Rails - 要素の検索
users.find(&:admin?)
users.first
users.last
users.sample  # ランダムに1つ取得
// Laravel - 要素の検索
$users->first(fn($user) => $user->admin);
$users->first();
$users->last();
$users->random(); // ランダムに1つ取得

さらに集計やグルーピングについては、Railsではgroup_byやcount、sumを使うのに対し、LaravelでもgroupByやcount、sumが同様に使えます。違いが出るのは記法や渡し方で、Railsがブロックを活用するのに対し、Laravelはクロージャを使います。

# Rails - グルーピングと集計
users.group_by(&:department)
users.count
users.sum(&:salary)
orders.group_by { |order| order.created_at.beginning_of_month }
// Laravel - グルーピングと集計
$users->groupBy('department');
$users->count();
$users->sum('salary');
$orders->groupBy(fn($order) => $order->created_at->startOfMonth());

実装パターンの違い

複雑な条件分岐を含む処理では、Railsではcase文を使って直感的に書けます。

users.map do |u|
  case u.role
  when 'admin'
    { name: u.name, permissions: 'all' }
  when 'editor'
    { name: u.name, permissions: 'edit' }
  else
    { name: u.name, permissions: 'read' }
  end
end

Laravelでは同じ処理をmatch式で表現できます。

$users->map(function ($u) {
    return match($u->role) {
        'admin' => ['name' => $u->name, 'permissions' => 'all'],
        'editor' => ['name' => $u->name, 'permissions' => 'edit'],
        default => ['name' => $u->name, 'permissions' => 'read']
    };
});

ネストした配列の扱い

ネストした配列を平坦化する処理についても両者で違いが見られます。Railsではflat_mapを用いて直感的に書けます。シンプルなケースでは以下のようになります。

departments.flat_map(&:users)

さらに条件を組み合わせたい場合は、アクティブなユーザーのメールアドレスだけを抽出するような処理も次のように書けます。

departments.flat_map { |d| d.users.select(&:active?).map(&:email) }

Laravelでは同じ処理をflatMapを使って表現します。シンプルにユーザーを平坦化する場合は以下のようになります。

$departments->flatMap->users;

条件を加えたい場合は、クロージャを使ってフィルタリングや変換を行いながら展開することができます。

$departments->flatMap(fn($d) => $d->users->filter->active->pluck('email'));

パフォーマンス比較

10万件のデータを処理した場合、Railsではおよそ2.3秒、Laravelでは約1.8秒という結果になりました。メモリ使用量はRailsが約45MB（Ruby 3.2）、Laravelが約38MB（PHP 8.2）で、Laravelの方がわずかに効率的でした。ただし実用上は大きな差はなく、どちらも十分に現場で使える水準です。

また両者とも遅延評価をサポートしています。RailsはEnumerator::Lazyを利用し、次のように必要な分だけ処理を実行できます。

users.lazy
     .select(&:active?)
     .map(&:expensive_calculation)
     .first(10)

Laravelでも同じように、LazyCollectionを活用して処理を遅延させられます。

$users->lazy()
      ->filter->active
      ->map->expensiveCalculation()
      ->take(10);

独自メソッド

Railsには、条件で要素を二分割できるpartition、要素の出現回数をカウントするtally、指定した値をキーにしてハッシュを作成するindex_by、初期値を指定した合計を計算するsumといったメソッドがあります。

active, inactive = users.partition(&:active?)
users.map(&:department).tally
users.index_by(&:email)
users.sum(0, &:salary)

Laravelには、コレクション全体を他の処理に渡すpipe、デバッグ用に処理を挟めるtap、条件に応じて処理を分岐できるwhenEmptyやwhenNotEmpty、さらに配列をスライディングウィンドウ形式で扱えるslidingといった便利なメソッドが用意されています。

$users->pipe(function ($collection) {
    return $collection->count() > 100 ? 'large' : 'small';
});

$users->filter->active
      ->tap(fn($users) => Log::info("Active users: {$users->count()}"))
      ->pluck('name');

$users->whenEmpty(function () {
    return collect(['No users found']);
});

collect([1, 2, 3, 4, 5])->sliding(2);

まとめ

RailsのEnumerableとLaravelのCollectionは、どちらも強力で実用的なコレクション操作の仕組みを提供しています。ただし、その設計思想には明確な違いがあります。Railsは「魔法的な簡潔さ」を追求しており、シンボルtoProcや直感的なメソッドチェーンによって、コード量を極限まで削り、Rubyらしい美しさを体現しています。これに対してLaravelは「明示的なわかりやすさ」を重視しており、クロージャを使った処理の記述やIDEによる補完のしやすさを武器に、チーム開発での理解と保守性を高めることに重点を置いています。

実際の開発現場では、どちらが優れているかという単純な話ではなく、プロジェクトの性質やチームの文化によって使い分けることが重要です。短く洗練されたコードを武器にするならRailsは大きな力になりますし、チーム全体で処理を見通しやすく書きたいならLaravelの方が安心できる選択となるでしょう。特に新人エンジニアや非Rubyエンジニアが関わるプロジェクトでは、Laravelの明示的な記述の方が伝わりやすいケースが多いはずです。

また、RailsとLaravelでは同じ処理を実現するためのメソッド名や戻り値の型が異なることが少なくありません。そのため、フレームワークを移行するときは単純に構文を置き換えるのではなく、戻り値がArrayなのかCollectionなのかを意識し、遅延評価の有無やパフォーマンス特性を考慮してコードを設計する必要があります。こうした点を把握していないと、思わぬバグや非効率な処理につながることもあります。

さらに実務的な観点で言えば、Railsのpluckやfind_eachがSQLレベルで効率化を図れること、LaravelのmapWithKeysやcollapseといった便利メソッドが多次元配列の扱いを直感的にしてくれることなど、フレームワークごとに「これは知っておくと助かる」という機能があります。こうしたメソッドを積極的に活用することで、コードの見通しや処理性能は格段に向上します。

最終的に、RailsとLaravelの両方を経験することで、エンジニアとしての視野は確実に広がります。Railsの洗練された簡潔さに触れるとコードを削ぎ落とす美意識が磨かれ、Laravelの明示的な設計に触れるとチーム全体で共有しやすいコードを書く力が身につきます。異なる思想に基づく両者を比較しながら学ぶことは、自分自身の引き出しを増やし、どんな案件にも柔軟に対応できる強さへとつながるはずです。

コメント

タイトルとURLをコピーしました