SOLID ve SRP

SOLID, nesne yönelimli tasarımdan gelen beş prensip. Frontend geliştirici olarak sınıf yazmıyor olabilirsiniz, ama fikirler React component'lerine ve hook'larına da uyuyor. Bu rehber en çok işe yarayan ikisine odaklanıyor: SRP ve DIP.

SOLID bir bakışta

Robert C. Martin bu ilkelerin bugün de geçerli olduğunu savunuyor.¹ Aşağıdaki tablo her birini tek cümleyle özetliyor.

Bu rehber SRP ve DIP'i açıyor. Diğerleri için tablo yeterli.

SRP: Tek değişme nedeni

Martin'e göre bir modülün değişmesi için tek bir nedeni olmalı. "Neden" ise insanlardan gelir: modül tek bir kişiden ya da tek bir iş işlevine hizmet eden gruptan değişiklik istemeli.² Örneğinde Employee sınıfı üç yöneticiye hizmet ediyor: maaş hesabı mali işlerden, saat raporu operasyondan, kayıt veritabanı teknolojiden gelen isteklere bağlı. Biri kendi isteğiyle koda dokunduğunda diğerinin bağlı olduğu yöntem bozulabilir.²

"Bir fonksiyon tek bir şey yapar" demek değil bu. Hata düzeltmeleri ve refactoring "neden" sayılmaz, çünkü onlar programın değil geliştiricinin işi.²

React'te SRP

Bir component hem veri çekip hem fiyatı biçimlendirip hem listeyi çiziyorsa üç değişme nedeni var: API değişir, fiyat formatı değişir, tasarım değişir.

// ❌ Üç sorumluluk tek yerde
function ProductList() {
  const { data: products = [] } = useQuery({
    queryKey: ['products'],
    queryFn: () => fetch('/api/products').then((res) => res.json()),
  })
  return products.map((p) => (
    <li key={p.id}>{p.name}: {p.price.toFixed(2)} TL</li>
  ))
}

// ✅ Her parçanın bir sebebi var

// products.api.ts: yalnızca API'yi bilir
export async function getProducts(): Promise<Product[]> {
  const res = await fetch('/api/products')
  if (!res.ok) throw new Error(`Products request failed: ${res.status}`)
  return res.json()
}

// format-price.ts: yalnızca fiyat biçimini bilir
export const formatPrice = (price: number) => `${price.toFixed(2)} TL`

// use-products.ts: veriyi component'e sunar
export function useProducts() {
  return useQuery({ queryKey: ['products'], queryFn: getProducts })
}

// ProductList.tsx: yalnızca çizer
function ProductList() {
  const { data: products = [] } = useProducts()
  return products.map((p) => (
    <li key={p.id}>{p.name}: {formatPrice(p.price)}</li>
  ))
}

Veriyi ham useEffect ve fetch ile çekmedik. React dokümanına göre temizleme mantığı olmayan bir Effect'te yanıtlar sırasız gelebilir ve eski bir yanıt yenisinin üstüne yazabilir. Doküman önce framework'ün yerleşik veri çekme yolunu önerir. Framework yoksa temizleme mantığı olan bir özel hook yazmayı ya da ekosistemdeki hazır çözümleri kullanmayı söyler.⁴ Bu akademide hazır çözüm olarak TanStack Query anlatılıyor.

Custom hook mantığı paylaşır, state'i değil: her çağrı kendi state'ini alır.⁵ Dokümana göre Effect yazdığınızda onu amaca uygun adlı bir hook'a sarmak niyeti ve veri akışını açık gösterir. Aynı yerde şu uyarı da var: her tekrarı hook'a çıkarmak gerekmez, tek bir useState'i sarmak çoğu zaman gereksiz.⁵

Component'i ne zaman böleceğiniz Component ve Kod Organizasyonu rehberinde, tekrar etmiyoruz.

Bağımlılık yönetimi: DIP

Martin'e göre üst seviye iş kuralları alt seviye ayrıntılara bağlı olmamalı, bağımlılık soyutlamalara doğru akmalı.¹ Brett Schuchert'in anlatımında DIP, dependency injection ve inversion of control ile aynı şey değil. Konu, kodunuzun hangi soyutlama seviyesindeki mesajlara bağlı olduğu.⁶

Frontend'de: component fetch('/api/products') çağırıyorsa URL'ye, HTTP'ye ve cevabın şekline bağlı. useProducts() çağırıyorsa yalnızca "ürünler" kavramına bağlı. Veri kaynağı değişse component değişmez.

Schuchert'in örneğinde veri, domain diliyle konuşan bir repository arkasına saklanıyor. Depolama bir bellek içi yapı, NoSQL ya da REST servisi olabiliyor, çünkü arayüz SQL'den söz etmiyor.⁶ Yukarıdaki useProducts aynı rolü oynuyor.

Ne zaman gerekmez?