Arayüzü teorik olarak bir sözleşme gibi düşünebiliriz. Bir arayüz, “Beni uygulayan her yapı şu metotları, özellikleri veya davranışları sağlayacak” der. Ancak bunu nasıl yapacağını söylemez. Matematiksel olarak bir arayüzü, nesneler kümesinden davranışlar kümesine kurulan bir beklenti ilişkisi gibi görebiliriz: $I = {b_1, b_2, b_3}$ ise, bu arayüzü uygulayan her nesne bu davranışları sağlamalıdır. Burada önemli olan nesnenin iç yapısı değil, dışarıdan gözlemlenebilen davranışıdır.

Çok biçimlilik yani polymorphism ise aynı mesajın farklı nesnelerde farklı şekillerde çalışabilmesidir. Örneğin draw() çağrısı bir daireyi yuvarlak, bir kareyi köşeli çizer. Çağıran kod için önemli olan şeklin gerçek sınıfı değil, çizilebilir olmasıdır. Bu yaklaşım $Kod -> Arayüz$ bağımlılığını güçlendirir, $Kod -> SomutSınıf$ bağımlılığını azaltır.

Basit bir TypeScript örneği düşünelim:

interface Payable {
  calculatePayment(): number;
}

class Employee implements Payable {
  constructor(private salary: number) {}

  calculatePayment(): number {
    return this.salary;
  }
}

class Freelancer implements Payable {
  constructor(private hourlyRate: number, private hours: number) {}

  calculatePayment(): number {
    return this.hourlyRate * this.hours;
  }
}

function printPayment(entity: Payable): void {
  console.log('Ödeme: ' + entity.calculatePayment());
}

printPayment(new Employee(40000));
printPayment(new Freelancer(750, 32));

Burada printPayment fonksiyonu, parametrenin Employee ya da Freelancer olmasını umursamaz. Tek şartı vardır: Payable davranışını sağlaması. Bu fonksiyonun zihni oldukça rahattır; CV sormaz, sadece ödeme hesaplayabiliyor musun diye bakar.

Bu tasarımın gücü, Açık/Kapalı Prensibi ile birleştiğinde ortaya çıkar. Yazılım birimleri genişletmeye açık, değiştirmeye kapalı olmalıdır. Yeni bir Consultant sınıfı eklediğimizde printPayment fonksiyonunu değiştirmiyorsak doğru yoldayız demektir. Teorik olarak bu, sistemin yeni türler karşısında kararlı kalmasıdır: $YeniTip + EskiArayüz = DahaAzKırılma$.

Ancak arayüz kullanmak her derde deva büyülü bir iksir değildir. Gereksiz arayüzler, projede “soyutlama sisi” oluşturabilir. Eğer sadece tek bir sınıfınız varsa ve değişim ihtimali düşükse, hemen arayüz üretmek erken mühendislik olabilir. İyi arayüz, gerçek bir değişim eksenini temsil eder. Yani “ileride farklı ödeme stratejileri olabilir” diyorsanız Payable anlamlıdır; ama “belki bir gün kahve makinesi de ödeme hesaplar” diyorsanız biraz sakinleşmek gerekebilir.

Arayüzlerin bir diğer güzelliği testlerde görülür. Somut veritabanı bağlantısı yerine Repository arayüzüne bağımlı kod, test sırasında sahte bir bellek içi nesneyle çalışabilir. Böylece kodun davranışını izole ederiz. Bu da yazılımı daha ölçülebilir yapar; çünkü test maliyeti kabaca $Maliyet = Kurulum + Bağımlılık + Bekleme$ ise, arayüzler özellikle bağımlılık ve bekleme kısmını azaltır.

Sonuç olarak arayüzler, yazılım tasarımında kimlik kontrolünden davranış kontrolüne geçiştir. Çok biçimlilikle birleştiğinde, aynı kodun farklı nesnelerle uyumlu çalışmasını sağlar. Bu yaklaşım, gelecekte gelecek yeni sınıflara kapıyı açık bırakırken mevcut kodu sakin ve kararlı tutar. Kısacası iyi tasarlanmış bir arayüz şunu söyler: “Bana nereden geldiğini anlatma, ne yapabildiğini göster.”

Teorik Temel: Boyut mu, Esneklik mi?

Dizi, uzunluğu türünün parçası olan sabit boyutlu bir veri yapısıdır. Go’da [3]int ile [4]int farklı türlerdir. Yani derleyici için “3 elemanlı int dizisi” ile “4 elemanlı int dizisi” aynı ailenin kuzenleri bile değildir; tamamen ayrı kimliklere sahiptir.

Dilim ise kendi başına veriyi doğrudan taşımaz. Arkasında genellikle bir dizi bulunur ve dilim bu dizinin belirli bir aralığına referans verir. Bir slice üç parçalı küçük bir başlık gibi düşünülebilir:

• işaretçi: alttaki dizide başlangıç konumu,
• uzunluk: şu an görünen eleman sayısı,
• kapasite: başlangıçtan itibaren kullanılabilecek maksimum alan.

Matematiksel olarak temel kural şudur: $0 \le len(slice) \le cap(slice)$. Yani uzunluk kapasiteyi aşamaz; ama append ile kapasite yetmezse Go yeni ve daha büyük bir alttaki dizi ayırabilir.

Diziler: Sabit Boyutlu Disiplin

Diziler, özellikle boyutun kesin bilindiği durumlarda harikadır. Örneğin RGB renk değeri için [3]uint8 gayet anlamlıdır. Çünkü kırmızı, yeşil ve mavi olmak üzere tam üç kanal vardır; dördüncü eleman beklenmez.

func updateArray(a [3]int) {
    a[0] = 99
}

func main() {
    nums := [3]int{1, 2, 3}
    updateArray(nums)
    println(nums[0]) // 1
}

Bu örnekte updateArray fonksiyonuna dizi gönderildiğinde tüm dizi kopyalanır. Fonksiyon içindeki değişiklik dışarıdaki nums dizisini etkilemez. Bu davranış güvenlidir ama büyük dizilerde maliyetli olabilir. Eğer $n$ elemanlı bir dizi kopyalanıyorsa işlem maliyeti yaklaşık $O(n)$ olur.

Dilimler: Esnek ve Paylaşımcı Pencereler

Dilimlerde durum daha hareketlidir. Slice değeri kopyalansa bile alttaki dizi çoğu zaman aynı kalır. Bu yüzden bir fonksiyona slice gönderdiğinizde eleman değişiklikleri dışarıdan görülebilir.

func updateSlice(s []int) {
    s[0] = 99
}

func main() {
    nums := []int{1, 2, 3}
    updateSlice(nums)
    println(nums[0]) // 99
}

Burada s aslında slice başlığının kopyasıdır; fakat başlığın gösterdiği alttaki dizi aynıdır. Bu nedenle s[0] = 99, orijinal veriyi değiştirir. İşte slice’ların “referans gibi davranıyor” denmesinin sebebi budur. Tam anlamıyla referans türü demek yerine, “referans taşıyan küçük bir descriptor” demek daha doğrudur.

Append ve Kapasite Sürprizi

Slice’ların en eğlenceli tarafı append ile büyüyebilmesidir; ama burada küçük bir numara vardır. Kapasite yetiyorsa aynı alttaki dizi kullanılır. Yetmiyorsa yeni bir dizi oluşturulur ve elemanlar oraya taşınır.

func main() {
    a := []int{10, 20, 30}
    b := a[:2]

    b = append(b, 99)

    println(a[2]) // kapasite yeterse 99 olabilir
}

Bu örnekte b, a dizisinin ilk iki elemanını gösterir. Eğer b için kapasite yeterliyse append, üçüncü konuma 99 yazar ve a[2] de değişmiş gibi görünür. Bu, slice paylaşımının hem süper gücü hem de potansiyel tuzağıdır.

Ne Zaman Hangisi?

Boyut gerçekten sabitse ve bu bilgi programın anlamının parçasıysa array iyi seçimdir. Örneğin matris boyutu, kriptografik bloklar veya sabit protokol alanları buna uygundur. Ancak çoğu uygulama kodunda veri miktarı çalışma zamanında değişir: kullanıcı listeleri, dosyadan okunan satırlar, API sonuçları… Bu durumda slice çok daha pratiktir.

Kısa özetle: array, bellekte düzenli ve sabit bir apartman; slice ise bu apartmanın odalarına bakan esnek bir emlak danışmanıdır. Danışman hafiftir, kolay kopyalanır; ama hangi odayı gösterdiğini unutursanız yanlış duvarı boyayabilirsiniz. Go’da güçlü ve hatasız kod yazmanın yolu, bu küçük pencerenin arkasındaki büyük diziyi her zaman akılda tutmaktan geçer.

Basit bir matematiksel bakış atalım. Bir programın toplam süresi $T$ olsun. Eğer işin paralelleştirilebilir kısmı $p$, işlemci çekirdeği sayısı da $n$ ise Amdahl yasasına göre teorik hızlanma yaklaşık $Hiz = 1 / ((1-p)+p/n)$ olur. Yani her şeyi paralel yapamayız; ama doğru parçaları eşzamanlı tasarlarsak ciddi kazanç elde ederiz.

Bir goroutine başlatmak şaşırtıcı derecede kolaydır. Aşağıdaki örnekte selamVer fonksiyonu ana akıştan bağımsız çalışır. time.Sleep burada sadece örneğin bitmeden goroutine’in çıktısını görebilmemiz için kullanılır; gerçek projelerde genellikle sync.WaitGroup tercih edilir.

package main

import (
    "fmt"
    "time"
)

func selamVer(kim string) {
    for i := 1; i <= 3; i++ {
        fmt.Println("Merhaba", kim, i)
        time.Sleep(300 * time.Millisecond)
    }
}

func main() {
    go selamVer("Goroutine")

    fmt.Println("Ana program çalışıyor")
    time.Sleep(1 * time.Second)
}

Bu kodda go selamVer(...) satırı fonksiyonu yeni bir goroutine olarak çalıştırır. Ana program beklemek zorunda değildir; kendi yoluna devam eder. İşte goroutine’lerin hafifliği burada parlar: binlerce goroutine başlatmak, binlerce işletim sistemi thread’i açmaktan çok daha ekonomiktir.

Ancak süper güçlerin yan etkileri vardır. Birden fazla goroutine aynı veriye yazmaya çalışırsa yarış durumu, yani race condition oluşabilir. Mesela iki kişi aynı deftere aynı anda not almaya çalışırsa sonuç karışabilir. Go’da bu tür durumlar için channel, mutex ve WaitGroup gibi araçlar kullanılır.

package main

import (
    "fmt"
    "sync"
)

func isYap(id int, wg *sync.WaitGroup) {
    defer wg.Done()
    fmt.Println("İş başladı:", id)
}

func main() {
    var wg sync.WaitGroup

    for i := 1; i <= 5; i++ {
        wg.Add(1)
        go isYap(i, &wg)
    }

    wg.Wait()
    fmt.Println("Tüm işler tamamlandı")
}

Burada WaitGroup, ana programın tüm goroutine’ler bitene kadar beklemesini sağlar. wg.Add(1) yeni bir iş eklendiğini, defer wg.Done() işin tamamlandığını, wg.Wait() ise herkes dönene kadar beklenmesi gerektiğini söyler.

Go’nun scheduler’ı goroutine’leri işletim sistemi thread’leri üzerinde gezdirir. GOMAXPROCS değeri aynı anda kaç OS thread’in Go kodu çalıştırabileceğini belirler. Modern Go sürümlerinde bu değer genellikle makinedeki CPU çekirdeği sayısına göre otomatik ayarlanır. Yani çoğu zaman ayar yapmadan çok çekirdekli gücü kullanmaya başlarsınız.

Sonuç olarak goroutine, Go’nun en keyifli ve güçlü özelliklerinden biridir. Ama amaç her yere go yazmak değildir. Doğru soru şudur: Bu işler bağımsız mı, bekleme içeriyor mu, sonuçlar güvenli şekilde birleşiyor mu? Cevap evetse goroutine’ler uygulamanıza roket takabilir. Cevap hayırsa, roket yerine mutfakta havai fişek yakmış olabilirsiniz.

Teorik olarak problem şudur: Birden fazla yürütme birimi aynı belleğe erişirse ve en az biri yazma yaparsa, sonuç zamana bağlı hale gelir. Buna race condition deriz. Basitçe ifade edersek, iki işlem $A$ ve $B$ için belirli bir sıra garanti edilmiyorsa sonuç $A \rightarrow B$ veya $B \rightarrow A$ olabilir. Kanallar ise bu sırayı veri alışverişi üzerinden tanımlar. Bir gönderme işlemi, ilgili alma işlemi tamamlanmadan anlamlı biçimde bitmez. Bu da Go bellek modelinde bir tür happens-before ilişkisi oluşturur: $send(x) \rightarrow receive(x)$.

En basit kanal örneğiyle başlayalım:

package main

import "fmt"

func main() {
    mesajlar := make(chan string)

    go func() {
        mesajlar <- "Merhaba kanal!"
    }()

    msg := <-mesajlar
    fmt.Println(msg)
}

Burada make(chan string) ifadesi string taşıyan bir kanal oluşturur. mesajlar <- ... gönderme, <-mesajlar ise alma işlemidir. Dikkat çekici nokta şudur: Varsayılan yani unbuffered kanal, gönderici ve alıcıyı buluşturur. Gönderen goroutine, biri veriyi alana kadar bekler. Bu davranış, kanalın yalnızca veri taşımasını değil, aynı zamanda senkronizasyon aracı olmasını sağlar.

Kanalları matematiksel olarak küçük bir kuyruk gibi düşünebiliriz. Kapasite $k$ ise kanalda aynı anda en fazla $k$ eleman bulunur. Unbuffered kanal için $k = 0$ kabul edilir; yani veri bekleme salonunda oturamaz, doğrudan teslim edilmelidir.

package main

import "fmt"

func main() {
    kuyruk := make(chan int, 2)

    kuyruk <- 10
    kuyruk <- 20

    fmt.Println(<-kuyruk)
    fmt.Println(<-kuyruk)
}

Bu örnekte kanalın kapasitesi 2’dir. İlk iki gönderim bloklanmaz; çünkü tamponda yer vardır. Ancak üçüncü bir gönderim yapılsaydı ve kimse okumuyorsa program beklemeye başlardı. Bu noktada kanal tasarımı önem kazanır: tampon, performans için faydalıdır ama yanlış kullanılırsa hatayı sadece biraz geciktiren yumuşak bir yastığa dönüşebilir.

Birden fazla kanalı dinlemek için Go’nun eğlenceli kontrol kulesi select kullanılır:

package main

import (
    "fmt"
    "time"
)

func main() {
    hizli := make(chan string)
    yavas := make(chan string)

    go func() {
        time.Sleep(500 * time.Millisecond)
        hizli <- "hızlı veri geldi"
    }()

    go func() {
        time.Sleep(1 * time.Second)
        yavas <- "yavaş veri geldi"
    }()

    for i := 0; i < 2; i++ {
        select {
        case msg := <-hizli:
            fmt.Println(msg)
        case msg := <-yavas:
            fmt.Println(msg)
        }
    }
}

select, hazır olan kanal işlemini seçer. Bu yapı özellikle timeout, iptal sinyali ve fan-in/fan-out desenlerinde çok kullanışlıdır. Örneğin bir işi sonsuza kadar beklemek yerine time.After ile süre sınırı koyabilirsin.

Kanallar güçlüdür ama sihirli değnek değildir. Alıcısı olmayan kanala veri göndermek, göndericisi olmayan kanaldan okumak veya hiç kapanmayan kanalı range ile tüketmek deadlock’a yol açabilir. Kanalı kapatmak için close(ch) kullanılır; fakat kural basittir: Genellikle kanalı gönderen taraf kapatır, alan taraf değil.

Sonuç olarak Go kanalları, eşzamanlı programlamayı daha okunabilir bir hikâyeye çevirir. Mutex ile “bu veriye kim dokunuyor?” diye düşünürken, kanallarla “bu veri kime gidiyor?” diye sorarsın. Bu bakış açısı özellikle karmaşık sistemlerde zihinsel yükü azaltır. Goroutine’ler mini karakterlerse, kanallar onların telsiz hattıdır; doğru frekansı ayarlarsan ekip uyum içinde çalışır.

Go’da metot, teknik olarak bir fonksiyondur; fakat özel bir parametreye sahiptir: receiver. Receiver, metodun hangi tipe aitmiş gibi çağrılacağını belirler. Matematiksel olarak düşünürsek, normal bir fonksiyon şöyle modellenebilir: $f(x) \rightarrow y$. Metotta ise fonksiyon, belirli bir veri tipinin bağlamında çalışır: $T.f(x) \rightarrow y$. Buradaki $T$, örneğin bir User, Account veya Rectangle struct’ı olabilir.

Basit bir örnekle başlayalım:

package main

import "fmt"

type Rectangle struct {
    Width  float64
    Height float64
}

func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

func main() {
    box := Rectangle{Width: 10, Height: 5}
    fmt.Println(box.Area())
}

Burada (r Rectangle) kısmı receiver’dır. Yani Area metodu, Rectangle tipine bağlanmıştır. Artık Area(box) yazmak yerine daha doğal bir şekilde box.Area() yazarız. Kodun okunabilirliği artar; çünkü davranış, ilgili veri yapısının yanında durur.

Receiver iki şekilde tanımlanabilir: value receiver ve pointer receiver. Value receiver, struct’ın bir kopyası üzerinde çalışır. Pointer receiver ise orijinal veriye erişir ve onu değiştirebilir.

type Account struct {
    Owner   string
    Balance float64
}

func (a Account) CurrentBalance() float64 {
    return a.Balance
}

func (a *Account) Deposit(amount float64) {
    if amount <= 0 {
        return
    }
    a.Balance += amount
}

CurrentBalance yalnızca okuma yaptığı için value receiver yeterlidir. Deposit ise bakiyeyi değiştirdiği için pointer receiver kullanır. Eğer para yatırma işlemini formülle ifade edersek: $bakiye_{yeni} = bakiye_{eski} + miktar$. Bu işlemde eski değerin gerçekten güncellenmesi gerekir; kopya üzerinde çalışmak işe yaramaz.

Go’nun burada sunduğu güzellik şudur: Nesne yönelimli programlamadaki “nesne davranış taşır” fikrini alır, ama sınıf hiyerarşisi karmaşasını dayatmaz. Bir struct veri modelini temsil eder, metotlar ise bu veri modeline ait davranışları ifade eder. Yani Go şunu der: “Veriyi ayrı düşün, davranışı açıkça bağla.”

Klasik OOP ile Go yaklaşımını karşılaştıralım:

Receiver adı genellikle kısa seçilir: u User, r Rectangle, a Account gibi. Go topluluğu this veya self benzeri isimler kullanmayı önermez. Çünkü receiver zaten bağlamı açıkça gösterir. Ayrıca aynı tipe ait metotlarda receiver adını tutarlı seçmek kodun ritmini güzelleştirir.

Biraz daha gerçekçi örnek düşünelim:

type Task struct {
    Title     string
    Completed bool
}

func (t *Task) Complete() {
    t.Completed = true
}

func (t Task) Status() string {
    if t.Completed {
        return "tamamlandı"
    }
    return "bekliyor"
}

Bu örnekte Task, sadece iki alanlı basit bir veri yapısıdır. Ancak Complete ve Status metotlarıyla birlikte artık küçük bir davranış modeline dönüşür. Kod başka bir yerde task.Complete() gördüğünde niyet hemen anlaşılır: görev tamamlanıyor.

Sonuç olarak Go’daki metot ve receiver sistemi, nesne yönelimli düşüncenin pratik tarafını korur: veriyle ilişkili davranışları bir araya getirir. Fakat bunu sınıf, kalıtım ve karmaşık hiyerarşiler olmadan yapar. Eğer bir struct’ın “ne olduğunu” alanları belirliyorsa, “ne yapabildiğini” de metotları belirler. Go’nun felsefesi de tam burada parlar: az sihir, çok netlik.

Map Mantığı Nedir?

Map, temel olarak şu fikre dayanır: Her değerin bir anahtarı vardır. Matematiksel olarak bunu bir eşleme fonksiyonu gibi düşünebiliriz:

$f: K \rightarrow V$

Burada $K$ anahtarlar kümesini, $V$ ise değerler kümesini temsil eder. Örneğin bir kullanıcı sisteminde kullaniciAdi -> profilBilgisi şeklinde bir ilişki kurabiliriz.

Dizilerde verilere genellikle indeksle ulaşırız:

const renkler = ['kirmizi', 'mavi', 'yesil'];
console.log(renkler[1]); // mavi

Ama indeksler her zaman anlamlı değildir. renkler[1] ifadesi çalışır, fakat 1 sayısı bize iş kuralı hakkında pek bir şey söylemez. Map ile anahtarları kendimiz belirleyebiliriz.

const renkKodlari = new Map();
renkKodlari.set('hata', 'kirmizi');
renkKodlari.set('basari', 'yesil');
renkKodlari.set('uyari', 'sari');

console.log(renkKodlari.get('basari')); // yesil

Burada basari anahtarı, yesil değerine karşılık gelir. Kod artık yalnızca çalışmakla kalmaz, aynı zamanda hikâye anlatır.

Dizi, Nesne ve Map Karşılaştırması

Map yapısının güzel tarafı, anahtar olarak yalnızca string değil, nesne, fonksiyon hatta başka bir Map bile kullanabilmesidir. Bu, özellikle cache, kullanıcı oturumu, ayar yönetimi ve oyun içi envanter gibi senaryolarda çok işe yarar.

Temel İşlemler: Ekleme, Arama, Silme

Bir Map üzerinde en sık kullanılan işlemler şunlardır:

const sepet = new Map();

// Ekleme veya güncelleme
sepet.set('elma', 3);
sepet.set('muz', 5);
sepet.set('elma', 4); // elma miktarı güncellendi

// Arama
console.log(sepet.has('muz')); // true
console.log(sepet.get('elma')); // 4

// Silme
sepet.delete('muz');

// Boyut
console.log(sepet.size); // 1

set metodu hem yeni kayıt ekler hem de aynı anahtar varsa değeri günceller. get değeri getirir, has anahtarın varlığını kontrol eder, delete ise eşleşmeyi kaldırır.

Performans Açısından Neden Önemli?

Map yapıları çoğu programlama dilinde hash table benzeri bir altyapıyla uygulanır. Bu nedenle ortalama durumda arama, ekleme ve silme işlemleri yaklaşık olarak $O(1)$ karmaşıklığındadır. Yani koleksiyon büyüse bile işlem süresi genellikle dramatik biçimde artmaz.

Elbette bu teorik bir ortalamadır. Kötü hash dağılımı gibi özel durumlarda maliyet artabilir. Ancak pratikte Map, özellikle sık arama yapılan yapılarda diziye göre daha uygun olabilir. Bir dizide elemanı bulmak için tek tek dolaşmak gerekirse maliyet $O(n)$ olur.

Küçük Bir Örnek: Kullanıcı Oturumları

const oturumlar = new Map();

function oturumAc(token, kullanici) {
  oturumlar.set(token, {
    ad: kullanici,
    baslangic: Date.now()
  });
}

function oturumKontrol(token) {
  if (!oturumlar.has(token)) {
    return 'Oturum bulunamadi';
  }

  const oturum = oturumlar.get(token);
  return `${oturum.ad} aktif`;
}

function oturumKapat(token) {
  return oturumlar.delete(token);
}

oturumAc('abc123', 'Ada');
console.log(oturumKontrol('abc123'));
oturumKapat('abc123');

Bu örnekte token anahtar, kullanıcı oturum bilgisi ise değerdir. Böylece her oturuma hızlıca erişebiliriz.

Ne Zaman Map Kullanmalı?

Eğer verilerin doğal bir anahtarı varsa, sık sık arama yapıyorsan veya anahtarların string dışında türler olmasını istiyorsan Map iyi bir seçimdir. Sadece sıralı bir liste tutuyorsan dizi daha uygundur. Sabit yapılı bir veri modeli için ise nesne veya sınıf daha okunabilir olabilir.

Kısacası Map, veriye anlamlı bir kapı etiketi takmaktır. İndekslerin soğuk apartman numaralarından sıkıldıysan, anahtar-değer dünyasına hoş geldin!

Hata bir olay değil, bir değerdir

Go’nun hata yönetimi felsefesi basittir: Fonksiyonlar başarılı sonucu ve hata bilgisini birlikte döndürebilir. Tipik imza şuna benzer:

func Oku(path string) ([]byte, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("dosya okunamadı: %w", err)
    }
    return data, nil
}

Burada error, özel bir büyü değil; Error() string metoduna sahip bir arayüzdür. Matematiksel düşünürsek fonksiyon sonucu şöyle modellenebilir: $(T, E)$; burada $T$ beklenen veri, $E$ ise hata durumudur. Başarı halinde $E = nil$, hata halinde çoğu zaman $T$ kullanılmaz. Akış şu denklemle okunabilir: $P(başarı) + P(hata) = 1$. Yani fonksiyon ya düzgün sonuç üretir ya da neden üretemediğini açıkça bildirir.

İstisna mı, değer mi?

Bu tablo Go’nun neden “hata varsa söyle, saklama” dediğini gösterir. Kod biraz daha uzun görünür; evet, if err != nil satırları çoğalır. Ama karşılığında fonksiyonun başarısız olabileceği yerler neon tabela gibi görünür.

Error wrapping: Hatanın dedikodu zinciri

Hata mesajını sadece “olmadı” diye döndürmek, kullanıcıya “bir şeyler ters gitti” demek gibidir; doğru ama pek faydalı değildir. Go’da %w ile hata sarmalanabilir:

func AyarYukle() error {
    err := VeritabaniBaglan()
    if err != nil {
        return fmt.Errorf("ayar yükleme başarısız: %w", err)
    }
    return nil
}

Bu sayede üst katman hem bağlamı görür hem de errors.Is veya errors.As ile kök hatayı inceleyebilir. Böylece hata, apartman dedikodusu gibi kat kat dolaşır ama kimden çıktığı da bellidir.

Peki panic ne zaman?

panic, “bu fonksiyon beklenen bir hata yaşadı” demek değildir. Daha çok “programın varsayımları çöktü” anlamına gelir. Örneğin imkânsız olması gereken bir durum gerçekleştiyse, başlatma sırasında kritik yapılandırma yoksa veya bellek dışı tutarsızlık oluştuysa kullanılabilir.

Recover: Panik odasının yangın çıkışı

recover, yalnızca defer içinde çağrıldığında aktif bir panici yakalayabilir. Bu mekanizma exception yakalamaya benzese de Go’da günlük hata yönetimi için önerilmez; daha çok sınır katmanlarında, örneğin HTTP sunucusunda tek bir isteğin tüm sistemi devirmesini engellemek için kullanılır.

func GuvenliCalistir(fn func()) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("panic yakalandı: %v", r)
        }
    }()

    fn()
}

Bu kod, verilen fonksiyonu çalıştırır; içeride panic olursa program tamamen yere kapaklanmadan önce durumu loglar. Ancak dikkat: recover hatayı yok etmez, sadece kontrolü geri verir. Verinin tutarlı olup olmadığını hâlâ sen düşünmelisin.

Pratik tasarım önerileri

1. Beklenen başarısızlıkları error olarak döndür.
2. Hatalara bağlam ekle: “bağlanamadı” yerine “kullanıcı profili yüklenirken veritabanına bağlanılamadı” daha değerlidir.
3. panici kontrol akışı için kullanma; if err != nil sıkıcı olabilir ama güvenilirdir.
4. recoveri uygulama sınırlarında kullan: HTTP middleware, worker supervisor, CLI komut sarmalayıcıları gibi.

Sonuç olarak Go’nun hata yönetimi şunu öğretir: Hata, utanılacak bir istisna değil, sistemin konuşma biçimidir. Onu değer olarak döndürdüğünde programın daha tahmin edilebilir, test edilebilir ve bakım yapılabilir olur. panic ise sahneye nadiren çıkan duman makinesi gibidir; doğru anda dramatik, yanlış anda tüm gösteriyi mahveder.

Struct nedir?

Struct, birden fazla veriyi tek bir özel tip altında toplamanızı sağlayan bir yapıdır. Sınıfa benzer görünür; alanları, metotları ve özellikleri olabilir. Ancak birçok dilde struct kavramsal olarak daha hafif, daha doğrudan ve veri merkezlidir. Özellikle C, C++, C# ve Rust gibi dillerde struct, bellekteki verinin düzenini anlamak açısından çok önemlidir.

Basit bir örnekle başlayalım:

public struct Health
{
    public int Current;
    public int Maximum;

    public float Ratio
    {
        get { return (float)Current / Maximum; }
    }
}

Bu struct, bir karakterin can bilgisini taşır. Current ve Maximum ayrı ayrı değişkenler olabilirdi; fakat birlikte anlamlı oldukları için tek bir tip altında toplanmaları kodu daha okunabilir yapar.

Struct ile class arasındaki temel farklar

Her dilde ayrıntılar değişebilir ama genel düşünce şudur: class çoğu zaman kimlik ve davranış odaklıdır, struct ise veri odaklıdır.

Örneğin bir oyun motorunda Position, Velocity, Health gibi tipler struct olmaya çok uygundur. Buna karşılık InventoryManager veya PaymentService gibi davranış yönü ağır bileşenler class olarak daha anlamlıdır.

Veri odaklı tasarımın mantığı

Veri odaklı tasarım, programı önce verinin şekline ve işlenme biçimine göre düşünmektir. Geleneksel nesne yönelimli yaklaşımda sıkça şu soru sorulur: Bu nesnenin hangi metotları var? Veri odaklı yaklaşım ise şunu sorar: Hangi veriyi, hangi sırayla, ne kadar sık işleyeceğim?

Performans açısından kritik nokta bellek erişimidir. Modern işlemciler veriyi tek tek sihirli şekilde değil, cache line denilen bloklarla okur. Basitçe düşünürsek:

$T \approx N \times C_{access}$

Burada $N$ erişilen veri sayısı, $C_{access}$ ise her erişimin maliyetidir. Eğer veriler bellekte dağınıksa $C_{access}$ artar. Veriler ardışık ve kompakt ise işlemci cache daha verimli çalışır.

Struct ile daha düzenli veri modeli

Diyelim ki çok sayıda karakterin sağlık bilgisini güncelliyoruz:

public struct PlayerStats
{
    public int Health;
    public int Armor;
    public float Speed;
}

public static void ApplyDamage(ref PlayerStats stats, int damage)
{
    int reduced = damage - stats.Armor;
    if (reduced < 0) reduced = 0;
    stats.Health -= reduced;
}

Burada PlayerStats, karaktere ait temel sayısal değerleri bir araya getirir. ApplyDamage fonksiyonu ise struct üzerinde işlem yapar. ref kullanımı, bazı dillerde veya senaryolarda kopyalama maliyetini azaltmak için tercih edilir. Çünkü struct değer gibi taşındığında kopyalanabilir; küçük structlarda bu harika, büyük structlarda ise dikkat gerektirir.

Struct seçerken dikkat edilmesi gerekenler

Struct kullanmak her derde deva değildir. Küçük ve değişmez veri tiplerinde çok güçlüdür; fakat devasa veri paketleri oluşturursanız kopyalama maliyeti can sıkabilir. Pratik bir sezgi olarak, struct veri taşımalı; karmaşık yaşam döngüsü, miras hiyerarşisi veya yoğun davranış gerekiyorsa class düşünülmelidir.

Sonuç

Structs, programlamada veriyi ciddiye almanın zarif yollarından biridir. Sınıflar dünyayı nesneler ve davranışlarla anlatırken, structlar küçük veri gerçekliklerini net ve kompakt biçimde ifade eder. Veri odaklı tasarımda amaç, kodu sadece güzel göstermek değil, verinin bellekte nasıl yaşadığını da hesaba katmaktır. Kısacası: Eğer programınız bir mutfaksa, classlar aşçı olabilir; structlar ise düzenli kesilmiş malzemelerdir. Lezzetli ve hızlı yemek için ikisine de ihtiyaç vardır, ama hangi malzemenin nerede durduğunu bilmek oyunu değiştirir.

Önce modülü etkinleştirelim:

sudo modprobe snd-aloop
aplay -l
arecord -l

Kalıcı yapmak için /etc/modules-load.d/alsa-loopback.conf içine şu satır eklenebilir:

snd-aloop

Ses zincirimiz teorik olarak şöyle çalışır:

Gerçek zamanlı ses işlemede en önemli denklem gecikmedir. Örnekleme frekansı $f_s$ ve tampon boyutu $N$ ise tek tampon gecikmesi yaklaşık şöyledir:

$L = \frac{N}{f_s}$

Örneğin $N=256$ ve $f_s=48000$ için $L \approx 5.3ms$ olur. Bu değer küçükse pedal hızlı tepki verir; ancak çok küçültürsek CPU yetişemez ve çıtırtılar başlar. Yani düşük gecikme ile kararlılık arasında tatlı bir denge ararız.

Yankı efekti temelde gecikmiş sinyalin tekrar karıştırılmasıdır:

$y[n] = x[n] + g \cdot x[n-D]$

Burada $D$ gecikme örneği, $g$ ise geri besleme veya karışım miktarıdır. Pitch değiştirme ise daha hilelidir; sesi hızlandırıp/yavaşlatmak perdeyi değiştirir ama süreyi de bozar. Basit bir pedal prototipinde kısa tamponlar üzerinde yeniden örnekleme kullanabiliriz. Profesyonel sonuç için phase vocoder veya granular yöntemler tercih edilir.

Aşağıdaki Python örneği, sounddevice ile girişten ses alır, basit yankı ekler ve pitch için yeniden örnekleme tabanlı kaba bir yaklaşım uygular. Üretim ortamında JACK/PipeWire daha esnek olabilir; fakat ALSA mantığını kavramak için bu örnek yeterli bir laboratuvardır.

import numpy as np
import sounddevice as sd
from scipy.signal import resample

fs = 48000
block = 512
delay_ms = 280
delay_samples = int(fs * delay_ms / 1000)
feedback = 0.35
mix = 0.55
pitch_ratio = 1.12  # 1.0 normal, >1 tiz, <1 pes

delay_buffer = np.zeros(delay_samples, dtype=np.float32)
write_pos = 0

def pitch_shift_simple(x, ratio):
    # Kısa bloğu yeniden örnekleyerek perdeyi kaba şekilde değiştirir.
    # Sonra tekrar eski blok boyuna getirir.
    if ratio == 1.0:
        return x
    n = len(x)
    stretched = resample(x, max(1, int(n / ratio)))
    shifted = resample(stretched, n)
    return shifted.astype(np.float32)

def callback(indata, outdata, frames, time, status):
    global write_pos, delay_buffer
    if status:
        print(status)

    x = indata[:, 0].astype(np.float32)
    pitched = pitch_shift_simple(x, pitch_ratio)
    y = np.zeros_like(pitched)

    for i, sample in enumerate(pitched):
        delayed = delay_buffer[write_pos]
        y[i] = sample * (1 - mix) + delayed * mix
        delay_buffer[write_pos] = sample + delayed * feedback
        write_pos = (write_pos + 1) % delay_samples

    outdata[:, 0] = y

with sd.Stream(channels=1, samplerate=fs, blocksize=block, callback=callback):
    print("Efekt pedalı çalışıyor. Durdurmak için Ctrl+C.")
    while True:
        sd.sleep(1000)

Bu kodda delay_buffer geçmiş sesi saklayan dairesel hafızadır. write_pos sona gelince başa döner; böylece sonsuz uzunlukta dizi kullanmadan yankı üretiriz. Pitch kısmı bilerek sade tutuldu: amaç algoritmanın iskeletini görmek. Daha pürüzsüz sonuç için pencereleme, overlap-add ve faz sürekliliği gerekir.

ALSA loopback yönlendirmesi için pavucontrol, PipeWire patchbay araçları veya doğrudan .asoundrc kullanılabilir. Basit testlerde mikrofonu Python uygulamasına giriş, uygulama çıkışını da Loopback oynatma cihazına vermek yeterlidir. Ardından OBS, DAW veya başka bir kayıt aracı Loopback yakalama tarafını dinleyebilir.

Sonuçta ALSA loopback bize sanal kabloyu, Python/DSP kodu ise pedalın elektronik devresini verir. Birkaç parametreyi MIDI kontrolcüye bağlayarak gerçek bir sahne pedalına yaklaşabilir; hatta zincire distortion, chorus ve compressor ekleyerek Linux tabanlı kendi mini efekt istasyonunuzu kurabilirsiniz.

``

Statik tip sisteminde bir değişkenin tipi çalışma zamanında rastgele değişmez; çoğu karar derleme aşamasında verilir. Yani program henüz çalışmadan önce derleyici şunu sorar: “Bu değişkene gerçekten bu değer atanabilir mi?” Eğer cevap hayırsa, program daha başlangıç çizgisine gelmeden uyarı alırız. Bu, özellikle büyük projelerde süper güç gibidir; çünkü hatayı kullanıcı değil, derleyici yakalar.

Basit düşünelim: int tam sayıları, double ondalıklı sayıları, string metinleri, bool ise doğru/yanlış değerlerini taşır. Matematiksel olarak bir tipin alabileceği değerleri bir küme gibi düşünebiliriz. Örneğin 32 bitlik işaretli bir tam sayı yaklaşık olarak şu aralıktadır: $-2^{31}$ ile $2^{31}-1$ arası. Bu aralığın dışındaki bir değeri int içine koymaya çalışmak, küçük bir bavula piyano sığdırmaya benzer.

Statik tipli dillerde tipleri her zaman uzun uzun yazmak zorunda değiliz. Burada otomatik tip belirleme, yani type inference devreye girer. Derleyici sağ taraftaki değere bakarak sol taraftaki değişkenin tipini çıkarır. Ancak bu, değişkenin tipsiz olduğu anlamına gelmez; sadece tipi bizim yerimize derleyici yazar.

var count = 10;        // Derleyici bunu int olarak belirler
var price = 19.99;     // double
var name = "Ada";      // string
var isActive = true;   // bool

// count = "on";       // Hata: count artık int kabul edilir

Bu örnekte var, “ne olursa olsun kabul et” demek değildir. Daha çok “tipi sağ taraftan anla ama sonra sıkı denetle” demektir. Yani type inference, statik tip sistemini zayıflatmaz; sadece daha az klavye mesaisi sağlar.

Tip dönüşümleri ise iki ana gruba ayrılır: örtük ve açık dönüşüm. Örtük dönüşüm güvenli kabul edilen, veri kaybı beklenmeyen durumlarda yapılır. Açık dönüşümde ise programcı sorumluluğu üstlenir: “Evet, bunun riskli olabileceğini biliyorum.”

int small = 42;
long big = small; // Örtük dönüşüm: int değeri long içine rahatça sığar

double ratio = 9.75;
int roundedDown = (int)ratio; // Açık dönüşüm: sonuç 9 olur

Buradaki dönüşümde $9.75 \rightarrow 9$ olur; yani bilgi kaybı yaşanır. Bu yüzden açık dönüşümler kodda küçük bir sarı ikaz levhası gibi okunmalıdır. “Burada bilinçli bir karar var” mesajı verir.

Kullanıcıdan veya dosyadan gelen veriler genellikle metindir. Bu metni sayıya çevirmek için doğrudan parse etmek yerine güvenli yöntemler tercih edilmelidir.

string input = "123";

if (int.TryParse(input, out int number))
{
    int result = number * 2;
    Console.WriteLine(result);
}
else
{
    Console.WriteLine("Geçerli bir sayı girilmedi.");
}

TryParse, programı patlatmadan sonucu kontrol etmemizi sağlar. Kullanıcı abc yazarsa uygulama dramatik bir tiyatro sahnesi gibi çökmez; sadece uygun mesajı verir.

Bazı diller taşma kontrolleri için özel mekanizmalar sunar. Örneğin çok büyük bir sayıyı küçük tipe çevirirken değer aralığı aşılabilir. Bu durumda $x \notin [min, max]$ ise dönüşüm güvenli değildir.

checked
{
    int max = int.MaxValue;
    // int overflow = max + 1; // Taşma hatası üretir
}

Özetle değişkenler veriyi taşır, veri tipleri bu verinin kurallarını belirler, statik tip sistemi de oyunun hakemi gibi yanlış pasları erkenden düdükler. Type inference kodu sadeleştirirken güvenliği korur. Tip dönüşümlerinde ise temel soru hep aynıdır: “Bu değer hedef tipe kayıpsız ve anlamlı biçimde sığar mı?” Bu soruyu alışkanlık haline getirmek, daha sağlam ve okunabilir programlar yazmanın en pratik yollarından biridir.