``

Sabit Dizi ile Dinamik Vektör Arasındaki Fark

Sabit bir dizinin boyutu oluşturulurken belirlenir ve sonradan değiştirilemez. Daha fazla elemana ihtiyaç duyulursa daha büyük bir alan ayırmak, eski elemanları kopyalamak ve önceki alanı serbest bırakmak gerekir. Vektör bütün bu işleri otomatikleştiren bir soyutlamadır.

Vektör nesnesinin kendisi stack üzerinde bulunabilir; ancak elemanların tutulduğu büyük ve bitişik bellek bloğu heap üzerinde ayrılır. Nesne genellikle üç önemli bilgi taşır: veri bloğunun adresi, mevcut eleman sayısı ve ayrılmış toplam kapasite.

Boyut ve Kapasite Aynı Şey Değildir

Vektörün size değeri gerçekten kullanılan eleman sayısını, capacity değeri ise yeniden bellek ayırmadan saklayabileceği eleman sayısını gösterir. Her eklemede bellek istemek pahalı olacağı için kapasite çoğunlukla ihtiyaçtan büyük tutulur.

Kapasite dolduğunda daha büyük bir blok ayrılır. Yaygın büyüme stratejilerinden biri kapasiteyi yaklaşık iki katına çıkarmaktır:

Ardından mevcut elemanlar yeni alana kopyalanır veya taşınır, eski heap bloğu serbest bırakılır ve yeni eleman eklenir. Bu yeniden yerleştirme tek seferde $O(n)$ maliyetli olsa da her eklemede gerçekleşmez. Bu nedenle sona ekleme işleminin amortize edilmiş zaman karmaşıklığı $O(1)$ kabul edilir.

C++ ile Vektörü Gözlemlemek

Aşağıdaki örnek, eleman eklendikçe boyut ve kapasitenin nasıl değiştiğini gösterir:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> sayilar;

    for (int i = 1; i <= 10; ++i) {
        sayilar.push_back(i * 10);
        std::cout << "Boyut: " << sayilar.size()
                  << ", Kapasite: " << sayilar.capacity()
                  << '\n';
    }
}

push_back, elemanı sona ekler. Kapasite yeterliyse işlem doğrudan yapılır. Yeterli değilse yeni heap alanı ayrılır ve elemanlar taşınır. Kapasitenin büyüme oranı C++ standardında kesin olarak belirtilmediğinden sonuç kullanılan kütüphane uygulamasına göre değişebilir.

Önceden Yer Ayırmak

Kaç eleman ekleneceği yaklaşık olarak biliniyorsa reserve kullanmak gereksiz yeniden ayırmaları önler:

std::vector<int> puanlar;
puanlar.reserve(1000); // En az 1000 elemanlık kapasite hazırlar.

for (int i = 0; i < 1000; ++i) {
    puanlar.push_back(i);
}

reserve, vektörün boyutunu değiştirmez; yalnızca kapasite ayırır. Buna karşılık resize, eleman sayısını değiştirir ve gerekirse yeni elemanlar oluşturur.

Dikkat: İşaretçiler Geçersizleşebilir

Yeniden bellek ayırma gerçekleştiğinde eski bloğu gösteren işaretçiler, referanslar ve iterator’lar geçersiz hale gelebilir. Artık tahliye edilmiş bir evin adresine kargo göndermek gibi düşünün: adres tanıdık görünür, fakat içeride kimse yoktur.

Vektörler hız, bitişik bellek düzeni ve esneklik arasında güçlü bir denge kurar. Yine de bu rahatlığın arkasında kapasite fazlası, taşıma maliyeti ve referans geçersizleşmesi bulunur. size, capacity, reserve ve yeniden ayırma mantığını bilmek, dinamik koleksiyonları yalnızca kullanmayı değil, verimli ve güvenli kullanmayı sağlar.

``

Jeneriklerin Temel Mantığı

Jenerik programlamada somut bir tip yerine tip parametresi kullanılır. Genellikle T, U, Element veya Value gibi isimlerle gösterilen bu parametre, kod kullanılırken gerçek bir tipe dönüşür.

Örneğin iki değerin yerini değiştiren işlemi her veri tipi için ayrı yazmak gereksizdir. Swift ile jenerik sürümü şöyle tanımlanabilir:

func yerDegistir<T>(_ ilk: inout T, _ ikinci: inout T) {
    let gecici = ilk
    ilk = ikinci
    ikinci = gecici
}

var x = 10
var y = 20
yerDegistir(&x, &y)

var ad1 = "Ada"
var ad2 = "Linus"
yerDegistir(&ad1, &ad2)

Buradaki T, çağrı sırasında Swift tarafından belirlenir. İlk çağrıda Int, ikinci çağrıda String olur. Fonksiyonun gövdesi ise yalnızca bir kez yazılmıştır.

Kod tekrarının yaklaşık maliyetini $C_{tekrar} = n \times m$ şeklinde düşünebiliriz. Burada $n$ desteklenen tip sayısı, $m$ ise her uygulamanın bakım maliyetidir. Jenerik yaklaşımda bu maliyet ideal olarak $C_{jenerik} \approx m$ seviyesine iner.

Jenerik ve Geleneksel Yaklaşım

Jenerikler, Any kullanmakla aynı şey değildir. Any, farklı tipleri kabul ederken tip hakkındaki bilgiyi büyük ölçüde çalışma zamanına bırakır. Jenerikler ise derleme zamanında gerçek tipi korur. Bu nedenle yanlış tip kullanımları program çalışmadan yakalanabilir.

Jenerik Yapılar

Bir yığın veri yapısı yalnızca sayılarla çalışmak zorunda değildir. Kitaplar, kullanıcılar veya uzay gemileri de aynı yığına eklenebilir; tabii aynı örnek içinde eleman tipi tutarlı olmak şartıyla.

struct Yigin<Element> {
    private var elemanlar: [Element] = []

    mutating func ekle(_ eleman: Element) {
        elemanlar.append(eleman)
    }

    mutating func cikar() -> Element? {
        elemanlar.popLast()
    }
}

var sayilar = Yigin<Int>()
sayilar.ekle(42)
sayilar.ekle(7)

var diller = Yigin<String>()
diller.ekle("Swift")
diller.ekle("Rust")

Element, yığının saklayacağı tipi temsil eder. Aynı yapı tanımıyla sınırsız sayıda tip için güvenli yığınlar oluşturulabilir.

Enum’larda Jenerik Gücü

Ağ işlemlerinde başarı durumunda veri, başarısızlık durumunda hata taşımak yaygın bir ihtiyaçtır. Jenerik enum bu iki değerin tipini dışarıdan alabilir:

enum APIResult<Success, Failure> {
    case success(Success)
    case failure(Failure)
}

struct User {
    let id: Int
    let name: String
}

enum NetworkError {
    case timeout
    case unauthorized
}

let result: APIResult<User, NetworkError> =
    .success(User(id: 1, name: "Grace"))

Bu model, başarılı sonucun User, hatanın ise NetworkError olduğunu açıkça belirtir. Böylece belirsiz sözlükler veya zorunlu tip dönüşümleri ortadan kalkar.

Tip Kısıtlamaları

Her jenerik işlem bütün tiplerle çalışamaz. Örneğin iki değerin eşitliğini kontrol etmek için tipin Equatable protokolüne uyması gerekir:

func ayniMi<T: Equatable>(_ sol: T, _ sag: T) -> Bool {
    sol == sag
}

print(ayniMi(5, 5))
print(ayniMi("Swift", "Kotlin"))

T: Equatable ifadesi, “Herhangi bir tip olabilir ama eşitlik karşılaştırmasını desteklemeli” demektir. Kısıtlamalar jenerikleri daraltmaz; aksine hangi yeteneklere güvenilebileceğini açıkça tanımlar.

Jenerikler doğru kullanıldığında kod tabanını küçültür, hataları derleme aşamasına taşır ve soyutlamaları güçlendirir. Ancak yalnızca bir yerde kullanılacak basit kodu gereksiz yere jenerikleştirmek okunabilirliği azaltabilir. Altın kural şudur: Aynı davranış birden fazla tip için gerçekten anlamlıysa jenerikler sahneye çıkmalı; aksi hâlde soyutlama pelerinini dolapta bırakmalıdır.

``

Kapanış neden sıradan bir fonksiyondan farklıdır?

Normal bir fonksiyon çoğunlukla yalnızca parametrelerine ve erişebildiği genel değerlere bağlıdır. Kapanış ise tanımlandığı kapsamın değişkenlerini yakalayabilir. Matematiksel açıdan sıradan bir fonksiyonu

şeklinde düşünürsek, dışarıdaki $a$ değerini yakalayan kapanış şu aileyi temsil eder:

Burada $a$, açıkça parametre olarak verilmemesine rağmen hesaplamanın parçasıdır. Kapanışın yanında taşıdığı bu çevresel bilgilere bazen closure environment denir.

Rust’ta bir kapanış çevresindeki değeri referansla ödünç alabilir, değiştirilebilir biçimde ödünç alabilir veya sahipliğini üstlenebilir. Derleyici buna göre kapanışı Fn, FnMut ya da FnOnce davranışlarından biriyle ilişkilendirir.

fn main() {
    let katsayi = 3;
    let carp = |sayi: i32| sayi * katsayi;

    println!("{}", carp(5)); // 15
}

Buradaki carp, katsayi değişkenini çevresinden yakalar. Böylece her çağrıda katsayıyı ayrıca göndermemiz gerekmez.

İteratör: Koleksiyon değil, üretim süreci

İteratör bir koleksiyonun kendisi değildir; sıradaki elemanın nasıl elde edileceğini tanımlayan bir mekanizmadır. Temel fikir, her adımda ya yeni bir değer ya da akışın bittiğini bildiren sonuç üretmektir.

$n$ elemanlı bir koleksiyon tek kez dolaşılıyorsa zaman karmaşıklığı çoğunlukla

olur. map, filter ve take gibi işlemlerin zincirlenmesi mutlaka her aşamada yeni bir koleksiyon oluşturmaz. Birçok dilde, özellikle Rust’ta, iteratörler tembeldir: Sonuç tüketilene kadar hesaplama başlamaz.

İkisini birlikte kullanalım

Aşağıdaki örnek çift sayıları seçer, dışarıdan yakalanan katsayıyla çarpar ve sonuçları toplar:

fn main() {
    let sayilar = vec![1, 2, 3, 4, 5, 6];
    let katsayi = 10;

    let toplam: i32 = sayilar
        .iter()
        .filter(|sayi| *sayi % 2 == 0)
        .map(|sayi| sayi * katsayi)
        .sum();

    println!("Toplam: {}", toplam); // 120
}

filter içindeki kapanış yalnızca çift değerleri geçirir. map kapanışı ise katsayi değişkenini yakalayarak değerleri dönüştürür. sum, tembel zinciri tüketen terminal işlem olduğu için gerçek hesaplama bu noktada gerçekleşir.

Aynı yaklaşım klasik bir döngüyle de yazılabilir; ancak iteratör zinciri “indeksi artır, elemana eriş, sonucu geçici değişkende tut” ayrıntılarını gizler. Böylece kod, mekanizmadan çok niyeti anlatır.

Ne zaman dikkatli olmalıyız?

Uzun ve iç içe kapanış zincirleri okunabilirliği azaltabilir. Yan etkiler, karmaşık hata yönetimi veya çok sayıda koşul varsa işlemleri isimlendirilmiş fonksiyonlara ayırmak daha sağlıklıdır. Ayrıca sahiplik kullanan dillerde move ile yakalanan bir değerin artık önceki kapsamda kullanılamayabileceği unutulmamalıdır.

Özetle kapanışlar davranışı veri gibi taşır, iteratörler ise veriyi kontrollü bir akışa dönüştürür. Birlikte kullanıldıklarında döngü yazmaktan fazlasını yaparız: Dönüşümleri birbirine bağlayan küçük ve güçlü bir işlem hattı kurarız.

Option neden gereklidir?

Java, C# ve JavaScript gibi dillerde bir referansın null olması mümkündür. Buna rağmen değişkenin tipi çoğu zaman bu ihtimali yeterince görünür kılmaz. Programcı kontrol yapmayı unutursa hata çalışma zamanında ortaya çıkar.

Rust’ta sıradan bir referans kendiliğinden null olamaz. Bir değerin bulunmaması geçerli bir durumsa standart kütüphanedeki şu enum kullanılır:

enum Option<T> {
    Some(T),
    None,
}

Buradaki T, saklanabilecek değerin tipidir. Örneğin Option<i32>, ya Some(i32) biçiminde bir tam sayı ya da None içerir. Olası durumların sayısını basitçe şöyle gösterebiliriz:

Formüldeki ekstra bir durum None seçeneğidir. Örneğin bool iki farklı değere sahipken Option<bool> üç durumu temsil eder: Some(true), Some(false) ve None.

Pattern matching ile değeri açmak

Option içindeki veriye doğrudan erişilemez. Önce hangi varyantla karşı karşıya olduğumuzu belirlememiz gerekir. En açık yöntem match ifadesidir:

fn kullanici_bul(id: u32) -> Option<String> {
    if id == 42 {
        Some(String::from("Ada"))
    } else {
        None
    }
}

fn main() {
    match kullanici_bul(42) {
        Some(isim) => println!("Kullanıcı bulundu: {isim}"),
        None => println!("Kullanıcı bulunamadı"),
    }
}

Fonksiyon, sonuç bulmayı garanti etmediği için String yerine Option<String> döndürür. match, hem Some hem de None kolunu yazmamızı zorunlu tutar. Bir kol unutulursa program derlenmez; yani hata, kullanıcıya ulaşmadan yakalanır.

Yalnızca değer bulunduğunda işlem yapılacaksa if let daha kısa olabilir:

if let Some(isim) = kullanici_bul(42) {
    println!("Hoş geldin, {isim}!");
}

Option yardımcı metotları

Rust, sık kullanılan senaryolar için pratik metotlar sunar:

Örneğin yaş bilgisini güvenli biçimde dönüştürebiliriz:

fn yas_metni(yas: Option<u8>) -> String {
    yas.map(|deger| format!("{deger} yaşında"))
        .unwrap_or(String::from("Yaş bilinmiyor"))
}

map, yalnızca değer varsa closure’ı çalıştırır. Sonuç None kalırsa unwrap_or varsayılan metni üretir. Böylece elle dallanma yazmadan güvenli bir akış kurulur.

Option ile Result aynı şey değildir

Option, yalnızca değer bulunup bulunmadığını anlatır. Başarısızlığın nedenini de taşımak gerekiyorsa Result<T, E> daha uygundur.

fn bol(a: f64, b: f64) -> Option<f64> {
    if b == 0.0 { None } else { Some(a / b) }
}

Bu örnekte yokluk sebebi zaten açıktır. Dosya okuma gibi bir işlemde ise “dosya yok”, “izin reddedildi” veya “disk hatası” ayrımı gerektiğinden Result seçilmelidir.

Kısacası Option, null değerini sihirli ve tehlikeli bir istisna olmaktan çıkarıp tip sisteminin parçası yapar. Rust size “Bu değer kesinlikle var mı?” sorusunu kod derlenmeden önce sordurur. Biraz disiplin karşılığında daha az gece yarısı hatası alınır; bu da oldukça kârlı bir takastır.

Kurtarılabilir hata nedir?

Hataları kabaca iki gruba ayırabiliriz. Programın varsayımlarını tamamen bozan durumlar kurtarılamaz kabul edilir ve Rust’ta çoğunlukla panic! ile ilişkilendirilir. Eksik dosya, geçersiz kullanıcı girdisi veya başarısız ağ isteği gibi olaylarsa kurtarılabilir hatalardır. Program bunları kullanıcıya bildirebilir, işlemi tekrarlayabilir ya da alternatif bir yol seçebilir.

Bir işlemin sonucunu basitçe şu küme gibi düşünebiliriz:

Burada $T$ başarılı değerin, $E$ ise hata bilgisinin türüdür. Rust standart kütüphanesindeki yapı kavramsal olarak şöyledir:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

Bu tanım, bir fonksiyonun aynı anda hem başarı hem hata olamayacağını anlatır. Sonuç iki olasılıktan tam olarak biridir.

Result değerini eşleştirmek

Bir metni sayıya dönüştüren fonksiyon yazalım. Fonksiyon hata mesajını da dönüş türünde ilan ediyor:

fn sayiya_cevir(girdi: &str) -> Result<i32, String> {
    match girdi.trim().parse::<i32>() {
        Ok(sayi) => Ok(sayi),
        Err(_) => Err(format!("Geçersiz sayı: {girdi}")),
    }
}

fn main() {
    match sayiya_cevir("42") {
        Ok(deger) => println!("Sonuç: {deger}"),
        Err(hata) => eprintln!("Hata: {hata}"),
    }
}

match, iki ihtimali de ele almaya zorlar. Böylece hata yolunu yanlışlıkla unutmak zorlaşır. Üstelik hata bir değer olduğu için kaydedilebilir, dönüştürülebilir veya başka bir fonksiyona aktarılabilir.

Soru işareti operatörüyle erken dönüş

Her adımda match yazmak güvenli olsa da kodu kalabalıklaştırabilir. ? operatörü, değer Ok ise içeriğini çıkarır; Err ise hatayı çağıran fonksiyona hemen döndürür.

use std::fs;
use std::io;

fn ayarlari_oku() -> Result<String, io::Error> {
    let icerik = fs::read_to_string("ayarlar.txt")?;
    Ok(icerik)
}

fn main() {
    match ayarlari_oku() {
        Ok(ayarlar) => println!("Ayarlar yüklendi:\n{ayarlar}"),
        Err(hata) => eprintln!("Ayarlar okunamadı: {hata}"),
    }
}

Bu akış matematiksel olarak ardışık işlemlerin başarısına bağlıdır. $A$ ve $B$ adımları için toplam başarı koşulu $A \land B$ olur. İlk Err oluştuğunda zincir kısa devre yapar; gereksiz işlemler çalışmaz.

Result dönüştürme araçları

Rust, sık kullanılan senaryolar için yardımcı metotlar sunar:

fn iki_kati(girdi: &str) -> Result<i32, String> {
    girdi
        .parse::<i32>()
        .map(|sayi| sayi * 2)
        .map_err(|_| "Sayı biçimi geçersiz".to_string())
}

Burada map, yalnızca başarı halinde çalışır; map_err ise yalnızca hatayı uygulamaya uygun bir mesaja çevirir. Bu ayrım, mutlu yol ile hata yolunu birbirine dolamadan yönetir.

unwrap ve expect hızlı prototiplerde kullanışlıdır ancak üretim kodunda ölçülü kullanılmalıdır; çünkü Err geldiğinde programı panikletirler. Beklenen hatalarda match, ? ve dönüştürme metotları daha dayanıklı tercihlerdir. Kısacası Result, hataları saklamaz: onları görünür, tür güvenli ve test edilebilir verilere dönüştürür. Program da tökezlediğinde yere kapanmak yerine neden tökezlediğini anlayıp yoluna devam eder.

Hash haritasının çalışma mantığı

Bir hash haritasındaki her anahtar, hash fonksiyonu tarafından sayısal bir özete dönüştürülür. Basitleştirilmiş biçimiyle yerleşim işlemi şöyle gösterilebilir:

Bu indeks, değerin bellekte hangi kovaya yerleştirileceğini belirler. İki farklı anahtar aynı indeksi üretirse çakışma oluşur. Hash haritası uygulamaları bu durumu zincirleme veya açık adresleme gibi yöntemlerle çözer.

İyi dağılım sağlayan bir hash fonksiyonunda ekleme, arama ve silme işlemlerinin ortalama zaman karmaşıklığı $O(1)$ kabul edilir. Ancak çok sayıda çakışmanın yaşandığı kötü durumda karmaşıklık $O(n)$ seviyesine çıkabilir.

Rust ile HashMap oluşturmak

HashMap, standart kütüphanenin ön hazırlık modülünde otomatik olarak bulunmaz; önce içe aktarılmalıdır. Aşağıdaki kod, ürün adlarını fiyatlarla eşleştirir:

use std::collections::HashMap;

fn main() {
    let mut fiyatlar = HashMap::new();

    fiyatlar.insert(String::from("Klavye"), 1250);
    fiyatlar.insert(String::from("Fare"), 700);
    fiyatlar.insert(String::from("Monitör"), 8200);

    if let Some(fiyat) = fiyatlar.get("Klavye") {
        println!("Klavye fiyatı: {fiyat} TL");
    }
}

insert, haritayı değiştirdiği için değişken mut olarak tanımlanmıştır. get metodu ise anahtar bulunamayabileceğinden Option<&V> döndürür. Böylece Rust, “olmayan değeri kullandın, program çöktü” sürprizini kontrollü bir seçime dönüştürür.

Sahiplik kuralları haritayı nasıl etkiler?

i32 gibi Copy özelliğine sahip türler haritaya kopyalanır. String gibi kopyalanmayan türlerde ise sahiplik varsayılan olarak HashMap yapısına taşınır:

use std::collections::HashMap;

fn main() {
    let anahtar = String::from("tema");
    let deger = String::from("karanlik");
    let mut ayarlar = HashMap::new();

    ayarlar.insert(anahtar, deger);

    // println!("{anahtar}"); // Hata: sahiplik taşındı.
    println!("{:?}", ayarlar.get("tema"));
}

Eklemeden sonra anahtar ve deger artık kullanılamaz; onların yeni sahibi ayarlar değişkenidir. Harita kapsam dışına çıktığında içindeki veriler de güvenli biçimde temizlenir. Verilerin sahipliğini taşımak istemiyorsak referans saklayabiliriz; ancak bu kez referansların haritadan daha uzun yaşaması gerekir.

Değerleri güncelleme stratejileri

Aynı anahtarla tekrar insert çağrılırsa eski değer yenisiyle değiştirilir. Anahtar yalnızca yoksa değer eklemek için entry API’si kullanılır. Bu API, kelime sayacı gibi senaryolarda oldukça zariftir:

use std::collections::HashMap;

fn main() {
    let metin = "rust guvenli rust hizli rust eglenceli";
    let mut sayac = HashMap::new();

    for kelime in metin.split_whitespace() {
        let adet = sayac.entry(kelime).or_insert(0);
        *adet += 1;
    }

    println!("{sayac:?}");
}

or_insert(0), ilgili değere değiştirilebilir bir referans verir. *adet += 1 ifadesi bu referansın gösterdiği sayıyı artırır. Ödünç alma kuralları nedeniyle aynı anda harita üzerinde çakışan değiştirilebilir erişimler oluşturulamaz; böylece iterator geçersizliği ve veri yarışı gibi hatalar daha derleme aşamasında engellenir.

Sonuç olarak HashMap, hızlı anahtar tabanlı erişim sağlarken Rust’ın sahiplik modeli verilerin kime ait olduğunu açıkça belirler. Ayarlar, önbellekler, sayaçlar ve kullanıcı kayıtları için güçlü bir seçimdir; fakat sıralama gerekiyorsa BTreeMap, yalnızca ardışık veriler tutulacaksa Vec daha uygun olabilir.

Struct Nedir?

struct, belirli bir kavramı temsil eden alanların tek bir veri tipi altında toplanmasıdır. Örneğin bir kullanıcı; metin biçiminde ada, sayısal yaşa ve mantıksal aktiflik durumuna sahip olabilir. Bu değerlerin tipleri farklı olsa da aynı varlığı tanımlar.

Matematiksel açıdan bir yapı, farklı kümelerin Kartezyen çarpımından seçilen bir kayıt gibi düşünülebilir:

Buradaki her kullanıcı, bu kümelerden gelen değerlerin oluşturduğu bir bütündür. Struct kullanmak yalnızca verileri paketlemez; alan adları sayesinde verinin anlamını da kodun içine taşır.

İlk Yapımızı Tanımlayalım

Aşağıdaki yapı, bir uygulama kullanıcısını modellemektedir:

struct Kullanici {
    ad: String,
    yas: u8,
    eposta: String,
    aktif: bool,
}

fn main() {
    let kullanici = Kullanici {
        ad: String::from("Ada"),
        yas: 28,
        eposta: String::from("ada@example.com"),
        aktif: true,
    };

    println!("Kullanıcı: {}", kullanici.ad);
}

Her alanın tipi derleme zamanında bellidir. Örneğin yas alanına yanlışlıkla bir metin atanırsa Rust programı çalıştırmadan önce hata verir. Bu özellik, veri modelini aynı zamanda bir güvenlik sözleşmesine dönüştürür.

Bir örneğin değiştirilebilmesi için tamamının mut olarak tanımlanması gerekir:

let mut kullanici = Kullanici {
    ad: String::from("Ece"),
    yas: 24,
    eposta: String::from("ece@example.com"),
    aktif: false,
};

kullanici.aktif = true;

Rust, yalnızca tek bir alanı mut yapmaya izin vermez. Değişebilirlik struct örneğinin tamamına aittir.

impl ile Yapıya Davranış Kazandırmak

Veri modellemek çoğu zaman yeterli değildir; modelin davranışları da olmalıdır. impl bloğu, belirli bir struct için metot ve ilişkili fonksiyon tanımlamamızı sağlar.

impl Kullanici {
    fn yeni(ad: String, yas: u8, eposta: String) -> Self {
        Self {
            ad,
            yas,
            eposta,
            aktif: true,
        }
    }

    fn yetiskin_mi(&self) -> bool {
        self.yas >= 18
    }

    fn devre_disi_birak(&mut self) {
        self.aktif = false;
    }
}

yeni, bir ilişkili fonksiyondur; çağrılmak için mevcut bir nesneye ihtiyaç duymaz. Self, Kullanici tipinin kısa yazımıdır. yetiskin_mi metodu &self ile veriyi yalnızca ödünç alır. devre_disi_birak ise &mut self kullandığı için örneği değiştirebilir.

Metotlar şu şekilde kullanılabilir:

let mut kisi = Kullanici::yeni(
    String::from("Mert"),
    20,
    String::from("mert@example.com"),
);

println!("Yetişkin mi? {}", kisi.yetiskin_mi());
kisi.devre_disi_birak();

Neden Önemlidir?

İyi tasarlanmış bir struct, programın iş kurallarını görünür hâle getirir. Kullanıcı, ürün, sipariş veya oyun karakteri gibi kavramlar; alanları ve davranışlarıyla bağımsız modellere dönüşür. Böylece fonksiyonlara uzun parametre listeleri taşımak yerine tek ve anlamlı bir değer gönderilir.

Struct ve impl birlikteliği, Rust’ta veri ile davranış arasında düzenli bir bağ kurar. Sonuç; okunabilir, tip güvenli ve büyümeye hazır koddur. Kısacası struct verinin iskeletiyse, impl o iskelete hareket kazandıran kaslardır.

Enum neden gereklidir?

Enum, bir değerin önceden belirlenmiş varyasyonlardan yalnızca biri olabileceğini ifade eden veri tipidir. Matematiksel olarak bir enum’u ayrık birleşim biçiminde düşünebiliriz:

enum OdemeDurumu {
    Bekliyor,
    Basarili { islem_no: String, tutar: f64 },
    Reddedildi(String),
}

Bu enum’da Bekliyor ek bilgi taşımaz. Basarili, işlem numarası ile tutarı; Reddedildi ise hata açıklamasını taşır. Birbirinden kopuk değişkenler oluşturmak yerine verinin şekli doğrudan tipe işlenmiştir.

Metin kullanan bir sistemde "başarılı", "Başarılı" ve yanlışlıkla yazılan "başarlı" farklı değerlerdir. Enum kullanıldığında ise derleyici yalnızca tanımlanmış varyasyonlara izin verir.

Match ile varyasyonları açmak

match, bir enum değerini varyasyonlarına göre inceleyen ve uygun kod dalını çalıştıran ifadedir. Aynı zamanda varyasyonun içindeki verileri desen eşleştirme yoluyla çıkarabilir:

fn raporla(durum: OdemeDurumu) -> String {
    match durum {
        OdemeDurumu::Bekliyor => {
            String::from("Ödeme henüz tamamlanmadı.")
        }
        OdemeDurumu::Basarili { islem_no, tutar } => {
            format!("{} numaralı işlem tamamlandı: {:.2} TL", islem_no, tutar)
        }
        OdemeDurumu::Reddedildi(neden) => {
            format!("Ödeme reddedildi: {}", neden)
        }
    }
}

Burada islem_no, tutar ve neden değişkenleri yalnızca ilgili desen eşleştiğinde oluşturulur. Ayrıca match bir ifade olduğu için her dalın ürettiği String, fonksiyonun dönüş değeri olarak kullanılabilir.

Eksiksizlik denetimi

Rust’taki match ifadesinin en güçlü özelliği exhaustiveness, yani eksiksizlik kontrolüdür. Enum’un varyasyon sayısı $n$ ise güvenli bir eşleştirme bütün olasılık kümesini kapsamalıdır:

Örneğin Reddedildi dalını silersek kod derlenmez. Derleyici, hangi desenin eksik olduğunu bildirir. Daha sonra enum’a IadeEdildi varyasyonu eklendiğinde de ilgili tüm match ifadeleri yeniden kontrol edilir. Böylece yeni bir özelliğin unutulmuş kod yolları oluşturması engellenir.

Genel bir yakalama için _ deseni kullanılabilir:

match durum {
    OdemeDurumu::Basarili { tutar, .. } => println!("Kazanç: {tutar}"),
    _ => println!("Henüz kazanç oluşmadı."),
}

.., varyasyondaki kullanılmayan alanları yok sayar; _ ise kalan bütün varyasyonları eşleştirir. Ancak _ aşırı kullanılırsa enum’a sonradan eklenen varyasyonlar sessizce bu dala düşebilir. Kritik iş kurallarında varyasyonları açıkça yazmak daha güvenlidir.

Koruyucular ve daha hassas desenler

Desenlere if koruyucuları eklenerek aynı varyasyon farklı koşullara ayrılabilir:

match durum {
    OdemeDurumu::Basarili { tutar, .. } if tutar >= 10_000.0 => {
        println!("Yüksek tutarlı işlem kontrol edilmeli.");
    }
    OdemeDurumu::Basarili { tutar, .. } => println!("Onaylanan tutar: {tutar}"),
    OdemeDurumu::Bekliyor => println!("Bekleniyor..."),
    OdemeDurumu::Reddedildi(neden) => println!("Hata: {neden}"),
}

Enum verinin hangi biçimlerde bulunabileceğini, match ise her biçimde ne yapılacağını tanımlar. İkisi birlikte kullanıldığında geçersiz durumlar azalır, dallanma mantığı okunabilir hâle gelir ve unutulan olasılıklar çalışma zamanına ulaşmadan yakalanır. Kısacası derleyici yalnızca kodu çevirmekle kalmaz; olasılıkları sizinle birlikte sayar.

İki Farklı Metin Görünümü

String, UTF-8 kodlanmış metni heap üzerinde saklayan, büyüyüp küçülebilen ve verisinin sahibi olan bir koleksiyondur. Yapısal olarak Vec<u8> ile benzer bir mantığa sahiptir ve üç temel bilgi taşır:

• Heap üzerindeki veriyi gösteren işaretçi
• Kullanılan bayt sayısını belirten uzunluk
• Ayrılmış toplam alanı belirten kapasite

Bu ilişkiyi kabaca şöyle gösterebiliriz:

Metne yeni karakterler eklendiğinde uzunluk kapasiteyi aşarsa daha büyük bir bellek alanı ayrılır ve mevcut veri taşınabilir. Dolayısıyla büyütme işlemi her zaman ücretsiz değildir.

str ise dinamik boyutlu bir türdür; derleme anında kaç bayt tutacağı bilinmez. Bu nedenle çoğunlukla doğrudan str değil, &str biçiminde kullanılır. Bir &str, metin verisine işaret eden ödünç alınmış bir görünüm ile görünümün bayt uzunluğundan oluşur. Verinin sahibi değildir ve kapsam sona erdiğinde metni serbest bırakmaz.

Oluşturma ve Ödünç Alma

Aşağıdaki örnekte değiştirilebilir bir String oluşturuluyor, büyütülüyor ve ardından bu veriye &str görünümü alınıyor:

fn kelime_sayisi(metin: &str) -> usize {
    metin.split_whitespace().count()
}

fn main() {
    let mut mesaj = String::from("Merhaba");
    mesaj.push_str(", Rust dünyası!");

    let gorunum: &str = &mesaj;
    println!("{}", gorunum);
    println!("Kelime: {}", kelime_sayisi(&mesaj));
}

kelime_sayisi parametresinin &str olması önemlidir. Böylece fonksiyon hem String içinden alınan dilimleri hem de doğrudan yazılmış metin sabitlerini kabul eder. &String kullanmak mümkün olsa da daha az esnek bir API ortaya çıkarır.

UTF-8: Karakter Sayısı Bayt Sayısı Değildir

Rust stringleri geçerli UTF-8 olmak zorundadır. ASCII karakterleri genellikle bir bayt kullanırken Türkçe karakterler veya emojiler birden fazla bayt kullanabilir. Bu nedenle genel olarak:

fn main() {
    let metin = "çağrı 🦀";

    println!("Bayt: {}", metin.len());
    println!("Karakter: {}", metin.chars().count());
}

Buradaki len() kullanıcıların gördüğü karakterleri değil, UTF-8 baytlarını sayar. Rust’ın metin[0] biçiminde indekslemeye izin vermemesinin nedeni de budur: Bir bayt her zaman bağımsız bir karakter anlamına gelmez.

Dilimleme yapılırken sınırların geçerli UTF-8 karakter sınırlarına denk gelmesi gerekir:

let metin = String::from("İstanbul");
let parca = &metin[0..2]; // "İ", UTF-8 içinde iki bayttır
println!("{}", parca);

Yanlış bir bayt sınırı çalışma zamanında paniğe yol açabilir. Güvenli karakter işleme için chars(), bayt işleme için bytes() kullanılmalıdır.

Hangisini Seçmeliyiz?

Yeni metin oluşturacak, birleştirecek veya değiştirecekseniz String doğru araçtır. Yalnızca mevcut metni okuyacak bir fonksiyon yazıyorsanız &str tercih etmek daha esnek ve ekonomiktir. Kısacası String metnin ev sahibi, &str ise anahtarı geçici olarak teslim edilmiş misafiridir. UTF-8 de evin oda planıdır; bayt sınırlarını bilmeden duvarı kırmaya çalışırsanız Rust güvenlik görevlisini, yani paniği, çağırır.

``

Trait nedir?

Trait, bir veri tipinin hangi davranışları sağlayacağını bildiren metot imzaları bütünüdür. Buradaki önemli fikir, tipin ne olduğundan çok ne yapabildiğiyle ilgilenmektir. Örneğin bir Kus ve Ucak aynı alanlara sahip değildir; ancak ikisi de Ucan davranışını uygulayabilir.

Bir trait’i matematiksel bir sözleşme gibi düşünebiliriz. $T$ bir veri tipi, $D$ ise bir davranış kümesi olsun. Eğer $T$, gerekli bütün metotları sağlıyorsa şu ilişkiyi kurarız:

Yani “$T$ tipi, $D$ davranış sözleşmesini karşılar” deriz. Böylece kodumuz somut tiplere değil, yeteneklere bağımlı hâle gelir.

İlk trait’imizi yazalım

Aşağıdaki örnekte uçabilen nesneler için ortak bir şablon oluşturuyoruz:

trait Ucan {
    fn isim(&self) -> &str;
    fn hiz(&self) -> u32;

    fn bilgi_ver(&self) {
        println!("{} saatte {} km hızla uçuyor.", self.isim(), self.hiz());
    }
}

struct Kus {
    ad: String,
    ucus_hizi: u32,
}

impl Ucan for Kus {
    fn isim(&self) -> &str {
        &self.ad
    }

    fn hiz(&self) -> u32 {
        self.ucus_hizi
    }
}

isim ve hiz metotlarının uygulanması zorunludur. bilgi_ver ise varsayılan bir gövdeye sahiptir; isteyen tip bunu doğrudan kullanabilir, isteyen kendi sürümünü yazabilir. Böylece tekrar azaltılırken davranışın özelleştirilebilirliği korunur.

Trait bound ile yetenek istemek

Generic bir fonksiyon her tipi kabul edebilir; fakat bazen “Her tip gelsin ama uçmayı bilsin!” demek isteriz. Bunun için trait bound kullanılır:

fn yarisa_kat<T: Ucan>(katilimci: &T) {
    println!("Yarışmacı: {}", katilimci.isim());
    katilimci.bilgi_ver();
}

Buradaki T: Ucan, T tipinin Ucan trait’ini uygulaması gerektiğini belirtir. Başka bir ifadeyle kabul edilen tipler kümesi şöyledir:

Bu kontrol derleme zamanında yapılır. Uçma davranışını sağlamayan bir tipi fonksiyona gönderirsek program henüz çalışmadan anlaşılır bir hata alırız.

Birden fazla koşul da tanımlanabilir:

fn raporla<T>(nesne: &T)
where
    T: Ucan + std::fmt::Debug,
{
    println!("{:?}", nesne);
    nesne.bilgi_ver();
}

Bu fonksiyon, tipin hem Ucan hem de Debug davranışlarını sağlamasını ister.

Statik ve dinamik çok biçimlilik

Trait’ler iki temel biçimde kullanılabilir:

Vec<Box<dyn Ucan>> kullanarak kuşları, uçakları ve başka uçan tipleri aynı koleksiyonda saklayabiliriz. Bunun küçük bir çalışma zamanı maliyeti vardır; buna karşılık esnek bir mimari sağlar.

Trait’lerin asıl gücü, “Bu nesne hangi sınıftan?” sorusunu geri plana atıp “Bu nesne hangi işleri yapabilir?” sorusunu öne çıkarmasıdır. Sonuçta daha gevşek bağlı, test edilebilir ve genişletilebilir kod elde edilir. Yeni bir tip eklemek için mevcut algoritmaları değiştirmek gerekmez; yalnızca ilgili davranış sözleşmesini uygulamak yeterlidir.