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.

``

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.

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.

``

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.

Statik ve dinamik tip sistemleri

Bir değişkenin hangi değerleri taşıyabileceği, programlama dilinin tip sistemi tarafından belirlenir. C++ gibi statik tipli bir dilde değişkenin tipi derleme sırasında bilinir ve uygunsuz işlemler reddedilir. JavaScript’te ise tip, değişkenden çok çalışma anındaki değere aittir.

let value = 10;
value = "on";
console.log(value * 2); // NaN

Bu kod JavaScript açısından geçerlidir. Sorun ancak işlem çalıştırıldığında ortaya çıkar. TypeScript aynı belirsizliği derleme aşamasına taşır:

let value: number = 10;
value = "on"; // Hata: string, number tipine atanamaz

Buradaki amaç programı yavaşlatan çalışma zamanı kontrolleri eklemek değildir. TypeScript tipleri JavaScript çıktısı üretilirken siler. Başka bir ifadeyle tip sistemi, çalışan programın değil, program hakkındaki bilgimizin parçasıdır.

Tip güvenliğinin teorik anlamı

Bir tip, olası değerler kümesi olarak düşünülebilir. Örneğin number tipi $N$ değer kümesini, string tipi ise $S$ kümesini temsil etsin. Bir fonksiyonun imzası şöyle modellenebilir:

Bu ifade, fonksiyonun sayı kabul edip sayı ürettiğini söyler. Fonksiyona $x \in S$ verilmesi, tanımlanan sözleşmenin ihlalidir. TypeScript derleyicisi bu ihlali program çalışmadan yakalamaya çalışır.

function double(input: number): number {
  return input * 2;
}

double(21);     // 42
double("21");   // Derleme hatası

Bu garanti mutlak değildir. Ağdan gelen JSON, kullanıcı girdisi veya yanlış kullanılan any, derleyicinin bilgisini aşabilir. Dolayısıyla TypeScript’in güvenliği, yalnızca ispatlayabildiği sınırlar içinde geçerlidir.

Yapısal tipleme: İsim değil, biçim önemlidir

C++ çoğunlukla bildirilen tip kimliğine önem verirken TypeScript yapısal tipleme kullanır. Bir nesne gerekli alanlara sahipse ilgili tipe uyumlu kabul edilir. Bu yaklaşım JavaScript’in ördek tipleme geleneğiyle uyumludur: Ördek gibi görünüyorsa ve yüzüyorsa, büyük olasılıkla ördektir.

interface User {
  id: number;
  name: string;
}

const customer = {
  id: 7,
  name: "Ada",
  premium: true
};

function greet(user: User): string {
  return `Merhaba ${user.name}`;
}

greet(customer);

customer, açıkça User olarak tanımlanmamasına rağmen gerekli yapıyı taşır. Böylece katı güvenlik ile JavaScript’in nesne esnekliği arasında kullanışlı bir denge kurulur.

Tip çıkarımı ve daraltma

TypeScript her değişkene açıklama yazılmasını istemez. const score = 100 ifadesinden tipin number olduğunu çıkarabilir. Birleşim tiplerinde ise kontrol akışını analiz ederek olasılıkları daraltır:

function format(value: string | number): string {
  if (typeof value === "number") {
    return value.toFixed(2);
  }

  return value.trim();
}

Bu davranış, tip sistemini yalnızca yasak koyan bir bekçi olmaktan çıkarıp kodu anlayan bir asistana dönüştürür. Editör otomatik tamamlama sunar, yeniden adlandırma işlemleri güvenilirleşir ve API sözleşmeleri belgelenebilir hâle gelir.

Sonuç olarak TypeScript, JavaScript’e C++ kostümü giydirmez. Bellek modeli, çalışma ortamı ve dinamik nesne yapısı hâlâ JavaScript’e aittir. TypeScript’in yaptığı şey, esnek bir dilin üzerine derleme zamanlı bir mantık ağı sermektir. Bu ağ tüm hataları yakalayamaz; fakat büyük projelerde yanlış varsayımları erkenden göstererek hata maliyetini ciddi ölçüde azaltır.

``

TypeScript Aslında Ne Yapar?

TypeScript, JavaScript’in üzerine statik tür sistemi ekleyen bir programlama dilidir. Tarayıcılar ve Node.js, TypeScript kodunu doğrudan çalıştırmaz. Bu nedenle .ts uzantılı dosyalar, TypeScript derleyicisi anlamına gelen tsc tarafından JavaScript’e dönüştürülür.

Bu dönüşümü basitçe şöyle gösterebiliriz:

Derleme sırasında türler kontrol edilir ve daha sonra silinir. Başka bir ifadeyle TypeScript’in tür sistemi geliştirme zamanında çalışır; ortaya çıkan JavaScript dosyasında tür açıklamaları bulunmaz.

Teorik olarak bir fonksiyonun beklediği tür $T$, gönderilen değerin türü $G$ olsun. Güvenli bir çağrı için temel beklenti $G \subseteq T$ biçiminde düşünülebilir. Uyumsuzluk varsa derleyici henüz programı çalıştırmadan bizi uyarır.

Node.js ve Proje Kurulumu

Öncelikle Node.js’in güncel LTS sürümünü resmi sitesinden kurun. Kurulumla birlikte paket yöneticisi npm de bilgisayarınıza gelir. Terminalde doğrulama yapabilirsiniz:

node --version
npm --version

Ardından proje klasörünü oluşturup bir Node.js projesi başlatalım:

mkdir typescript-baslangic
cd typescript-baslangic
npm init -y
npm install --save-dev typescript

Burada TypeScript’i global olarak değil, projeye özel bir geliştirme bağımlılığı şeklinde kurduk. Böylece farklı projeler farklı derleyici sürümlerini kullanabilir. Kurulumu doğrulamak için şu komutu çalıştırın:

npx tsc --version

npx, projenin node_modules klasöründeki yerel TypeScript derleyicisini bulup çalıştırır.

tsconfig.json Yapılandırması

TypeScript yapılandırma dosyasını otomatik oluşturabiliriz:

npx tsc --init

Başlangıç için dosyayı daha sade bir içerikle düzenleyelim:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "rootDir": "src",
    "outDir": "dist",
    "strict": true,
    "esModuleInterop": true
  },
  "include": ["src/**/*.ts"]
}

rootDir, kaynak kodların yerini; outDir ise üretilen JavaScript dosyalarının hedefini belirtir. strict, daha kapsamlı tür denetimlerini etkinleştirir. target seçeneği de üretilecek JavaScript’in dil seviyesini belirler.

VS Code Ortamını Hazırlama

Proje klasörünü VS Code ile açın:

code .

VS Code, TypeScript desteğini yerleşik olarak sunar. İsterseniz ESLint ve Prettier eklentilerini de kurarak kod kalitesi ile biçimlendirmeyi otomatikleştirebilirsiniz. Şimdi src/index.ts dosyasını oluşturalım:

type Kullanici = {
  ad: string;
  puan: number;
};

function seviyeHesapla(kullanici: Kullanici): string {
  return kullanici.puan >= 100 ? "Usta" : "Çırak";
}

const yazilimci: Kullanici = {
  ad: "Ada",
  puan: 120
};

console.log(`${yazilimci.ad}: ${seviyeHesapla(yazilimci)}`);

Bu örnekte Kullanici türü nesnenin sözleşmesini tanımlar. puan alanına yanlışlıkla metin verirseniz VS Code, daha derleme yapmadan kırmızı bir uyarı gösterecektir.

Projeyi derleyip çalıştırmak için:

npx tsc
node dist/index.js

Terminalde Ada: Usta çıktısını görüyorsanız zincirin tamamı çalışıyor demektir: VS Code kodu analiz etti, tsc türleri denetleyip JavaScript üretti ve Node.js sonucu çalıştırdı. Artık daha büyük TypeScript maceralarına hazırsınız!

Type alias nedir?

TypeScript’te type anahtar sözcüğü, mevcut bir tip ifadesine yeni bir ad verir. En basit örnekle başlayalım:

type UserId = string;

const activeUserId: UserId = "usr_42";

Burada UserId, teknik olarak hâlâ string tipidir. Ancak değişkenin sıradan bir metin değil, kullanıcı kimliği taşıdığı artık çok daha açıktır. Type alias yeni bir çalışma zamanı değeri veya sınıf üretmez; yalnızca derleme aşamasında kullanılır ve JavaScript çıktısından silinir.

Bunu matematiksel olarak $A = B$ biçiminde düşünebiliriz: UserId ile string farklı adlara sahip olsa da aynı değer kümesini temsil eder. Dolayısıyla TypeScript’in yapısal tip sisteminde her string, aksi yönde özel bir marka oluşturulmadıkça UserId olarak kabul edilebilir.

Karmaşık nesneleri sadeleştirmek

Takma adların asıl gücü, iç içe geçmiş nesne tiplerinde ortaya çıkar:

type Address = {
  city: string;
  district: string;
  postalCode?: string;
};

type User = {
  id: string;
  name: string;
  address: Address;
};

function printUser(user: User): void {
  console.log(`${user.name} - ${user.address.city}`);
}

Address ayrı bir kavram olarak tanımlandığı için hem tekrar önlenir hem de User tipi daha kolay okunur. Adres yapısı değiştiğinde onlarca fonksiyon imzasını düzenlemek yerine tek bir merkezi tanım güncellenir.

Birleşim ve kesişim tipleri

Type alias yalnızca nesnelere isim vermek için kullanılmaz. Birleşim, kesişim, tuple ve fonksiyon tipleri de adlandırılabilir:

type RequestStatus = "idle" | "loading" | "success" | "error";
type Coordinates = [latitude: number, longitude: number];
type Logger = (message: string, level?: "info" | "warn") => void;

type Timestamped = { createdAt: Date };
type Product = { id: number; name: string };
type StoredProduct = Product & Timestamped;

Birleşim tipi $T = A \cup B$ yaklaşımıyla, değerin izin verilen kümelerden birine ait olmasını sağlar. RequestStatus örneğinde rastgele bir metin yerine yalnızca dört durum kabul edilir. Kesişim tipi $T = A \cap B$ ise bir değerin iki tipin özelliklerini birlikte taşımasını ister.

Generic takma adlarla yeniden kullanılabilirlik

Generic yapılar, farklı veri tipleri için aynı şablonu kullanmamızı sağlar:

type ApiResponse<T> = {
  data: T | null;
  error: string | null;
  statusCode: number;
};

type UserResponse = ApiResponse<User>;

Buradaki T, daha sonra yerleştirilecek tip için parametredir. Böylece kullanıcı, ürün veya sipariş yanıtlarında aynı API yapısını tekrar yazmak gerekmez. Bir yapının $n$ farklı veri modeli için kullanıldığını düşünürsek, tekrar miktarı yaklaşık $n \times k$ satırdan tek bir k satırlık şablona indirilebilir.

Type alias mı, interface mi?

Nesne odaklı ve sonradan genişletilecek genel API sözleşmelerinde interface; union, tuple, fonksiyon veya birleşik tiplerde type genellikle daha uygundur. Bu kesin bir savaş değil, doğru aleti seçme meselesidir.

Son olarak takma adları Data, Info veya Thing gibi belirsiz isimlerle doldurmayın. CheckoutResult, AuthenticatedUser ve ProductFilter gibi niyeti anlatan adlar seçin. İyi bir type alias kodu yalnızca kısaltmaz; geliştiriciye sistemin iş kurallarını sessizce anlatan küçük bir belgeye dönüşür.

any: TypeScript’e kısa bir mola verdirmek

any, TypeScript’in tip denetimini ilgili değer için büyük ölçüde kapatır. any tipindeki bir değişkene her tür değer atanabilir ve bu değişken üzerinde neredeyse her işlem gerçekleştirilebilir.

let veri: any = "TypeScript";

veri.toUpperCase(); // Çalışabilir
veri = 42;
veri.toFixed(2);    // Bu da çalışabilir
veri.olmayANMetot(); // Derleyici itiraz etmez!

Son satır TypeScript tarafından kabul edilir; fakat çalışma zamanında büyük olasılıkla TypeError oluşur. Yani any, JavaScript’in eski ve özgür dünyasına geçici bir dönüş bileti gibidir. Bilet eğlencelidir, fakat emniyet kemeri yanında verilmez.

Teorik olarak any, tip sistemi içinde hem üst hem alt tip gibi davranabilen özel bir kaçış mekanizmasıdır. Basitleştirilmiş biçimde, herhangi bir $T$ tipi için şu esneklik düşünülebilir:

Bu çift yönlü geçiş, tip denetiminin sağladığı garantileri zayıflatır. Dolayısıyla any, bilinçli ve sınırlı kullanılmalıdır.

unknown: Önce kontrol, sonra hareket

unknown da her tür değeri kabul eder. Fakat değeri kullanmadan önce tipini daraltmamızı, yani type narrowing yapmamızı zorunlu kılar.

let cevap: unknown = "Merhaba dünya";

// cevap.toUpperCase(); // Hata: Tip henüz bilinmiyor

if (typeof cevap === "string") {
  console.log(cevap.toUpperCase());
}

Burada typeof kontrolünden sonra TypeScript, cevap değişkeninin ilgili blok içinde string olduğunu bilir. Bu yaklaşımın mantığı şöyledir:

Başka bir ifadeyle unknown, belirsizliği saklamaz; onu çözme sorumluluğunu programcıya açıkça verir.

Temel farklar

Gerçek dünyada güvenli veri işleme

Dış kaynaklardan gelen JSON verileri, unknown için ideal bir kullanım alanıdır. Çünkü sunucunun sözleşmeye her zaman uyacağını varsaymak risklidir.

type Kullanici = {
  ad: string;
  yas: number;
};

function kullaniciMi(deger: unknown): deger is Kullanici {
  if (typeof deger !== "object" || deger === null) {
    return false;
  }

  const aday = deger as Record<string, unknown>;
  return typeof aday.ad === "string" &&
         typeof aday.yas === "number";
}

const hamVeri: unknown = JSON.parse('{"ad":"Ada","yas":28}');

if (kullaniciMi(hamVeri)) {
  console.log(`${hamVeri.ad}, ${hamVeri.yas} yaşında.`);
}

kullaniciMi fonksiyonu bir type guard oluşturur. Yalnızca nesne yapısı doğrulandığında veriye Kullanici gibi davranılır. Böylece API’den gelen sürpriz bir dizi, null veya eksik alanlı nesne uygulamayı kolayca sabote edemez.

Hangisini seçmeliyiz?

Yeni kod yazarken varsayılan tercih unknown olmalıdır. any; tip tanımı bulunmayan eski kütüphaneleri bağlamak, aşamalı JavaScript dönüşümü yapmak veya kısa süreli prototip geliştirmek için kullanılabilir. Yine de mümkün olan en küçük alana hapsedilmelidir.

Kısacası any, “Ne yaptığımı biliyorum, bana karışma” der. unknown ise “Önce kanıtla, sonra devam et” yaklaşımını benimser. Büyük ve uzun ömürlü projelerde ikinci cümle genellikle daha az hata, daha iyi otomatik tamamlama ve daha huzurlu geliştiriciler anlamına gelir.

Union tipi: Bu veya şu

Union, | operatörüyle oluşturulur ve bir değerin belirtilen tiplerden en az birine uygun olabileceğini anlatır. Matematiksel olarak iki tipin birleşimini şöyle gösterebiliriz:

Örneğin kullanıcı kimliği bazı sistemlerde sayı, bazılarında metin olabilir:

type Kimlik = string | number;

function kimlikYazdir(kimlik: Kimlik): void {
  console.log(`Kullanıcı kimliği: ${kimlik}`);
}

kimlikYazdir(42);
kimlikYazdir("USR-42");

Bu fonksiyon hem number hem de string kabul eder. Ancak TypeScript, değerin o anda hangi tipe ait olduğunu bilmeden tipe özel işlemler yapılmasına izin vermez. Örneğin doğrudan kimlik.toUpperCase() çağırmak hatalıdır; çünkü sayıların böyle bir metodu yoktur.

Çözüm, type narrowing, yani tip daraltmadır:

function kimlikBicimlendir(kimlik: string | number): string {
  if (typeof kimlik === "string") {
    return kimlik.toUpperCase();
  }

  return kimlik.toFixed(0);
}

typeof kontrolünden sonra TypeScript ilk dalda değerin string, diğer dalda ise number olduğunu anlar. Böylece esneklik uğruna tip güvenliğinden vazgeçilmez.

Intersection tipi: Hem bu hem şu

Intersection, & operatörüyle tanımlanır. Oluşan tip, birleştirilen tiplerin bütün gereksinimlerini aynı anda karşılamalıdır:

Bir çalışanı hem kişi bilgileriyle hem de kurumsal yetkilerle modelleyelim:

interface Kisi {
  ad: string;
  yas: number;
}

interface Calisan {
  departman: string;
  yetkiSeviyesi: number;
}

type KurumsalKullanici = Kisi & Calisan;

const kullanici: KurumsalKullanici = {
  ad: "Ada",
  yas: 28,
  departman: "Yazılım",
  yetkiSeviyesi: 3
};

KurumsalKullanici, iki arayüzden yalnızca birini seçmez; ikisinin alanlarını da zorunlu tutar. departman veya yas kaldırılırsa derleyici itiraz eder. Intersection’ı, farklı LEGO setlerini aynı modelde kullanmak gibi düşünebiliriz: Parçaların hiçbiri kaybolmaz.

Temel farklar

Ayırt edilebilir union modeli

Union tiplerinin en güçlü kullanım alanlarından biri, her seçeneğe sabit bir ayırt edici alan eklemektir:

type Sonuc =
  | { durum: "basarili"; veri: string[] }
  | { durum: "hatali"; mesaj: string };

function sonucuGoster(sonuc: Sonuc): void {
  switch (sonuc.durum) {
    case "basarili":
      console.log(sonuc.veri.join(", "));
      break;
    case "hatali":
      console.error(sonuc.mesaj);
      break;
  }
}

Buradaki durum alanı, union üyelerini ayırt eden etikettir. Başarılı sonuçta veri, hatalı sonuçta mesaj güvenle kullanılabilir. Bu yaklaşım API yanıtlarında ve durum makinelerinde sık görülür.

Tehlikeli kesişimler

Her intersection mantıklı bir sonuç üretmez. Örneğin string & number, aynı değerin eş zamanlı olarak hem metin hem sayı olmasını ister. Böyle bir değer üretilemeyeceği için sonuç pratikte never tipidir:

type Imkansiz = string & number; // never

Benzer şekilde, aynı isimli alanlar uyumsuz tiplerle kesiştirildiğinde ilgili alan kullanılamaz hâle gelebilir. Bu nedenle intersection oluştururken arayüzlerin çelişmediği kontrol edilmelidir.

Özetle union, “seçeneklerden biri”; intersection ise “gereksinimlerin tamamı” demektir. Alternatif akışları union ile, farklı yetenekleri taşıyan birleşik nesneleri intersection ile modellemek kodun niyetini görünür kılar. TypeScript de bu modelin dışına çıktığınız anda nazik ama kararlı bir bekçi gibi sizi uyarır.