RUBY METAPROGRAMMING NEDİR?

Ruby metaprogramming'i "sihir" olarak anlatan kaynaklar yanıltıcıdır — pek çok geliştirici bunun runtime'da kod üreten bir büyü olduğunu sanır. Oysa metaprogramming, dilin zaten sahip olduğu açık sınıf yapısı, method_missing kancası ve define_method gibi araçlarla kodun kendini tanımlamasıdır. Asıl mesele ne yapabildiğin değil, ne pahasına yaptığındır: her dinamik tanım, ileride bir geliştiricinin "bu method nereden geliyor?" diye saatlerce arayacağı bakım yüküne dönüşür.

Metaprogramming Tam Olarak Nedir?

Metaprogramming, programın kendisini veri olarak ele alıp çalışma zamanında değiştirmesidir. Ruby'de bu, dilin felsefesinden geliyor: her şey nesnedir ve sınıflar bile çalışma zamanında değiştirilebilir. Bir method'u runtime'da tanımlayabilir, eksik bir method çağrısını yakalayabilir, var olan bir sınıfa dışarıdan davranış ekleyebilirsiniz.

Burada yaygın yanılgı şu olur sanılır ki metaprogramming sadece framework yazarlarının işidir. Rails'in has_many veya validates macro'larının arkasında tam olarak bu mekanizmalar çalışır. Ruby'nin temellerini ve nesne modelini daha iyi kavramak için Ruby eğitimi içeriğinden yararlanabilirsiniz.

method_missing: Kancanın Gücü ve Tuzağı

Ruby bir nesne üzerinde tanımlı olmayan bir method çağrıldığında doğrudan hata fırlatmaz — önce method_missing kancasını çağırır. Bu kanca override edilirse, var olmayan method'lara dinamik tepki verilebilir. Pratik detaylar için proje sayfasını incelenebilir.

class DynamicFinder
  def method_missing(name, *args)
    if name.to_s.start_with?("find_by_")
      attribute = name.to_s.sub("find_by_", "")
      puts "#{attribute} ile arama yapılıyor: #{args.first}"
    else
      super
    end
  end

  def respond_to_missing?(name, include_private = false)
    name.to_s.start_with?("find_by_") || super
  end
end

Burada kritik nokta respond_to_missing? tanımıdır. Pek çok kişi sadece method_missing'i override eder; oysa bu durumda respond_to? yanlış cevap döner ve introspection araçları kırılır.

define_method: Açık Tanım Açık Yük

method_missing tüm çağrıları yakalar; define_method ise method'u önceden somut olarak tanımlar. İkisi arasındaki seçim performans ve okunabilirlik açısından kritiktir.

• method_missing: Her çağrıda lookup zincirini geçer, dispatch maliyeti yüksektir. Stack trace'lerde method adı görünmez.
• define_method: Method gerçekten tanımlanır, methods listesinde görünür, IDE autocomplete çalışır.
• def: Klasik yöntem; closure içinde değişken yakalayamaz, scope kapatır.

class Product
  [:name, :price, :stock].each do |attr|
    define_method("#{attr}_or_default") do
      instance_variable_get("@#{attr}") || "tanımsız"
    end
  end
end

Bu yaklaşım Active Record'un attribute accessor'larında, Sinatra'nın HTTP verb DSL'inde ve binlerce gem'de aynı kalıpla kullanılır.

Open Class: En Tehlikeli Özellik

Ruby'de bir sınıfı istediğin yerde yeniden açıp method ekleyebilirsin — buna "monkey patching" denir. String sınıfına to_slug method'u ekleyebilirsiniz, Integer'a days tanımlayabilirsiniz.

Ancak burada bakım yükü patlama yapar şu sebeplerle:

1. İki farklı gem aynı core sınıfa aynı method'u ekleyebilir; yükleme sırasına göre davranış değişir.
2. Standart kütüphane güncellemesi sizin tanımladığınız method'la çakışabilir.
3. Yeni gelen geliştirici "hello".to_slug görür, bunun Ruby core olduğunu sanır.

Bu yüzden Rails 5+ sürümünde Refinements tercih edilmeye başlandı: monkey patch yalnızca using bildirilen scope'ta aktif olur.

Bakım Yükü: Sihrin Görünmeyen Faturası

Metaprogramming yazmak kolay, okumak zordur. Dinamik tanımlanmış bir method için aşağıdakiler bozulur:

• Grep ile arama: grep -r "find_by_email" sonuç vermez çünkü string olarak inşa edilmiştir.
• IDE go-to-definition: Method gerçekte yoktur, statik analiz çuvallar.
• Stack trace okunabilirliği: (eval) veya boş satır referansları çıkar.
• Type checker araçları (Sorbet, RBS): Dinamik method'lar için manuel signature gerekir.

Ne Zaman Kullanmalı, Ne Zaman Kaçınmalı?

Genel kural: aynı kalıbı 3+ kez tekrarladığında ve değişkenliği runtime'a kalmışsa metaprogramming uygun olabilir. Tek seferlik kullanım için iki satır def her zaman daha okunur kalır.

Kullanmaya değer durumlar: DSL inşası (RSpec'in describe/it yapısı gibi), ORM attribute mapping'i, configuration DSL'leri. Kaçınılması gereken durumlar: iş mantığı koşullarını dinamik method'larla şifrelemek, debugging'i imkânsız hale getiren çok katmanlı method_missing zincirleri.

Ruby ekosisteminin derinliklerine inmek ve bu tekniklerin pratik uygulamalarını görmek için Ruby eğitimi içeriğini inceleyebilirsiniz.

Refinements: Modern Alternatif

Ruby 2.0 ile gelen Refinements, open class'ın global etkisini sınırlar. Bir module içinde refine ile değişiklik tanımlanır, sadece using çağrılan dosyada etkin olur.

module StringSlug
  refine String do
    def to_slug
      downcase.gsub(/s+/, "-")
    end
  end
end

class ArticleProcessor
  using StringSlug
  # burada "Merhaba Dünya".to_slug çalışır
end

Refinements henüz tüm topluluk tarafından benimsenmedi çünkü scope kuralları başlangıçta kafa karıştırıcıdır. Yine de büyük projelerde monkey patching yerine giderek standart hale geliyor.

Ruby metaprogramming'i öğrenmenin gerçek değeri, onu sürekli kullanmakta değil, hangi durumda kaçınılması gerektiğini anlamakta yatar. Bir method tanımının üç katına çıkan bakım maliyetini kabul ediyorsan kullan; etmiyorsan açık tanımla yaz. "Akıllı kod" yerine "anlaşılır kod" tercih eden ekipler uzun vadede daha az tükenir.