Composables Mimarisinde Clean Code Yaklaşımları: DRY, KISS, SOLID ile Temiz ve Ölçeklenebilir Kod

Vue 3 ve Nuxt dünyasında composables artık neredeyse her projede temel yapı taşı haline geldi. Ancak çoğu projede bu yapı zamanla karmaşıklaşır: aynı mantık farklı dosyalarda tekrar eder, fonksiyonlar büyür, okunabilirlik kaybolur.

Bu yazımda composable yapısını clean code prensipleriyle ele alacağız. DRY, KISS ve SOLID yaklaşımlarına göre nasıl daha düzenli, okunabilir ve ölçeklenebilir hale getirebileceğimizi konuşacağız.

Composables Nedir, Neden Bu Kadar Önemli?

Composables, Vue’nun Composition API’si sayesinde component’lerin iş mantığını soyutlamamızı sağlar. Yani bir component sadece UI’a odaklanırken, iş mantığı composable fonksiyonlarda merkezi şekilde yönetilir.

Eğer net oturmadıysa bu yazımda daha anlayabileceğiniz şekilde bahsettim.

Kısaca:

• UI → Component
• İş Mantığı → Composable

Bu ayrım Single Responsibility Principle (SRP) yani “her yapının tek bir sorumluluğu olmalı” anlayışının doğrudan yansımasıdır.

DRY (Don’t Repeat Yourself)

Sorun: Aynı mantığı farklı composable’larda tekrar yazmak.

Örneğin useFetchUser ve useFetchProduct fonksiyonlarında aynı hata yönetimi veya loading mantığı varsa, DRY ihlali vardır.

Çözüm: Ortak davranışları soyutlayıp tek bir generic utility(genel yardımcı fonksiyonlar) oluşturmak:

export function useFetch<T>(url: string) {
  const data = ref<T | null>(null)
  const error = ref<Error | null>(null)

  const load = async () => {
    try {
      const res = await fetch(url)
      data.value = await res.json()
    } catch (err) {
      error.value = err as Error
    }
  }

  return { data, error, load }
}

Artık farklı senaryolarda sadece tipi ve URL’i değiştirerek kullanabiliriz:

const { data: user } = useFetch<User>('/api/user')
const { data: products } = useFetch<Product[]>('/api/products')

Bu sayede hem tekrar ortadan kalkar hem de hata yönetimi merkezi hale gelir.

KISS (Keep It Simple, Stupid)

Amaç: Composable’lar küçük, sade ve tek amaca odaklı olmalı.

Örneğin useDashboard içinde filtreleme, pagination, istatistik gibi farklı konular bir aradaysa, kod karmaşıklaşır.

Bunun yerine şu şekilde ayrıştırmak gerekir:

• useDashboardStats
• useDashboardFilters
• useDashboardPagination

Not: Basitlik, composable’ların okunabilirliğini ve test edilebilirliğini artırır.

SOLID Prensiplerine Göre Composables

(S) Single Responsibility: Her composable tek bir sorumluluğa sahip olmalı.

UseAuth hem login hem register hem logout yapıyorsa, üçe bölünmeli:

useLogin()
useRegister()
useLogout()

(O) Open/Closed: Composable’lar genişletilebilir ama değiştirilmemelidir.

Bir useFetch’e pagination eklemek istiyorsak fonksiyonu değiştirmeyelim, genişletelim:

function usePaginatedFetch<T>(url: string, page: Ref<number>) {
  const { data, error, load } = useFetch<T>(`${url}?page=${page.value}`)
  return { data, error, load }
}

(L) Liskov Substitution: Composable’ların döndürdüğü yapılar tutarlı olmalı.

Tüm fetch composable’ları { data, error, load } yapısını koruyorsa, bu standardı bozmamak kod okunabilirliğini korur.

(I) Interface Segregation: Composable, gereksiz veri veya fonksiyon döndürmemeli.

UseUser yalnızca user ve updateUser döndürmeli; deleteUser gibi farklı sorumluluklar başka composable’a ait olmalı.

(D) Dependency Inversion: Composable’lar doğrudan fetch veya axios gibi araçlara değil, soyut bir API katmanına bağlı olmalı:

export function useUser(api = apiClient) {
  const getUser = async () => api.get('/user')
  return { getUser }
}

Bu sayede testlerde kolayca mock’lanabilir, bağımlılıklar esnek hale gelir.

Önerilen Dizin Yapısı

/composables
 ├── api/
 │   ├── useFetch.ts
 │   ├── usePaginatedFetch.ts
 ├── auth/
 │   ├── useLogin.ts
 │   ├── useLogout.ts
 ├── user/
 │   ├── useUser.ts
 │   ├── useUserProfile.ts

Bu yapı:

• SRP’yi destekler
• KISS prensibine uygundur
• Kodun ölçeklenmesini kolaylaştırır

Sonuç

Composables yalnızca “tekrar kullanılabilir fonksiyonlar” değil, aynı zamanda temiz kodun yapıtaşı olabilir. DRY, KISS ve SOLID prensipleri bu yapıyı sürdürülebilir hale getirir.

Doğru kurgulanmış bir composable mimarisi:

• Kod tekrarını azaltır
• Karmaşıklığı düşürür
• Geliştirici deneyimini iyileştirir

Clean code sadece bugünü değil, geleceği de korur.

Composables bu geleceği inşa etmek için en güçlü alanlardan biridir.