Arayüz tam olarak nedir?

Arayüz, bir nesnenin ne yapacağını tanımlayan; bunu nasıl yapacağını ise uygulayıcı sınıfa bırakan soyut bir şablondur. Örneğin OdemeYontemi isimli bir arayüz, her ödeme yönteminin ode() metoduna sahip olmasını zorunlu kılabilir. Kredi kartı, banka havalesi veya dijital cüzdan bu işlemi farklı şekilde gerçekleştirir; önemli olan, dışarıdan bakıldığında hepsinin aynı davranışı sunmasıdır.

Bu düşünceyi küme mantığıyla ifade edebiliriz. Bir $I$ arayüzünün zorunlu tuttuğu davranış kümesi $B_I$, bir $C$ sınıfının sunduğu davranış kümesi ise $B_C$ olsun. Sınıfın sözleşmeyi sağlaması için şu koşul geçerlidir:

Yani sınıf, arayüzde belirtilen bütün üyeleri içermelidir; isterse bunlara yeni özellikler ve metotlar da ekleyebilir.

Sınıf, soyut sınıf ve arayüz farkı

Bu üç yapı sıkça aynı çekmeceye atılsa da görevleri farklıdır:

Arayüzü bir priz standardı, sınıfı ise o prize bağlanan cihaz gibi düşünebiliriz. Televizyon ile kahve makinesinin iç mekanizması aynı değildir; fakat ikisi de uygun fişe sahipse elektrik altyapısıyla iletişim kurabilir.

TypeScript ile sözleşme oluşturmak

Aşağıdaki örnekte bütün bildirim servislerinin uyması gereken yapı tanımlanıyor:

interface BildirimServisi {
  servisAdi: string;
  gonder(alici: string, mesaj: string): boolean;
}

class EpostaServisi implements BildirimServisi {
  servisAdi = "E-posta";

  gonder(alici: string, mesaj: string): boolean {
    console.log(`${alici} adresine gönderildi: ${mesaj}`);
    return true;
  }
}

function kullaniciyiBilgilendir(
  servis: BildirimServisi,
  alici: string
): void {
  servis.gonder(alici, "Siparişiniz hazır!");
}

Buradaki kullaniciyiBilgilendir fonksiyonu doğrudan EpostaServisi sınıfına bağımlı değildir. Yalnızca BildirimServisi sözleşmesini tanır. Daha sonra SMS veya mobil bildirim sınıfı eklendiğinde fonksiyonun değiştirilmesi gerekmez. Kodun yeni davranışlara açılırken mevcut yapıda değişiklik istememesi, Açık/Kapalı Prensibi ile uyumludur.

Gevşek bağlılık neden değerlidir?

Bir sınıf başka bir somut sınıfa doğrudan bağımlıysa değişiklikler zincirleme etki yaratabilir. Arayüz kullanıldığında bağımlılık, uygulama ayrıntısına değil soyut sözleşmeye yönelir. Bu yaklaşım Bağımlılıkların Tersine Çevrilmesi Prensibinin temelidir.

Örneğin test sırasında gerçekten e-posta göndermek yerine aynı arayüzü uygulayan bir SahteBildirimServisi kullanılabilir. Böylece test hızlı, ücretsiz ve öngörülebilir olur.

Her yere arayüz eklenmeli mi?

Hayır. Tek uygulaması bulunan ve değişme ihtimali düşük, küçük yapılara sırf “kurumsal görünsün” diye arayüz eklemek gereksiz karmaşıklık yaratabilir. Arayüzler özellikle birden fazla uygulama beklendiğinde, dış sistemler soyutlandığında veya bileşenlerin bağımsız test edilmesi gerektiğinde değerlidir.

Kısacası arayüzler yalnızca metot listeleri değildir; ekipler ve bileşenler arasında kurulmuş teknik anlaşmalardır. İyi tasarlanmış bir arayüz, nesnenin iç ayrıntılarını gizlerken beklentileri netleştirir. Kod değiştikçe sözleşme sabit kalabiliyorsa sistem daha esnek, test edilebilir ve sürdürülebilir hâle gelir.

``

Dinamik dizilerin bellek düzeni

Klasik bir dizi, aynı veri türündeki elemanları çoğunlukla bellekte ardışık olarak saklar. İlk elemanın adresi $A$, her elemanın boyutu $s$ ise $i$ indisli elemanın adresi yaklaşık olarak şöyle hesaplanır:

Bu basit formül sayesinde indisle erişim $O(1)$ zaman karmaşıklığına sahiptir. İşlemci önbelleği de komşu elemanları birlikte getirebildiği için diziler üzerinde sırayla dolaşmak oldukça hızlıdır.

Dinamik diziler ise çalışma sırasında büyüyebilir. C++ dilindeki std::vector, bunun yaygın bir örneğidir. Vector genellikle üç bilgiyi yönetir: veri bloğunun adresi, mevcut eleman sayısı ve ayrılmış kapasite.

#include <iostream>
#include <vector>

int main() {
    std::vector<int> puanlar;
    puanlar.reserve(4); // Dört elemanlık belleği önceden ayırır.

    puanlar.push_back(70);
    puanlar.push_back(85);
    puanlar.push_back(92);

    std::cout << "Boyut: " << puanlar.size() << '\n';
    std::cout << "Kapasite: " << puanlar.capacity() << '\n';
}

size, gerçekten bulunan eleman sayısını; capacity ise yeniden bellek ayırmadan saklanabilecek eleman sayısını gösterir. Kapasite dolduğunda daha büyük bir blok ayrılır, eski elemanlar yeni alana taşınır ve eski blok serbest bırakılır. Bu işlem tek seferde $O(n)$ maliyetlidir. Ancak kapasite geometrik olarak büyütüldüğünden push_back işleminin amortize maliyeti $O(1)$ kabul edilir.

Demetler neden farklıdır?

Demet, farklı türdeki değerleri belirli bir sırada ve sabit sayıda tutar. Örneğin bir öğrenciyi kimlik numarası, isim ve not ile temsil edebiliriz:

#include <iostream>
#include <string>
#include <tuple>

int main() {
    std::tuple<int, std::string, double> ogrenci{42, "Ada", 91.5};

    auto& [numara, ad, notu] = ogrenci;
    std::cout << numara << " - " << ad << " - " << notu;
}

Buradaki elemanların türleri derleme zamanında bellidir ve sonradan dördüncü bir alan eklenemez. Yapısal bağlama, indis yerine anlamlı değişken adlarıyla çalışmayı kolaylaştırır. Bununla birlikte std::tuple elemanlarının fiziksel sıralaması ve yerleşimi uygulamaya bağlı olabilir; ardışık bir ham dizi gibi yorumlanmamalıdır.

Farklı türlerin hizalama gereksinimleri nedeniyle demet içinde padding adı verilen kullanılmayan baytlar oluşabilir. Yaklaşık toplam boyut şu düşünceyle modellenebilir:

Eşitsizliğin nedeni hizalama boşlukları ve kütüphane uygulamasının tercih ettiği yerleşimdir.

Hangisini seçmeliyiz?

Aynı türden, sayısı değişebilen verileri işleyecekseniz dinamik dizi doğal seçimdir. Sensör ölçümleri, puan listeleri ve oyun nesneleri buna örnektir. Bir fonksiyondan farklı türde birkaç değeri birlikte döndürmek veya küçük, sabit bir kayıt oluşturmak istiyorsanız demet daha uygundur.

Yine de alanların özel anlamları varsa tuple yerine adlandırılmış bir struct kullanmak okunabilirliği artırır. Kısacası dizi, büyüyebilen düzenli bir raf; demet ise bölmeleri önceden belirlenmiş bir araç çantasıdır. Doğru seçim, hem bellek davranışını hem de kodun anlaşılabilirliğini doğrudan etkiler.

``

Enum mantığı

Enum, yani enumeration veya numaralandırma, alabileceği değerler önceden belirlenmiş kategorik bir veri türüdür. Bir SiparisDurumu değişkeni yalnızca Bekliyor, Hazirlaniyor, Kargoda ya da TeslimEdildi gibi tanımlanmış seçeneklerden birini taşır. Böylece hem insan hem de derleyici değişkenin anlamını bilir.

Matematiksel açıdan enum değerlerini sonlu bir küme gibi düşünebiliriz:

Bir sipariş durumu değişkeni için $d \in S$ koşulu geçerlidir. Patates gibi kümede bulunmayan bir değerin atanması tür güvenli bir dilde derleme hatası üretir. Enum’un temel avantajı tam olarak budur: Geçersiz durumları daha program çalışmadan yakalamak.

Temel kullanım

C# ile bir sipariş durumunu şöyle modelleyebiliriz:

public enum SiparisDurumu
{
    Bekliyor = 1,
    Hazirlaniyor = 2,
    Kargoda = 3,
    TeslimEdildi = 4,
    IptalEdildi = 5
}

SiparisDurumu durum = SiparisDurumu.Kargoda;

if (durum == SiparisDurumu.Kargoda)
{
    Console.WriteLine("Siparişiniz yola çıktı!");
}

Buradaki sayısal karşılıklar depolama, veritabanı uyumluluğu veya dış sistemlerle iletişim için kullanılabilir. Ancak uygulama kodunda sayı yerine isim tercih edilir. 3 tek başına sessiz ve gizemliyken SiparisDurumu.Kargoda adeta megafonla ne olduğunu söyler.

Enum değerleri switch ifadeleriyle de oldukça uyumludur:

string MesajOlustur(SiparisDurumu durum)
{
    return durum switch
    {
        SiparisDurumu.Bekliyor => "Sipariş onay bekliyor.",
        SiparisDurumu.Hazirlaniyor => "Mutfakta hareket var!",
        SiparisDurumu.Kargoda => "Paket yolda.",
        SiparisDurumu.TeslimEdildi => "Afiyet olsun!",
        SiparisDurumu.IptalEdildi => "Sipariş iptal edildi.",
        _ => "Bilinmeyen durum."
    };
}

Bu fonksiyon, her kategoriyi açıkça ele alır ve durum ile kullanıcı mesajı arasındaki ilişkiyi merkezi bir yerde tutar.

Bayrak enum’ları

Bazı kategorilerde değişken aynı anda birden fazla seçeneği taşımalıdır. Dosya izinleri bunun klasik örneğidir. İkili sistemde her seçeneğe $2^n$ biçiminde bir değer verirsek seçenekleri bit düzeyinde birleştirebiliriz:

[Flags]
public enum DosyaIzni
{
    Yok = 0,
    Oku = 1,      // 2^0
    Yaz = 2,      // 2^1
    Calistir = 4  // 2^2
}

DosyaIzni izin = DosyaIzni.Oku | DosyaIzni.Yaz;
bool yazabilir = izin.HasFlag(DosyaIzni.Yaz);

Burada birleşik değer $1 + 2 = 3$ olur; fakat kod hâlâ anlamlı isimlerle çalışır. Normal enum tek seçim, bayrak enum’u ise kontrollü çoklu seçim için uygundur.

Ne zaman kullanılmamalı?

Seçenekler çalışma sırasında veritabanından ekleniyor, sık sık değişiyor veya kullanıcı tarafından yönetiliyorsa enum fazla katı kalabilir. Böyle durumlarda tablo, yapılandırma dosyası ya da sınıf tabanlı bir model daha uygundur. Ayrıca enum üyelerini silmek veya sayısal değerlerini değiştirmek, kayıtlı eski verilerle uyumsuzluk yaratabilir.

Özetle enum; sınırlı, kararlı ve anlamlı kategorileri modellemek için küçük ama etkili bir araçtır. Sihirli değerleri kovar, otomatik tamamlama desteği sunar, geçersiz atamaları azaltır ve kodu kendi kendini açıklayan bir belgeye dönüştürür.

``

Fonksiyon sözleşmesi nedir?

Bir fonksiyonu matematiksel olarak $f: A \rightarrow B$ biçiminde düşünebiliriz. Burada $A$, fonksiyonun kabul ettiği değerler kümesini; $B$ ise üretebileceği sonuçlar kümesini temsil eder. Örneğin iki tam sayıyı toplayan bir fonksiyon şu sözleşmeye sahiptir:

Bu ifade, iki tam sayı verildiğinde sonucun da tam sayı olacağını söyler. Programlama dillerindeki tip belirtimleri aynı fikri kaynak koda taşır. Böylece fonksiyonun davranışını anlamak için gövdesindeki her satırı okumak gerekmez.

TypeScript ile basit bir örnek:

function topla(a: number, b: number): number {
  return a + b;
}

const sonuc = topla(12, 8);

Buradaki a: number ve b: number parametre sınırlarını, son : number ise dönüş garantisini belirtir. topla("12", 8) çağrısı çalışma aşamasına ulaşmadan hata verir. Böylece JavaScript’in sürprizli birleştirme davranışı yerine öngörülebilir toplama işlemi elde edilir.

Tipli ve tipsiz yaklaşım

Tip belirtimi yalnızca sözdizimsel bir süs değildir. Özellikle birçok modülün ve geliştiricinin bulunduğu projelerde iletişim aracına dönüşür.

Dinamik dillerde de aynı avantajlardan yararlanılabilir. Python tip ipuçları çalışma zamanında zorunlu doğrulama yapmasa da mypy ve benzeri araçlar tarafından denetlenebilir:

def indirimli_fiyat(fiyat: float, oran: float) -> float:
    """Fiyata belirtilen oranda indirim uygular."""
    return fiyat * (1 - oran)

sonuc: float = indirimli_fiyat(250.0, 0.20)

Hesaplama $y = x(1-r)$ formülünü uygular. İmza sayesinde fiyat ve oran değerlerinin ondalıklı sayı, sonucun da float olması beklendiği hemen anlaşılır.

Daha kesin modeller kurmak

Her şeyi string, number veya object olarak işaretlemek yeterli değildir. Alan modelini temsil eden özel tipler, geçersiz durumların oluşturulmasını zorlaştırır.

type Kullanici = {
  id: number;
  ad: string;
  aktif: boolean;
};

function gorunenAd(kullanici: Kullanici): string {
  return kullanici.aktif
    ? kullanici.ad
    : `${kullanici.ad} (pasif)`;
}

Bu fonksiyon rastgele bir nesne değil, gerekli alanları taşıyan bir Kullanici ister. Dönüş değerinin daima metin olduğu da garanti edilir. Başka bir modül fonksiyonu kullanırken iç uygulamaya değil bu sözleşmeye bağımlı olur.

Aşırı katılığa dikkat

Tip güvenliği, her fonksiyonu gereksiz ölçüde daraltmak anlamına gelmez. Aynı mantık farklı türlerle çalışıyorsa generic tipler kullanılabilir:

function ilkEleman<T>(liste: T[]): T | undefined {
  return liste[0];
}

Buradaki T, esnekliği korurken giriş ve çıkış arasındaki ilişkiyi kaybetmez. Sayı listesi sayı, metin listesi metin döndürür. Boş liste ihtimali ise undefined ile açıkça modellenir.

Sonuç olarak iyi tip belirtimi, “Bu fonksiyon muhtemelen ne döndürür?” sorusunu ortadan kaldırır. Küçük projelerde okunabilirlik, büyük projelerde modüler güvenlik sağlar. En iyi yaklaşım; anlamlı alan tipleri oluşturmak, belirsiz any kullanımını azaltmak ve hata ihtimallerini dönüş tipinde açıkça ifade etmektir. Tipler kelepçe değil, kodun korkuluklarıdır: hareketi engellemez, uçurumdan düşmeyi önler.

``

Git geçmişinin teorik yapısı

Git commit’leri yalnızca sıralı kayıtlar değildir. Her commit, kendisinden önce gelen commit’in kimliğini taşıyan bir düğümdür. Basitleştirilmiş bir geçmiş şöyle gösterilebilir:

A <- B <- C <- D
               ^
              HEAD

Burada HEAD, üzerinde çalıştığımız dalın güncel commit’ini işaret eder. Bir commit kimliği; içerik, yazar, zaman ve üst commit bilgileri kullanılarak üretilen bir özettir. Kavramsal olarak bunu şöyle düşünebiliriz:

Bu yapı sayesinde geçmişteki bir commit değiştirilirse onu izleyen kimlikler de değişir. Bu nedenle yayımlanmış geçmişi yeniden yazmak ekip çalışmalarında risklidir.

Geçmişi git log ile okumak

İlk inceleme aracımız git log komutudur:

git log

Bu komut commit kimliklerini, yazarları, tarihleri ve mesajları gösterir. Daha okunabilir bir görünüm için şu sürüm oldukça kullanışlıdır:

git log --oneline --graph --decorate --all

Buradaki --oneline kayıtları kısaltır, --graph dallanmaları görselleştirir, --decorate dal ve etiket adlarını ekler. Belirli bir dosyanın geçmişini incelemek için ise şunu kullanabiliriz:

git log --oneline -- src/app.js

Commit’in hangi değişiklikleri yaptığını görmek için git show <commit-id> kullanılabilir. Böylece geri alma kararı vermeden önce “Suçlu gerçekten bu commit mi?” sorusunu yanıtlarız.

Reset mi, revert mü?

İki komut da geri dönüş sağlar fakat yöntemleri farklıdır:

Reset ile işaretçiyi taşımak

Son commit mesajı veya içeriği yanlışsa ve henüz uzak depoya gönderilmediyse şu komut kullanılabilir:

git reset --soft HEAD~1

HEAD~1, güncel commit’in bir önceki atasını ifade eder. Commit kaldırılır ancak değişiklikler staging alanında kalır; böylece düzenleyip yeniden commit oluşturabiliriz.

git reset --hard HEAD~1

Bu sürüm hem commit’i hem de dosya değişikliklerini siler. Kaydedilmemiş çalışmalar açısından oldukça tehlikelidir. Kısacası --hard, Git dünyasının “Emin misin?” diye iki kez sormamız gereken kırmızı düğmesidir.

Revert ile güvenli geri alma

Hatalı commit uzak depoya gönderildiyse geçmişi değiştirmek yerine ters değişiklik oluşturan yeni bir commit eklemek daha güvenlidir:

git revert a1b2c3d

Geçmiş başlangıçta $A \rightarrow B \rightarrow C$ ise ve C geri alınırsa sonuç $A \rightarrow B \rightarrow C \rightarrow C^{-1}$ olur. Yani C kaybolmaz; etkisini tersine çeviren kayıt eklenir. Bu yaklaşım denetlenebilirliği korur ve ekip arkadaşlarının geçmişiyle çatışmaz.

Yanlış reset yaptıysak ne olacak?

Git çoğu zaman kaçış kapısını açık bırakır. reflog, HEAD işaretçisinin önceki konumlarını gösterir:

git reflog
git reset --hard HEAD@{1}

İkinci komut, uygun kayıt seçildiğinde bizi reset öncesindeki konuma döndürebilir. Yine de reflog kalıcı bir yedek değildir.

Pratik kural basittir: Önce log ve show ile incele, paylaşılmamış geçmişte dikkatli biçimde reset, paylaşılmış geçmişte ise çoğunlukla revert kullan. Komutu çalıştırmadan önce git status kontrolü yapmak da zaman makinesine emniyet kemeri takmak gibidir.

``

Temel fikir: Türü şimdi değil, kullanırken belirle

Normal bir fonksiyon parametrelerinin türünü önceden bilir. Jenerik fonksiyon ise gerçek türün yerine T gibi bir tür parametresi kullanır. Buradaki T, “her şey serbest” anlamına gelmez; derleyicinin çağrı sırasında belirleyeceği bir tür değişkenidir.

Matematiksel olarak normal bir fonksiyonu $f: int → int$ biçiminde düşünürsek, jenerik karşılığı $f_T: T → T$ olur. Başka bir ifadeyle algoritma sabit kalırken tür değişebilir:

Derleyici T yerine kullanılacak gerçek tipi izlediği için yanlış tür atamaları çalışma zamanına bırakılmaz. Böylece hem tekrar azalır hem de tip güvenliği korunur.

Jenerik fonksiyon örneği

Aşağıdaki C# fonksiyonu, verilen iki değerin yerini türlerinden bağımsız olarak değiştirir:

static void YerDegistir<T>(ref T sol, ref T sag)
{
    T gecici = sol;
    sol = sag;
    sag = gecici;
}

int x = 10;
int y = 20;
YerDegistir(ref x, ref y);

string ilk = "Ada";
string ikinci = "Linus";
YerDegistir(ref ilk, ref ikinci);

Fonksiyon iki kez çağrılır: ilkinde T, int; ikincisinde string olur. Aynı algoritma kullanılırken derleyici iki değerin de uyumlu türde olmasını denetler. Örneğin bir int ile string değerini yanlışlıkla değiştirmeye çalışmak derleme hatası üretir. Hata erkenden yakalanır; gece yarısı gelen sürpriz hata bildirimi başka güne kalır.

Jenerik sınıflar ve kısıtlamalar

Jenerikler yalnızca fonksiyonlarda değil, sınıflarda ve arayüzlerde de kullanılabilir. Aşağıdaki depo, yalnızca kimliği bulunan sınıfları kabul eder:

interface IEntity
{
    int Id { get; }
}

class Depo<T> where T : IEntity
{
    private readonly List<T> kayitlar = new();

    public void Ekle(T kayit) => kayitlar.Add(kayit);

    public T? Bul(int id)
    {
        return kayitlar.FirstOrDefault(x => x.Id == id);
    }
}

where T : IEntity ifadesi bir jenerik kısıtlamadır. Bu sayede derleyici, T nesnelerinde Id özelliğinin bulunduğunu bilir. Kısıtlama olmasaydı x.Id kullanımının güvenli olduğuna karar veremezdi.

Neden object yeterli değil?

Her değeri object olarak saklamak ilk bakışta kolay görünür. Ancak geri alırken tür dönüşümü gerekir ve yanlış dönüşüm çalışma zamanında patlayabilir. Değer tiplerinde kutulama ve kutudan çıkarma maliyeti de oluşabilir. Jenerikler, tür bilgisini koruyarak bu riskleri ve gereksiz dönüşümleri azaltır.

Yine de her yere <T> serpiştirmek iyi tasarım değildir. Algoritma gerçekten türden bağımsızsa jenerik kullanmak mantıklıdır. Türlere göre tamamen farklı davranışlar gerekiyorsa arayüz, kalıtım veya strateji deseni daha anlaşılır olabilir.

Özetle jenerikler, “bir kez yaz, birçok türle güvenle kullan” ilkesini hayata geçirir. Daha az kopya kod, daha erken hata tespiti ve daha temiz API’ler sağlar. Doğru kısıtlamalarla birleştiğinde T, belirsiz bir harf olmaktan çıkıp güçlü bir tasarım aracına dönüşür.

Pull Request nedir?

Pull Request (PR), bir dalda yapılan değişikliklerin başka bir dala alınması için oluşturulan resmi bir birleştirme talebidir. GitHub bu adı kullanırken GitLab aynı kavrama Merge Request der. İsimler değişse de temel fikir aynıdır: “Değişikliklerimi tamamladım; lütfen inceleyin ve uygunsa ana projeye dahil edin.”

PR yalnızca kod farklarını gösteren bir ekran değildir. Değişikliğin amacı, test yöntemi, ilişkili görevler, ekran görüntüleri ve inceleme konuşmaları için ortak bir çalışma alanıdır. Böylece kodun neden değiştirildiği, aylar sonra bile commit geçmişinden daha rahat anlaşılır.

Tipik akış şöyledir:

1. Ana daldan yeni bir özellik dalı oluşturulur.
2. Değişiklikler küçük ve anlamlı commit’lerle kaydedilir.
3. Dal uzak depoya gönderilir.
4. Bir Pull Request açılır.
5. Otomatik testler ve statik analiz araçları çalışır.
6. İnceleyiciler yorum yapar veya değişiklik ister.
7. Onaylanan kod ana dalla birleştirilir.

git switch main
git pull
git switch -c feature/kullanici-arama

# Kod değişikliklerinden sonra
git add .
git commit -m "Kullanıcı arama filtresi eklendi"
git push -u origin feature/kullanici-arama

Bu komutlar güncel main dalından bağımsız bir geliştirme dalı oluşturur, değişiklikleri kaydeder ve PR açılabilmesi için uzak depoya gönderir.

Code Review neden gereklidir?

Code Review, başka bir geliştiricinin değişiklikleri sistematik biçimde değerlendirmesidir. Amaç hata avına çıkıp yazarı köşeye sıkıştırmak değil; ortak kod tabanını iyileştirmek ve ekip içinde bilgi paylaşmaktır. İnceleme sırasında doğruluk, performans, güvenlik, test kapsamı, isimlendirme ve sürdürülebilirlik değerlendirilir.

Basitleştirilmiş bir kalite modeli şöyle düşünülebilir:

Burada $D$ doğruluğu, $T$ test edilebilirliği, $O$ okunabilirliği ve $G$ güvenliği temsil eder. $w$ katsayıları ise projenin öncelikleridir. Örneğin finans uygulamasında güvenliğin ağırlığı, küçük bir tanıtım sitesine göre daha yüksek olabilir.

İyi bir PR nasıl hazırlanır?

İyi PR küçük, odaklı ve açıklayıcıdır. Aynı talepte hem kullanıcı araması eklemek hem dosya yapısını tamamen değiştirmek, incelemeyi zorlaştırır. Büyük PR’larda bilişsel yük artar; gözden kaçan hata olasılığı da yükselir. Kabaca inceleme etkinliğini

şeklinde düşünebiliriz. Burada $S$, değişiklik boyutudur. Bu kesin bir fizik yasası değildir; küçük değişikliklerin daha dikkatli incelenebildiğini anlatan pratik bir modeldir.

PR açıklamasında şu bilgiler bulunmalıdır:

• Değişikliğin amacı ve kapsamı
• İlgili görev veya hata kaydı
• Değişikliğin nasıl test edildiği
• Arayüz değiştiyse ekran görüntüsü
• Bilinen sınırlamalar ve riskler

Yapıcı inceleme kültürü

Yorumlar kişiye değil koda yöneltilmelidir. “Bunu yanlış yazmışsın” yerine “Bu koşul boş değer geldiğinde hata üretebilir; burada erken dönüş kullanabilir miyiz?” demek daha yapıcıdır. Yazar da her yorumu saldırı olarak görmemeli, ancak gerekçesini açıklayamadığı önerileri körü körüne uygulamamalıdır.

Sonuç olarak Pull Request bir izin ekranı, Code Review ise bürokratik bir engel değildir. İkisi birlikte hataları erken yakalayan, ekip bilgisini çoğaltan ve ana dalı güvenilir tutan bir mühendislik pratiğidir. Sağlıklı ekiplerde hedef, kimin haklı olduğunu kanıtlamak değil; kodu birlikte daha doğru, anlaşılır ve sürdürülebilir hâle getirmektir.

Kapsülleme neden gereklidir?

Nesne yönelimli programlamanın temel ilkelerinden biri olan kapsülleme, bir nesnenin durumunu temsil eden veriler ile bu verileri yöneten davranışların aynı sınıfta toplanmasıdır. Ancak asıl amaç, alanları sınıfın içine taşımaktan daha fazlasıdır: Verinin geçersiz veya tehlikeli biçimde değiştirilmesini önlemek.

Bir sınıfın durumunu $S$, izin verilen geçerli durumlar kümesini ise $V$ ile gösterelim. İyi bir sınıfın hedefi şudur:

Dışarıdaki kod alanları doğrudan değiştirebiliyorsa bu koşul kolayca bozulabilir. Örneğin bir banka hesabının bakiyesi, kontrol yapılmadan negatif bir değere dönüştürülebilir. Kapsülleme sayesinde değişiklikler metotlar üzerinden geçirilir ve sınıf kendi kurallarını korur.

Erişim belirleyiciler ne söyler?

Java, C# ve C++ gibi dillerde ayrıntılar değişebilse de temel yaklaşım benzerdir:

public, sınıfın dış dünyaya verdiği sözleşmedir. Bu nedenle her alanı veya metodu düşünmeden public yapmak, evin bütün kapılarını açık bırakmaya benzer. private, bir üyenin yalnızca tanımlandığı sınıf tarafından kullanılmasını sağlar. protected ise özellikle kalıtım sırasında alt sınıflara kontrollü erişim vermek için kullanılır.

Java ile kapsüllenmiş hesap örneği

Aşağıdaki sınıf, bakiyeyi dışarıdan doğrudan değiştirmeye izin vermez:

public class BankAccount {
    private String owner;
    private double balance;

    public BankAccount(String owner, double initialBalance) {
        if (initialBalance < 0) {
            throw new IllegalArgumentException("Başlangıç bakiyesi negatif olamaz.");
        }
        this.owner = owner;
        this.balance = initialBalance;
    }

    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Tutar pozitif olmalıdır.");
        }
        balance += amount;
    }

    public boolean withdraw(double amount) {
        if (amount <= 0 || amount > balance) {
            return false;
        }
        balance -= amount;
        return true;
    }

    public double getBalance() {
        return balance;
    }
}

Burada balance alanı private olduğu için aşağıdaki müdahale derleme hatası üretir:

BankAccount account = new BankAccount("Ada", 1000);
// account.balance = -5000; // Erişim yasak!
account.deposit(250);
account.withdraw(100);

deposit ve withdraw metotları birer kontrol noktasıdır. Para yatırıldıktan sonra yeni bakiye matematiksel olarak

şeklinde hesaplanır. Böylece nesnenin iş kuralları tek yerde uygulanır.

Protected kullanırken dikkat

Bir alt sınıfın bazı davranışları özelleştirmesi gerekiyorsa protected yararlı olabilir:

public class RewardAccount extends BankAccount {
    protected double calculateBonus(double amount) {
        return amount * 0.02;
    }
}

Ancak alanları doğrudan protected yapmak, alt sınıfların geçersiz değerler atamasına yol açabilir. Bu yüzden alanları yine private tutup, gerektiğinde protected metotlar sağlamak daha güvenlidir. Kalıtım var diye kasanın anahtarını teslim etmek gerekmez!

Getter ve setter her zaman çözüm mü?

Her private alan için otomatik olarak getter ve setter üretmek gerçek kapsülleme değildir. Kontrolsüz bir setBalance() metodu, alanı public yapmakla neredeyse aynı riski taşır. Sınıfın teknik yapısını değil, anlamlı davranışlarını dışarı açmak gerekir. setBalance(500) yerine deposit(500) denmesi, işlemin niyetini ve kurallarını açıkça ifade eder.

Özetle alanlarda varsayılan tercihiniz private, dışarıya sunulan güvenli davranışlarda public, alt sınıfların kontrollü biçimde kullanacağı genişletme noktalarında ise protected olmalıdır. Böylece sınıflar yalnızca veri taşımaz; kendi tutarlılığını koruyan güvenilir yazılım bileşenlerine dönüşür.

``

Temel veri tipi nedir?

Bir veri tipi, bellekte saklanan değerin nasıl yorumlanacağını ve üzerinde hangi işlemlerin yapılabileceğini tanımlar. Örneğin 10 sayısına 5 eklemek matematiksel toplama üretirken, "10" metnine "5" eklemek çoğu dilde "105" sonucunu verir.

Bir değişkeni matematiksel olarak değer kümesiyle ifade edebiliriz. boolean tipindeki bir $b$ değişkeninin alabileceği değerler şöyledir:

Benzer biçimde, 0 ile 120 arasında sınırlandırılmış bir yaş değeri için hedeflenen küme şudur:

Tip sistemi ilk bölümde değerin sayı olmasını garanti edebilir. Aralık gibi daha özel iş kuralları ise doğrulama kodları veya gelişmiş tip teknikleri gerektirir.

En yaygın temel tipler

null ve undefined birbirine benzese de aynı şeyi anlatmaz. null, geliştiricinin bilinçli biçimde “burada değer yok” demesidir. undefined ise değerin henüz tanımlanmadığını belirtir. Bu ayrım, özellikle API yanıtlarında oldukça önemlidir.

Tip kısıtlaması neden güvenlidir?

Dinamik tipli JavaScript’te aşağıdaki değişken önce sayı, ardından metin olabilir:

let puan = 90;
puan = "doksan";

Kod sözdizimi açısından geçerlidir; ancak daha sonra puan / 2 işlemi yapılırsa beklenmeyen bir sonuç oluşabilir. TypeScript ile değişkenin kabul edeceği değer türü baştan belirtilir:

let puan: number = 90;
puan = 100;       // Geçerli
// puan = "doksan"; // Derleme hatası

const basariliMi: boolean = puan >= 50;
const mesaj: string = basariliMi ? "Tebrikler!" : "Tekrar dene";

Burada puan yalnızca sayı, basariliMi yalnızca mantıksal değer ve mesaj yalnızca metin kabul eder. Hatalı atama yorumdan çıkarılırsa TypeScript, program çalıştırılmadan geliştiriciyi uyarır. Böylece hata üretim ortamında kullanıcıyla tanışmadan önce yakalanır.

Tip çıkarımı ve açık tanımlama

TypeScript her zaman tipin açıkça yazılmasını istemez:

let kullaniciAdi = "deniz"; // string olarak çıkarılır
let girisSayisi = 3;        // number olarak çıkarılır
let aktif = true;           // boolean olarak çıkarılır

Bu mekanizmaya tip çıkarımı denir. Başlangıç değeri tip hakkında yeterli bilgi veriyorsa kısa ve okunaklı kod sağlar. Fonksiyon parametrelerinde ise açık tip kullanmak daha güvenlidir:

function indirimliFiyat(fiyat: number, oran: number): number {
  return fiyat * (1 - oran);
}

const sonuc = indirimliFiyat(500, 0.2); // 400

Formül $F_{son} = F \times (1-r)$ şeklindedir. Tipler fiyat ve oran değerlerinin metin olmasını engeller; fakat oranın 0 ile 1 arasında olduğunu tek başına doğrulamaz. Bu nedenle çalışma zamanı kontrolleri tip sisteminin tamamlayıcısıdır.

Sonuç

Temel veri tipleri yalnızca sözdizimsel ayrıntılar değildir; programın veri sözleşmesini oluşturur. Doğru tip seçimi otomatik tamamlama kalitesini artırır, yeniden düzenlemeyi kolaylaştırır ve hataları erkenden görünür kılar. Değişkene “her şeyi kabul et” demek pratik görünebilir, fakat güvenli yazılım çoğu zaman doğru yerde nazikçe “hayır” diyebilen yazılımdır.

Tip çıkarımı tam olarak nedir?

Tip çıkarımı, derleyicinin bir ifadenin veri türünü programcının açık bildirimine ihtiyaç duymadan hesaplamasıdır. Basit bir modelle değişkenin türünü şöyle gösterebiliriz:

Burada $x$ değişkeni, $e$ ise ona atanan ifadedir. Örneğin x = 42 ifadesinde derleyici, 42 sabitinin türünü inceler ve dile bağlı olarak int, Int veya benzeri bir tür seçer.

Bu işlem çoğunlukla derleme zamanında gerçekleşir. Yani program çalışırken tür tahmini yapılmaz; derleyici daha çalıştırılabilir dosya üretilmeden önce kararını verir. Bu nedenle tip çıkarımı, dinamik tiplemeyle aynı şey değildir.

Derleyici nasıl karar verir?

Derleyici önce sağ taraftaki ifadeyi analiz eder. Sabitleri, fonksiyonların dönüş türlerini, operatörleri ve varsa genel tür kısıtlarını değerlendirir. Ardından bulunan türü değişkenle eşleştirir.

C# dilindeki şu örneğe bakalım:

var puan = 95;             // Derleyici türü int olarak çıkarır.
var mesaj = "Başarılı";   // Tür string olur.
var oran = 0.85;           // Varsayılan olarak double seçilir.

Buradaki var, değişkenin türsüz olduğu anlamına gelmez. puan, derleme sonrasında kesin biçimde int kabul edilir. Bu yüzden aşağıdaki atama geçersizdir:

var puan = 95;
puan = "Doksan beş"; // Hata: string, int değişkenine atanamaz.

Derleyicinin ilk değerden hareket etmesi, türün daha sonra sürekli değişebileceği anlamına gelmez. İlk ifade yalnızca başlangıçtaki kanıttır; ulaşılan tür ise değişkenin kapsamı boyunca geçerli sözleşmedir.

Fonksiyonlarda ve koleksiyonlarda çıkarım

Tip çıkarımı yalnızca basit değişkenlerle sınırlı değildir. Genel fonksiyon çağrılarında tür parametreleri de argümanlardan bulunabilir:

function ilkEleman<T>(liste: T[]): T {
  return liste[0];
}

const sonuc = ilkEleman([10, 20, 30]);
// T, number olarak çıkarılır; sonuc da number olur.

Derleyici burada dizinin elemanlarını inceler ve şu ilişkiyi kurar:

Bu yaklaşım, genel ve yeniden kullanılabilir kod yazmayı kolaylaştırır. Programcı her çağrıda <number> yazmak zorunda kalmaz.

Ne zaman açık tür yazılmalı?

Tip çıkarımı faydalı olsa da her yerde kullanmak okunabilirliği artırmaz. Değer türü ilk bakışta belliyse çıkarım idealdir. Karmaşık API dönüşlerinde, değişkenin niyetini vurgulamak gerektiğinde veya daha geniş bir tür hedeflendiğinde açık bildirim daha anlaşılır olabilir.

IEnumerable<int> puanlar = new List<int> { 70, 85, 100 };

Burada var kullanmak mümkün olsa da açık tür, kodun yalnızca List<int> uygulamasına değil IEnumerable<int> sözleşmesine dayandığını anlatır.

Kısacası tip çıkarımı, geliştiricinin yerine rastgele karar veren bir mekanizma değil; ifadelerden, kısıtlardan ve dil kurallarından mantıksal sonuç üreten bir derleyici özelliğidir. Doğru kullanıldığında kodu sadeleştirir, tekrarları azaltır ve tip güvenliğinden vazgeçmeden daha akıcı programlama sağlar.