``

Fonksiyon aşırı yükleme nedir?

Function overloading, aynı kapsam içerisinde aynı isimli fakat farklı parametre listelerine sahip birden fazla fonksiyon tanımlamaktır. Parametre listesindeki tür, sayı veya sıralama değiştiğinde yeni bir overload meydana gelir.

#include <iostream>
#include <string>

int topla(int a, int b) {
    return a + b;
}

double topla(double a, double b) {
    return a + b;
}

std::string topla(const std::string& a, const std::string& b) {
    return a + b;
}

int main() {
    std::cout << topla(4, 7) << '\n';
    std::cout << topla(2.5, 1.8) << '\n';
    std::cout << topla(std::string("Merhaba "), std::string("C++"));
}

Burada topla(4, 7) çağrısı int sürümünü, ondalıklı argümanlar double sürümünü seçer. Son sürüm ise iki metni birleştirir. const std::string& kullanılması, metinlerin gereksiz yere kopyalanmasını önler.

Derleyici doğru fonksiyonu nasıl seçer?

Derleyici, çağrıdaki argümanları mevcut adayların parametreleriyle karşılaştırır. Bu sürece overload resolution denir. Basitleştirilmiş biçimde her aday için bir dönüşüm maliyeti düşünülebilir:

Burada $C_i$, ilgili argümanın parametre türüne dönüştürülme maliyetidir. En düşük $S$ değerine sahip aday seçilir. Tam eşleşme genellikle standart tür dönüşümünden, standart dönüşüm de kullanıcı tanımlı dönüşümden daha güçlüdür.

Neler overload oluşturur?

Aşağıdaki fonksiyonlar geçerli biçimde aşırı yüklenebilir:

void yazdir(int deger);
void yazdir(double deger);
void yazdir(int deger, int tekrar);
void yazdir(const std::string& metin);

Birincisi ve ikincisi parametre türüyle, üçüncüsü parametre sayısıyla ayrılır. Ancak yalnızca dönüş türünü değiştirmek yeterli değildir:

int hesapla(int x);
// double hesapla(int x); // Hata: Parametre listesi aynı!

Çağıran kod yalnızca hesapla(5) yazdığında hangi dönüş türünü istediğini derleyici kesin olarak anlayamaz. Bu nedenle dönüş türü, fonksiyon aşırı yükleme imzasının ayırt edici parçası değildir.

Belirsizlik tuzağı

Dönüşümler eşit derecede uygun olduğunda derleyici seçim yapamaz:

void goster(long deger) {}
void goster(double deger) {}

int main() {
    // goster(10); // Belirsiz çağrı
    goster(10L);   // long sürümü
    goster(10.0);  // double sürümü
}

10, int türündedir ve hem long hem de double türüne dönüştürülebilir. L ve .0 ekleriyle niyet açıkça belirtilir. Benzer sorunlar varsayılan parametrelerle de oluşabilir.

Ne zaman kullanmalıyız?

Aşırı yüklenen fonksiyonlar kavramsal olarak aynı işi yapmalıdır. yazdir, hesapla veya ekle gibi işlemler bunun için uygundur. Bir overload dosya silerken diğeri matematiksel hesap yapıyorsa ortak isim geliştiriciyi şaşırtır.

Kısacası function overloading, C++ arayüzlerini esnek ve okunabilir hâle getirir. Parametre listelerini belirgin tuttuğunuz, örtük dönüşümleri sınırladığınız ve her sürüme aynı kavramsal sorumluluğu verdiğiniz sürece tek bir isim gerçekten birçok yeteneği zarifçe taşıyabilir.

İstisna yönetiminin temel mantığı

Normal koşullarda fonksiyonlar sonuçlarını return ile döndürür. Ancak bir fonksiyon görevini tamamlayamıyorsa sıradan bir sonuç döndürmek yanıltıcı olabilir. Örneğin pozitif sayı bekleyen bir karekök fonksiyonuna negatif değer verilmesi ayrı bir kontrol akışı gerektirir.

İstisna oluştuğunda program, uygun bir catch bloğu bulana kadar çağrı zincirinde geriye ilerler. Bu sürece stack unwinding denir. Matematiksel olarak bir fonksiyonun geçerli kümesini şöyle gösterebiliriz:

Burada $x < 0$ olması, fonksiyon sözleşmesinin ihlal edildiğini belirtir.

Temel try, throw ve catch kullanımı

Aşağıdaki örnek, bölme işleminden önce paydayı denetler. Sıfıra bölme tespit edildiğinde std::runtime_error nesnesi fırlatılır:

#include <iostream>
#include <stdexcept>

double bol(double pay, double payda) {
    if (payda == 0.0) {
        throw std::runtime_error("Sıfıra bölme girişimi!");
    }
    return pay / payda;
}

int main() {
    try {
        std::cout << bol(42, 0) << '\n';
    } catch (const std::runtime_error& hata) {
        std::cerr << "Hata: " << hata.what() << '\n';
    }
}

İstisnanın const referansla yakalanması gereksiz kopyalamayı engeller ve çok biçimliliği korur. what() metodu ise hatanın açıklamasını verir. Program kontrolsüz biçimde çökmek yerine kullanıcıya anlamlı bir mesaj sunar.

Standart mı, özel istisna mı?

C++ standart kütüphanesi std::exception tabanlı birçok hata türü sağlar.

Uygulamaya özgü hatalar için özel bir sınıf da tanımlanabilir:

#include <stdexcept>
#include <string>

class BakiyeHatasi : public std::runtime_error {
public:
    explicit BakiyeHatasi(const std::string& mesaj)
        : std::runtime_error(mesaj) {}
};

void paraCek(double bakiye, double miktar) {
    if (miktar > bakiye) {
        throw BakiyeHatasi("Yetersiz bakiye");
    }
}

Bu yaklaşım, çağıran kodun banka işlemlerine özgü problemi diğer çalışma zamanı hatalarından ayırmasını sağlar.

Yakalama sırası ve yeniden fırlatma

catch blokları özel türden genel türe doğru sıralanmalıdır. Aksi hâlde std::exception gibi genel bir blok, türetilmiş bütün istisnaları önce yakalayabilir.

try {
    paraCek(100, 250);
} catch (const BakiyeHatasi& hata) {
    std::cerr << hata.what() << '\n';
    throw; // Aynı istisnayı üst seviyeye iletir
} catch (const std::exception& hata) {
    std::cerr << "Genel hata: " << hata.what() << '\n';
}

Parametresiz throw;, mevcut istisnayı türünü kaybetmeden yeniden fırlatır. Bu yöntem, alt seviyede kayıt tutup üst seviyede kullanıcıya cevap vermek için kullanışlıdır.

Güvenli tasarım için kısa kurallar

İstisnaları sıradan döngü kontrolü amacıyla değil, gerçekten olağan dışı durumlar için kullanın. Kaynak yönetiminde RAII yaklaşımını tercih edin; std::vector, std::string ve akıllı işaretçiler stack unwinding sırasında otomatik olarak temizlenir. Yıkıcılar mümkünse istisna fırlatmamalıdır. Ayrıca yalnızca gerçekten garanti verebildiğiniz fonksiyonları noexcept olarak işaretleyin.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları görünür, sınıflandırılabilir ve güvenli biçimde yönetilebilir hâle getirir. Böylece programınız ilk beklenmedik durumda havlu atmak yerine kontrollü bir iniş yapar.

``

Operatörlerin temel mantığı

Operatör, bir veya daha fazla değer üzerinde işlem yapan semboldür. Örneğin + iki sayıyı toplarken >= değerleri karşılaştırır. = ile == arasındaki fark özellikle önemlidir: İlki atama, ikincisi eşitlik kontrolüdür.

int puan = 75;              // Atama
bool gectiMi = puan >= 50;  // Karşılaştırma
int bonusluPuan = puan + 10;

Aritmetik operatörler matematiksel işlemleri gerçekleştirir. İki sayı $a$ ve $b$ olmak üzere kalan işlemi $a \bmod b$ biçiminde düşünülebilir. C# dilinde bunun karşılığı % operatörüdür.

Mantıksal operatörler Boolean cebirine dayanır. && için sonuç yalnızca iki ifade de doğruysa doğrudur:

|| operatöründe ise koşullardan birinin doğru olması yeterlidir. C# kısa devre değerlendirmesi uygular; A && B ifadesinde A yanlışsa B çalıştırılmaz. Bu davranış hem performans sağlar hem de bazı null hatalarını engeller.

C#’a özgü kullanışlı işleçler

C#, null değerlerle güvenli çalışmayı kolaylaştıran operatörler sunar. ?. yalnızca nesne null değilse üyeye erişir; ?? ise sol taraf null olduğunda yedek değer üretir.

string? kullaniciAdi = null;
int? uzunluk = kullaniciAdi?.Length;
string gorunenAd = kullaniciAdi ?? "Misafir";

Console.WriteLine(gorunenAd); // Misafir

is tür denetimi ve örüntü eşleştirme için, as ise güvenli tür dönüşümü için kullanılır. Ayrıca nameof(degisken) değişkenin adını metin olarak verir; böylece yeniden adlandırmalara dayanıklı hata mesajları oluşturulur.

if-else ile karar vermek

if bloğu koşul doğru olduğunda çalışır. Alternatif yollar else if ve else ile tanımlanır.

int not = 82;

if (not >= 85)
{
    Console.WriteLine("Pek iyi");
}
else if (not >= 50)
{
    Console.WriteLine("Geçti");
}
else
{
    Console.WriteLine("Tekrar dene");
}

Basit seçimlerde üçlü koşul operatörü kullanılabilir: sonuc = kosul ? dogruDeger : yanlisDeger;. Ancak iç içe üçlü ifadeler kodu bulmacaya çevirebilir; okunabilirlik her zaman kısalıktan değerlidir.

Döngüsel iterasyon mekanizmaları

Döngüler tekrar eden işleri otomatikleştirir. Hangi döngünün seçileceği, tekrar sayısının bilinip bilinmemesine bağlıdır.

string[] diller = { "C#", "Java", "Python" };

foreach (string dil in diller)
{
    if (dil == "Java")
        continue; // Bu turu atlar

    Console.WriteLine(dil);
}

continue mevcut turu atlatırken break döngüyü tamamen bitirir. Sonsuz döngülerden kaçınmak için while koşulunu etkileyen değerin gerçekten değiştiğinden emin olun. Özetle operatörler veriyi işler, koşullar yolu seçer, döngüler ise işi tekrarlar; bu üçlü, neredeyse bütün C# uygulamalarının kontrol merkezidir.

C++ şablonlarında özelleştirme ve aşırı yükleme aynı hedefe gidiyormuş gibi görünür: belirli türlerde farklı davranmak. Fakat derleyicinin gözünde bunlar iki ayrı mekanizmadır. Overloading adaylar arasındaki yarışı belirlerken specialization, yarışı kazanan şablonun özel bir sürümünün bulunup bulunmadığına bakar. Küçük görünen bu sıra farkı, şaşırtıcı sonuçların kaynağıdır.

``

İki mekanizmanın temel anlamı

Bir fonksiyon şablonunu aşırı yüklediğimizde derleyicinin aday listesine yeni bir fonksiyon şablonu ekleriz. Açık özelleştirme ise yeni ve bağımsız bir aday oluşturmaz; mevcut birincil şablonun belirli argümanlar için alternatif uygulamasını tanımlar.

#include <iostream>

template<typename T>
void goster(T) {
    std::cout << "Genel sürüm\n";
}

template<>
void goster<int>(int) {
    std::cout << "int özelleştirmesi\n";
}

template<typename T>
void goster(T*) {
    std::cout << "İşaretçi overload'u\n";
}

Burada üç bildirim varmış gibi görünse de overload çözümlemesinde yalnızca goster(T) ve goster(T*) yarışır. goster<int> ise ilk şablona bağlı bir açık özelleştirmedir.

Derleyicinin seçim sırası

Basitleştirilmiş süreç şöyledir:

1. Görünür fonksiyonlar ve fonksiyon şablonları aday kümeye alınır.
2. Şablon argüman çıkarımı yapılır.
3. Dönüşüm kalitesi ve şablonların kısmi sıralaması değerlendirilir.
4. En iyi overload seçilir.
5. Kazanan bir fonksiyon şablonuysa ona ait açık özelleştirme aranır.

Bunu kabaca

şeklinde düşünebiliriz. Buradaki $C$, uygun adaylar kümesidir. İşlemlerin sırası ters değildir; specialization önce yarışıp overload’u yenemez.

Klasik işaretçi sürprizi

int* p = nullptr;
goster(p);

İlk bakışta T = int* olduğundan genel şablonun int* özelleştirmesinin aranacağı düşünülebilir. Ancak goster(T*), int* argümanı için goster(T) şablonundan daha özeldir. Dolayısıyla pointer overload’u yarışı kazanır. Derleyici artık yalnızca bu kazanan şablona bağlı bir explicit specialization olup olmadığına bakar; diğer birincil şablonun özelleştirmesine geri dönmez.

Bu nedenle bir specialization’ın hangi birincil şablona bağlı olduğu kritik önemdedir. Bildirim sırası ve specialization bildiriminin çağrıdan önce görünür olması da ayrı derleme birimlerinde ciddi farklar yaratabilir. Açık özelleştirme, örtük örneklemeye yol açan ilk kullanımdan önce bildirilmelidir.

Neden fonksiyon şablonları kısmen özelleştirilemez?

Sınıf şablonlarında kısmi özelleştirme geçerlidir:

template<typename T>
struct Bilgi;

template<typename T>
struct Bilgi<T*> {
    static constexpr bool pointer = true;
};

Fakat aşağıdaki fonksiyon biçimi geçersizdir:

template<typename T>
void isle<T*>(T*); // Geçersiz kısmi specialization

Fonksiyonlarda aynı niyet overload ile ifade edilir:

template<typename T>
void isle(T*) {
    // Türetilen her işaretçi türü için ortak davranış
}

Bunun önemli nedeni, fonksiyonlarda zaten overload çözümlemesi bulunmasıdır. Kısmi specialization da eklenseydi iki ayrı sıralama sistemi birbiriyle çakışabilirdi.

Pratik tercih rehberi

Bir tür ailesini yakalamak istiyorsanız overload kullanın. Yalnızca tek ve kesin bir şablon argümanı kombinasyonunda davranışı değiştirecekseniz explicit specialization düşünülebilir. Bununla birlikte fonksiyonlarda overload çoğu zaman daha okunabilir ve öngörülebilirdir.

Modern C++ kodunda if constexpr, kavramlar ve requires ifadeleri de güçlü alternatiflerdir. Özellikle kısıtlı overload’lar, niyeti doğrudan tür sistemi üzerinden anlatır. Altın kural şudur: specialization’ı bağımsız yarışmacı sanmayın; o, ancak bağlı olduğu şablon yarışı kazandığında sahneye çıkan yedek oyuncudur.

Artıklılık ne anlama gelir?

Bir manipülatörün eklem değişkenlerini $q \in R^n$, uç efektör görevini ise $x \in R^m$ ile gösterelim. İleri kinematik ilişki

şeklindedir. Eğer eklem sayısı görev uzayının boyutundan büyükse, yani $n > m$ ise sistem redundant kabul edilir. Örneğin üç boyutlu uzayda yalnızca uç noktanın konumunu kontrol etmek için üç bağımsız değişken yeterliyken yedi eklemli bir kol dört adet fazladan serbestlik derecesine sahiptir.

Bu fazlalık gereksiz değildir. Aynı uç efektör konumunu üreten birden fazla eklem yapılandırması bulunabilir. Robot böylece ana görevi bozmadan dirseğini bir engelden uzaklaştırabilir, eklem sınırlarından kaçabilir veya daha rahat bir duruş seçebilir.

Jacobian ve sıfır uzayı

Eklem hızları ile uç efektör hızı arasındaki ilişki Jacobian matrisiyle kurulur:

Redundant bir sistemde ters çözüm tek değildir. Yaygın hız çözümü şöyledir:

Burada $J^+$ Jacobian’ın sözde tersidir. İlk terim uç efektörü hedeflenen yönde hareket ettirir. İkinci terim ise Jacobian’ın sıfır uzayında kalır; başka bir deyişle uç efektör hareketini değiştirmeden eklemleri oynatır. Engel kaçınma sihrinin büyük bölümü bu ikinci terimdedir.

$z$ vektörü, robotu engelden uzaklaştıran bir maliyet fonksiyonunun negatif gradyanı olarak seçilebilir:

$H(q)$ robot ile engel arasındaki mesafe azaldıkça büyüyen bir ceza fonksiyonu olabilir. Böylece robot bir eliyle hedefe ilerlerken “dirseğini içeri çekebilir.”

Basit bir hesaplama örneği

Aşağıdaki Python kodu, ana uç efektör hızına sıfır uzayı üzerinden ikincil bir kaçınma hareketi ekler:

import numpy as np

def redundant_velocity(J, target_velocity, avoidance_gradient, gain=0.4):
    J_pinv = np.linalg.pinv(J)
    identity = np.eye(J.shape[1])

    primary = J_pinv @ target_velocity
    null_space = identity - J_pinv @ J
    secondary = null_space @ (-gain * avoidance_gradient)

    return primary + secondary

primary hedefe ulaşma görevini gerçekleştirir. secondary ise engel maliyetini azaltmaya çalışır. null_space izdüşümü sayesinde ikincil hareket, ideal matematiksel koşullarda uç efektörün istenen hızını bozmaz.

Potansiyel alan yaklaşımı

Engeller çoğu zaman itici potansiyel alanlarla modellenir. Engel ile robot noktası arasındaki mesafe $d$, etkinin başladığı güvenli mesafe $d_0$ olsun:

Robot engelden uzaktaysa ceza sıfırdır; yaklaştıkça hızla büyür. Bu yöntem sezgiseldir fakat yerel minimumlara takılabilir. Ayrıca yalnızca uç efektörü değil, dirsek ve bağlantılar üzerindeki örnek noktaları da kontrol etmek gerekir.

Sonuç olarak fazladan serbestlik derecesi, robota yalnızca daha fazla hareket değil, aynı hedefe giderken daha iyi hareket seçme özgürlüğü verir. Doğru kontrol algoritmasıyla redundant kol; engellerden kaçınabilir, eklem sınırlarını koruyabilir ve çalışma alanında çok daha güvenli davranabilir.

Operatörler: Programın hesaplama araçları

Operatörler, bir veya daha fazla değer üzerinde işlem yapan sembollerdir. Örneğin + toplama yaparken > iki değeri karşılaştırır. Bir ifadenin sonucu başka bir operatörün girdisi olabilir. Bu nedenle işlem önceliğini anlamak önemlidir.

Örneğin aşağıdaki matematiksel ifade Java’da da aynı öncelik mantığıyla değerlendirilir:

Çarpma önce çalışır. Sonucun 28 olması isteniyorsa parantez kullanılmalıdır: (10 + 4) * 2.

Mod alma operatörü %, özellikle çift-tek kontrolünde kullanışlıdır. Bir $n$ sayısı için $n \bmod 2 = 0$ ise sayı çifttir.

Karar yapıları: Yol ayrımındaki Java

if, else if ve else, koşullara göre farklı kod blokları çalıştırır. Koşulun sonucu mutlaka true veya false olmalıdır.

int puan = 78;

if (puan >= 85) {
    System.out.println("Pekiyi");
} else if (puan >= 50) {
    System.out.println("Geçti");
} else {
    System.out.println("Kaldı");
}

Bu kod, karşılaştırma operatörleriyle puanı sınıflandırır. Koşullar yukarıdan aşağıya sınanır ve ilk doğru bloğun ardından yapı sona erer. Dolayısıyla daha özel veya yüksek eşikli koşulların önce yazılması önemlidir.

Sabit seçeneklerin bulunduğu durumlarda switch daha okunaklı olabilir:

String rol = "editor";

switch (rol) {
    case "admin" -> System.out.println("Tam yetki");
    case "editor" -> System.out.println("İçerik düzenleme yetkisi");
    default -> System.out.println("Sınırlı yetki");
}

Üçlü operatörün biçimi koşul ? doğruDeğer : yanlışDeğer şeklindedir. Örneğin yas >= 18 ? "Yetişkin" : "Çocuk" ifadesi kısa bir karar üretir; ancak iç içe kullanılırsa okunabilirliği hızla düşürür.

Döngüler: Tekrarın kontrollü hâli

Döngüler, aynı işlemi belirli bir koşul sağlandığı sürece tekrarlar. for tekrar sayısı bilindiğinde, while koşul ön planda olduğunda, do-while ise bloğun en az bir kez çalışması gerektiğinde tercih edilir.

int toplam = 0;

for (int i = 1; i <= 5; i++) {
    toplam += i;
}

System.out.println(toplam); // 15

Bu döngü $1+2+3+4+5=15$ toplamını hesaplar. Başlangıç değeri, devam koşulu ve artış işlemi aynı satırda görüldüğü için akış kolayca izlenebilir.

break döngüyü tamamen sonlandırırken continue yalnızca mevcut turu atlar. Bunlar güçlü araçlardır; gereğinden fazla kullanılmaları akışı takip etmeyi zorlaştırabilir.

Kısa devre değerlendirmesi

Mantıksal && operatörü ilk koşul yanlışsa ikinci koşulu çalıştırmaz. || ise ilk koşul doğruysa devamını değerlendirmez:

if (kullanici != null && kullanici.isActive()) {
    System.out.println("Giriş başarılı");
}

Burada önce null kontrolü yapılır. Böylece var olmayan bir nesne üzerinde metot çağrılması ve NullPointerException oluşması engellenir.

Sonuç olarak operatörler veriyi dönüştürür, karar ifadeleri uygun yolu seçer ve döngüler tekrarları yönetir. Sağlam bir Java programında bu üçlü birlikte çalışır: doğru koşul kurulur, akış bilinçli biçimde yönlendirilir ve her tekrarın ne zaman biteceği açıkça tanımlanır.

``

Green Project ve Oak’ın Doğuşu

Java’nın hikâyesi 1991 yılında Sun Microsystems bünyesindeki Green Project ile başladı. James Gosling, Mike Sheridan ve Patrick Naughton gibi mühendisler, televizyon kutuları ve ev cihazları için güvenilir bir yazılım platformu geliştirmeye çalışıyordu. C ve C++ güçlüydü; ancak donanıma bağımlılık, elle bellek yönetimi ve işaretçi hataları bu cihazlar için ciddi risk oluşturuyordu.

Gosling tarafından geliştirilen dil önce, ofisinin önündeki ağaçtan esinlenilerek Oak adını aldı. Oak isminin başka bir şirket tarafından tescillenmiş olması nedeniyle dilin adı daha sonra Java olarak değiştirildi. Projenin cihaz pazarı beklenen hızda büyümese de internetin yükselişi, taşınabilir kod fikrine yeni bir sahne hazırladı. Java, 1995 yılında resmen tanıtıldı.

Java’nın temel felsefesi şu sloganla özetlendi: Write Once, Run Anywhere — bir kez yaz, her yerde çalıştır.

Kaynak Koddan Bayt Koda

Java derleyicisi, kaynak kodunu doğrudan belirli bir işlemcinin makine diline dönüştürmez. Bunun yerine JVM’nin anlayabileceği ara temsil olan bayt kodu üretir.

public class MerhabaJVM {
    public static void main(String[] args) {
        int javaYasi = 2026 - 1995;
        System.out.println("Java yaklaşık " + javaYasi + " yaşında!");
    }
}

Bu sınıf şu komutla derlenir:

javac MerhabaJVM.java
java MerhabaJVM

javac komutu kaynak dosyadan MerhabaJVM.class dosyasını üretir. Bu dosya işlemciye özel makine kodu değil, JVM komutları içerir. javap -c MerhabaJVM komutu kullanılarak bayt kod talimatları incelenebilir.

Süreci matematiksel bir dönüşüm gibi gösterebiliriz:

Aynı .class dosyasının farklı sistemlerde çalışabilmesinin koşulu, her sistem için uygun bir JVM bulunmasıdır. Dolayısıyla taşınabilir olan JVM’nin kendisi değil, JVM üzerinde çalışacak şekilde üretilen bayt koddur.

JVM Tam Olarak Ne Yapar?

Java Virtual Machine, fiziksel işlemci ile Java programı arasında soyut bir bilgisayar gibi davranır. Sınıfları yükler, bayt kodunu doğrular, belleği düzenler ve kodu çalıştırır. JVM’nin başlıca bileşenleri şunlardır:

• Class Loader: Gerekli sınıfları çalışma anında yükler.
• Bytecode Verifier: Talimatların güvenli ve kurallara uygun olduğunu denetler.
• Execution Engine: Bayt kodu yorumlar veya makine koduna dönüştürür.
• Garbage Collector: Kullanılmayan nesnelerin belleğini otomatik olarak geri kazanır.
• Runtime Data Areas: Heap, stack ve metot alanı gibi bellek bölgelerini yönetir.

İlk JVM’ler bayt kodu çoğunlukla yorumluyordu. Modern JVM’lerdeki JIT derleyici, sık çalışan kod bölümlerini çalışma sırasında yerel makine koduna çevirir. Basitleştirilmiş performans fikri şöyle ifade edilebilir:

Başlangıçta JIT maliyeti oluşsa da tekrar sayısı $n$ büyüdükçe optimize edilmiş kod önemli hız kazandırır.

Java’nın Evrimi

Java zaman içinde yalnızca bir dil olmaktan çıkıp büyük bir platforma dönüştü. Java 5 generics ve annotation özelliklerini, Java 8 lambda ifadelerini ve Stream API’yi getirdi. Java 9 modül sistemini tanıttı; sonraki sürümler record, sealed class, pattern matching ve virtual thread gibi modern yetenekler ekledi.

Bugün Java’nın gücü; olgun kütüphane ekosistemi, geriye dönük uyumluluk yaklaşımı ve JVM’nin gelişmiş optimizasyonlarında yatıyor. Üstelik Kotlin, Scala ve Clojure gibi diller de JVM üzerinde çalışabiliyor. Kısacası Oak’ın küçük cihazlar için filizlenen fikri, milyonlarca uygulamayı taşıyan oldukça büyük bir ormana dönüştü.

``

Güçlü numaralandırmalar: enum

Bir değer yalnızca belirli seçeneklerden biri olabiliyorsa String veya rastgele sayılar yerine enum kullanmak daha güvenlidir. Örneğin sipariş durumunu "HAZIRLANIYOR" şeklinde saklamak yazım hatalarına açıktır. enum ise derleyicinin kontrol edebildiği sınırlı bir değer kümesi oluşturur.

Matematiksel olarak bir enum, sonlu bir küme gibi düşünülebilir:

Java enum’ları basit sabit listelerinden daha güçlüdür. Alan, kurucu metot ve davranış taşıyabilirler:

public enum SiparisDurumu {
    BEKLIYOR("Sipariş sırada", false),
    HAZIRLANIYOR("Mutfak çalışıyor", false),
    GONDERILDI("Kurye yolda", true),
    IPTAL("Sipariş iptal edildi", true);

    private final String aciklama;
    private final boolean sonDurum;

    SiparisDurumu(String aciklama, boolean sonDurum) {
        this.aciklama = aciklama;
        this.sonDurum = sonDurum;
    }

    public String getAciklama() {
        return aciklama;
    }

    public boolean isSonDurum() {
        return sonDurum;
    }
}

Bu örnek, durumla ilgili veriyi farklı if bloklarına dağıtmak yerine doğrudan enum içinde toplar. Enum değerleri tekil nesneler olduğundan == ile güvenle karşılaştırılabilir. Dış sistemlerden gelen metinleri valueOf() ile dönüştürürken geçersiz değerlerin IllegalArgumentException üreteceği unutulmamalıdır.

Autoboxing ve unboxing

Java’nın int, double ve boolean gibi ilkel tipleri nesne değildir. Koleksiyonlar ise nesne bekler. Autoboxing, ilkel değeri karşılık gelen sarmalayıcı sınıfa otomatik dönüştürür; unboxing bunun tersidir.

List<Integer> puanlar = new ArrayList<>();
puanlar.add(90);          // int -> Integer: autoboxing
int ilkPuan = puanlar.get(0); // Integer -> int: unboxing

Derleyici zihninde yaklaşık olarak şu dönüşüm gerçekleşir:

\(int \xrightarrow{boxing} Integer\) \(Integer \xrightarrow{unboxing} int\)

Kolaylık güzel olsa da null değer unboxing sırasında NullPointerException üretir:

Integer adet = null;
// int toplam = adet + 1; // Unboxing sırasında hata oluşur

Ayrıca Integer nesnelerini == ile karşılaştırmak tehlikelidir. Java bazı küçük sayıları önbelleğe aldığı için sonuçlar şaşırtıcı olabilir. Değer karşılaştırmasında equals() kullanılmalıdır. Yoğun döngülerde gereksiz boxing işlemleri ek nesne maliyeti de oluşturabilir.

Anotasyonlar: Kodun üzerine iliştirilen metadata

Anotasyonlar doğrudan iş mantığını çalıştırmaz; derleyiciye, araçlara veya çalışma zamanı kütüphanelerine ek bilgi verir. @Override, metodun üst sınıftaki bir metodu ezdiğini doğrulatır. Spring’deki @Service veya JPA’deki @Entity ise framework davranışlarını yönlendirir.

Kendi anotasyonumuzu da oluşturabiliriz:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface YetkiGerekli {
    String rol();
}

Buradaki @Retention, bilginin çalışma zamanına kadar korunacağını; @Target ise yalnızca metotlarda kullanılabileceğini belirtir. Ardından @YetkiGerekli(rol = "ADMIN") biçiminde işaretlenen metotlar reflection ile bulunabilir ve çağrıdan önce yetki kontrolü yapılabilir.

Özetle enum değer alanını sınırlar, autoboxing ilkel ve nesne dünyalarını yakınlaştırır, anotasyonlar ise kod hakkında kod dışı bilgi taşır. Üçü birlikte kullanıldığında Java uygulamaları daha açıklayıcı, denetlenebilir ve framework dostu olur.

PATH tam olarak nedir?

PATH, çalıştırılabilir dosyaların aranacağı dizinleri tutan bir listedir. Linux ve macOS sistemlerinde dizinler : karakteriyle ayrılır:

printf '%s\n' "$PATH"

Örnek bir çıktı şöyle olabilir:

/home/ada/bin:/usr/local/bin:/usr/bin:/bin

Kabuk, ornek komutu girildiğinde önce /home/ada/bin/ornek, sonra /usr/local/bin/ornek ve devamında diğer olasılıkları kontrol eder. İlk uygun dosya bulunduğunda arama sona erer.

Bunu matematiksel olarak $PATH = (d_1, d_2, \ldots, d_n)$ biçiminde sıralı bir dizi kabul ederek düşünebiliriz. Çalıştırılan dosyanın indeksi:

Buradaki min, neden sıranın kritik olduğunu anlatır: İlk eşleşme kazanır; sonraki dosyalar daha yeni veya daha doğru olsa bile dikkate alınmaz.

\vert PATH sırası \vert Seçilen komut \vert Olası sonuç \vert \vert —\vert —\vert —\vert \vert /usr/local/bin:/usr/bin \vert /usr/local/bin/python \vert Elle kurulan sürüm çalışabilir \vert \vert /usr/bin:/usr/local/bin \vert /usr/bin/python \vert Sistem sürümü çalışabilir \vert \vert ./bin:/usr/bin \vert Projedeki komut \vert Projeye özel araç öne geçer \vert

Hangi dosyanın çalıştığını bulmak

Bir komutun çözümlendiği ilk yolu görmek için command -v kullanılabilir:

command -v python
command -v git

Aynı ada sahip bütün adayları görmek için Bash ve Zsh üzerinde type -a oldukça kullanışlıdır:

type -a python

Örneğin çıktı hem /home/ada/bin/python hem de /usr/bin/python gösteriyorsa terminal yalnızca ilkini çalıştırır. Belirli dosyayı kesin olarak kullanmak istediğinizde tam yol vermek arama mekanizmasını devre dışı bırakır:

/usr/bin/python --version

\vert Yöntem \vert PATH araması yapar mı? \vert Kullanım amacı \vert \vert —\vert —:\vert —\vert \vert python \vert Evet \vert Normal komut çağrısı \vert \vert /usr/bin/python \vert Hayır \vert Kesin dosyayı çalıştırma \vert \vert command -v python \vert Arama sonucunu gösterir \vert Tanılama \vert \vert type -a python \vert Tüm eşleşmeleri gösterir \vert Çakışma inceleme \vert

Sırayı bilinçli olarak değiştirmek

Kullanıcıya özel araçları öne almak için dizin listenin başına eklenebilir:

export PATH="$HOME/bin:$PATH"

Bu komut mevcut PATH değerini korur, fakat $HOME/bin dizinine öncelik verir. Değişikliğin kalıcı olması için satır genellikle ~/.bashrc, ~/.zshrc veya kullanılan kabuğun ilgili yapılandırma dosyasına eklenir. Sona eklemek ise sistem araçlarına öncelik tanır:

export PATH="$PATH:$HOME/bin"

Bazı kabuklar daha önce buldukları yolları önbelleğe alabilir. Bir dosyayı taşıdıktan sonra hâlâ eski komut çalışıyorsa Bash üzerinde önbelleği temizlemek mümkündür:

hash -r

Güvenlik tarafı: Noktaya dikkat

Geçerli dizini temsil eden . değerini PATH’in başına koymak risklidir:

export PATH=".:$PATH"

İçinde zararlı bir ls dosyası bulunan klasöre girildiğinde gerçek /bin/ls yerine bu dosya çalışabilir. Bu nedenle . mümkünse PATH’e hiç eklenmemeli; gerekiyorsa yerel program açıkça ./program şeklinde çağrılmalıdır.

Özetle PATH yalnızca bir dizin listesi değil, bir öncelik sistemidir. Beklenmeyen sürüm çalıştığında önce command -v, ardından type -a kullanın; sırayı inceleyin ve gerekirse tam dosya yoluyla doğrulama yapın. Terminal gizemli davranmıyordur—yalnızca listeyi soldan sağa okumaktadır.

Python sözlükleri bugün anahtarları eklenme sırasına göre dolaştığı için oldukça öngörülebilir davranıyor. Ancak eski bir Python sürümünde çalışan projeyi ayağa kaldırdığınızda aynı kodun farklı sırada çıktı üretmesi mümkündür. Bu durum yalnızca estetik bir farklılık değildir; testleri, dosya üretimini, API yanıtlarını ve hatta uygulama mantığını bozabilen sinsi bir uyumluluk problemidir. ``

“Sırasız” tam olarak ne demekti?

Bir dict, anahtarları değerlere bağlayan hash tablosu tabanlı bir veri yapısıdır. Bir anahtarın yerleşimi kabaca şu ilişkiyle düşünülebilir:

Buradaki $N$, tablonun kapasitesini temsil eder. Python 3.7 öncesinde sözlüğün dolaşım sırası, anahtarların eklenme zamanından ziyade hash değerleri, tablonun boyutu ve yeniden boyutlandırma işlemleri gibi ayrıntılardan etkilenebilirdi.

“Sırasız” ifadesi, öğelerin her erişimde mutlaka rastgele dizildiği anlamına gelmez. Asıl anlamı, programcının gözlemlediği sıranın dil tarafından garanti edilmemesidir. Aynı makinede kararlı görünen bir çıktı, başka Python sürümünde veya farklı bir süreçte değişebilirdi. Hash randomization özelliği de özellikle metin anahtarlarında süreçler arasında farklılık oluşturabilir.

CPython 3.6’da sıralı davranış, daha kompakt sözlük uygulamasının bir sonucu olarak ortaya çıktı. Python 3.7 ile bu davranış resmi dil özelliği hâline geldi.

Eski kod nasıl bozulur?

Aşağıdaki kod modern Python’da host, port, debug sırasını korur:

config = {}
config["host"] = "localhost"
config["port"] = 8000
config["debug"] = True

line = ";".join(f"{key}={value}" for key, value in config.items())
print(line)

Kod, yapılandırmayı tek satırlık bir metne dönüştürür. Python 3.7 ve sonrasında sonuç öngörülebilirken eski sürümlerde alanlar farklı sırada gelebilir. Bu metin bir snapshot testiyle karşılaştırılıyorsa test başarısız olur. Daha kötüsü, sıralamaya duyarlı eski bir tüketici varsa veri yanlış yorumlanabilir.

Benzer riskler şuralarda görülür:

• JSON veya CSV benzeri çıktıların metinsel olarak karşılaştırılması,
• HTML şablonlarında alanların beklenen sırada gösterilmesi,
• Komut satırı argümanlarının sözlükten üretilmesi,
• Sözlük anahtarlarının indeks gibi kullanılması,
• Snapshot ve golden file testleri.

Teorik olarak bir eşlemenin doğruluğu sıra üzerinden değil, anahtar-değer çiftleri üzerinden tanımlanmalıdır:

Yani iki sözlük aynı çiftlere sahipse dolaşım sıraları farklı olsa bile eşit kabul edilir.

Güvenli uyumluluk yöntemleri

Sıra iş mantığının parçasıysa eski sürümlerde OrderedDict kullanılmalıdır:

from collections import OrderedDict

config = OrderedDict([
    ("host", "localhost"),
    ("port", 8000),
    ("debug", True),
])

for key, value in config.items():
    print(key, value)

Amaç yalnızca deterministik çıktıysa anahtarları açıkça sıralamak daha net olabilir:

for key in sorted(config):
    print(f"{key}={config[key]}")

Sonuç olarak modern dict davranışını geçmişe doğru varsaymak tehlikelidir. Legacy kod incelerken items(), keys() ve sözlük üzerinde doğrudan dönen her döngüye dikkat etmek gerekir. Sıra önemliyse bunu açıkça ifade etmek, Python’un tarihsel davranışlarına güvenmekten çok daha sağlamdır.