Laravel Koleksiyonları: İş Mantığı İçin Neden Kullanıyorum (Sadece Kolaylık Değil)

Laravel’dan bahsedildiğinde, genellikle Eloquent, migration veya kuyruklar (queues) üzerinde durulur. Ancak günlük kod kalitemi en çok artıran özelliklerden birini seçmem gerekirse, bu Laravel Collections olur.

Collections’ı “şık” göründükleri için kullanmıyorum. Onları kullanmamın sebebi, iş mantığını (business logic) daha okunabilir, bakım yapılabilir ve başkalarına açıklanabilir bir şekilde yazmamı sağlamasıdır.

Özetle: onlar, kodun ne yaptığını verinin nasıl yinelendiğinden ayırmamda yardım ediyorlar.

İş Mantığında foreach Kullanmanın Gerçek Problemi

Basit yinelemeler için foreach‘de bir sakınca yok. Ancak projeler büyüdüğünde, döngüler içindeki iş mantığı genellikle şunlara dönüşür:

• İç içe döngüler ve geçici “toplayıcı” diziler.
• Dağıtım mantığı (if/else) her yerde yayılır.
• Karışık sorumluluklar: Kod, veriyi nasıl yineleyeceğini ve onunla ne yapacağını aynı anda halletmektedir.

Bu durum, kodun gözden geçirilmesini, hata ayıklamasını veya değiştirilmesini zorlaştırır ve ince hataların oluşmasına neden olur.

Bu yüzden sık sık Collections’a yöneliyorum.

Gözlemim: SQL/Eloquent ve Collections Arasındaki Ayırıcı

Projelerimi temiz tutmak için, sorumlulukları sıkı bir şekilde ayırıyorum:

1. Veritabanı / Eloquent (Veri Alma): Büyük veri kümesini filtrelemek, birleştirmek ve temel toplamlar için SQL kullanıyorum. Bu, belleğe yüklenen veri miktarını azaltır.

2. Collections (İş Dönüşümleri): Veriler PHP’de olduğunda, verileri yeniden şekillendirmek, gruplamak, biçimlendirmek ve karmaşık koşullu kuralları uygulamak için Collections’ı kullanıyorum.

Bu ayrım, veritabanının iyi olduğu şeyleri yapmasını sağlar; Collection boru hattı ise iş niyetini yönetir.

Veritabanı iyi olduğu işleri yapar.
Collection boru hattı ise PHP iş mantığıyla ifade edilmesi daha kolay olan işleri yönetir.

Neden Collections Okunabilirliği Artırır

Collections, kodu kasıtlı adımlar dizisi olarak yazmanıza olanak tanır:

1. İhtiyacınız olmayanları filtreleyin.
2. Veri biçimini dönüştürün.
3. Belirli bir kritere göre gruplayın.
4. Birleştirin (toplama, sayma vb.).
5. Sonucu sıralayın.

Bu, adımların iç içe geçtiği döngüye dayalı bir yaklaşıma göre büyük bir fark yaratır.

Bir Collection boru hattını okuduğumda, genellikle önce iş niyetini anlayabiliyorum.

Bu durum gerçekte çok önemlidir çünkü çoğu zaman sıfırdan algoritmalar yazmıyor, iş kurallarını sürdürüp genişletiyoruz.

Somut Bir Örnek: Ödenmiş Siparişlerden En Üst Kategoriler

Ödenmiş siparişler için kategorilere göre gelir hesaplamanız gerektiğini hayal edin, en yüksek kazanç sağlananlardan başlayarak sıralayın.

Collections ile bunu şu şekilde yazardım:

$topCategories = collect($orders)
    ->where('status', 'paid')
    ->flatMap(fn ($order) => $order['items'])
    ->groupBy('category')
    ->map(fn ($items, $category) => [
        'category' => $category,
        'revenue'  => $items->sum(
            fn ($item) => $item[] * $item[]
        ),
        => $items->pluck()->unique()->count(),
    ])
    ->sortByDesc()
    ->take(5)
    ->values();

Bu kod parçacığını seviyorum çünkü neredeyse düz İngilizce gibi okuyabiliyorum.

İş sürecini adım adım açık bir şekilde tasvir ediyor.

Döngülerle Aynı Tip Mantık Hızla Gürültü Oluşturur

Döngülerle temelde bir versiyon oluşturmak mümkün.

Ama genellikle şu sorunları getirir:

• değişken durumu ($result, $totals, $seenProducts)
• döngüler içinde dağıtım mantığı
• manuel başlatma
• ince hatalar için daha fazla fırsat

Bunun gibi basit bir örnek:

$categories = [];

foreach ($orders as $order) {
    if ($order[] !== ) {
        continue;
    }

    foreach ($order[] as $item) {
        $category = $item[];

        if (! isset($categories[$category])) {
            $categories[$category] = [
                => $category,
                => 0,
                => [],
            ];
        }

        $categories[$category][] += $item[] * $item[];
        $categories[$category][][$item[]] = true;
    }
}

$topCategories = [];

foreach ($categories as $category) {
    $category[] = count($category[]);
    $topCategories[] = $category;
}

usort($topCategories, fn ($a, $b) => $b[]  $a[]);
$topCategories = array_slice($topCategories, 0, 5);

Bu çalışıyor.

Ancak iş niyeti o kadar belirgin değil çünkü yineleme mekanikleri öne çıkıyor.

Bu nedenle, dönüşüm “iş” olduğunda Collections’ı tercih ediyorum; algoritmik olduğunda değil.

Neden Bu, Bir Takımda Daha İyi Ölçeklenir

Benim için en büyük avantaj sözdiziminde değil.

Bu takım okunabilirliğidir.

Kod bir Collection boru hattı olarak yazıldığında, başka bir geliştirici genellikle:

• Hızla tarayabilir
• Her dönüşüm adımını belirleyebilir
• Herhangi bir adımı yeniden yazmadan değiştirebilir

Bu, yeniden yapılandırmayı daha güvenli hale getirir.

Ayrıca, kod incelemelerini daha hızlı hale getirir, çünkü niyet açıktır.

Ve müşteri projeleri veya ürün ekiplerinde, bu, 3 satır kod tasarrufundan çok daha önemlidir.

En Sık Kullandığım Collection Yöntemleri (ve Nedenleri)

İşte Laravel projelerinde sürekli olarak kullandığım yöntemler:

filter() / reject()

Veri kümesini temizlemek için.

Kullanım durumu: sadece geçerli öğeleri, ödenmiş siparişleri, aktif kullanıcıları tutmak için.

map()

Veri biçimini dönüştürmek için.

Kullanım durumu: iç dizileri/modelleri API dostu veya UI dostu çıktı haline dönüştürmek.

flatMap()

Her öğe bir iç liste içerdiğinde ve düz bir liste oluşturmak istediğinizde harika.

Kullanım durumu: siparişler → ürünler, kullanıcılar → izinler, gönderiler → etiketler.

groupBy()

Raporlar için en yararlı yöntemlerden biri.

Kullanım durumu: kategori, gün, durum, ekip, kaynak vb. ile gruplama.

pluck()

Tek bir alanı hızlıca çıkartmak için mükemmel.

Kullanım durumu: ID’ler, adlar, e-postalar, etiketler.

sum(), count(), reduce()

Toplama işlemleri için.

Özel toplama mantığı gerekiyorsa reduce() kullanıyorum. Daha basit toplamlar için sum() ve count() daha net.

sortBy() / sortByDesc()

Sonucu döndürmeden önce son sıralama için.

Neden Bu Eloquent ile Bu Kadar İyi Çalışır

Collections’ı kullanmamın bir diğer sebebi: Laravel’in akışına doğal olarak uyum sağlarlar.

Eloquent ile bir model seti çektiğinizde, hemen ardından ilgili dönüşümleri Collection yöntemleri ile gerçekleştirebilirsiniz.

Şu geçiş:

• veri alımı
  oldukça etkileyici bir şekilde işe hazır veri haline gelir.

Bu, arka uç kodunun tutarlı hissettirmesini sağlar.

İzlediğim Pratik Bir Kural (Önemli)

Her şeyi körü körüne Collections ile kullanmıyorum.

İşte benim kuralım:

• SQL’de daha hızlı, daha basit ve daha doğruyse → SQL’de yapın.
• PHP’de iş mantığı olarak daha kolay anlaşılabilir hale geliyorsa → Collections kullanın.

Bunun nedeni, Collections’ın PHP belleğinde çalıştığıdır.

Bu nedenle, çok büyük bir veri kümesi ile uğraşıyorsam, önce veri kümesini sorgu katmanında azaltmalı, ardından son dönüşüm için Collections kullanmalıyım.

Bu denge genellikle tatlı nokta olur.

Bonus: Tekrarlanan İş Dönüşümleri için Makrolar Kullanın

Collections’ın gözden kaçan bir özelliği makro eklenebilir olmalarıdır.

Bu, tekrarlayan dönüşümler için kendi yeniden kullanılabilir Collection yöntemlerinizi tanımlayabileceğiniz anlamına gelir.

Projeniz sık sık aynı tür rapor veya formatı hesaplıyorsa, bir makro bu mantığı standartlaştırmaya ve boru hatlarını daha temiz tutmaya yardımcı olabilir.

Bu, iş dönüşümlerinin tekrar ettiğinde büyük kod tabanlarında özellikle faydalıdır.

Son Düşünce

Laravel Collections, sadece bir kolaylık API’si değildir.

Benim için, daha net arka uç kodu yazmak için bir tasarım aracıdır.

Beni şunları yapmaya yardımcı olurlar:

• alım ve dönüşümü ayırmak
• iş mantığını bir boru hattı olarak ifade etmek
• döngü gürültüsünü azaltmak
• bakım yapılması daha kolay kod oluşturmak

Ve gerçek projelerde, o okunabilirlik her seferinde kazanç sağlar.