İstisna nedir?

İstisna, program çalışırken normal akışı bozan olağan dışı bir durumu temsil eden nesnedir. C# içerisindeki bütün istisnalar doğrudan veya dolaylı olarak System.Exception sınıfından türetilir.

Bir işlemin başarısız olma olasılığını $P(E)$, hatanın sisteme vereceği zararı da $C(E)$ ile gösterirsek basitleştirilmiş risk hesabı şöyle yazılabilir:

İstisna yönetimi hatanın oluşma ihtimalini her zaman azaltmaz; fakat $C(E)$ değerini düşürerek hatanın uygulamanın tamamına yayılmasını engeller.

try-catch-finally mimarisi

Aşağıdaki örnek bir dosyayı okumayı dener, olası hataları türlerine göre izole eder ve işlem sonunda bilgi verir:

try
{
    string metin = File.ReadAllText("ayarlar.json");
    Console.WriteLine(metin);
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"Dosya bulunamadı: {ex.FileName}");
}
catch (UnauthorizedAccessException)
{
    Console.WriteLine("Dosyaya erişim yetkiniz yok.");
}
catch (IOException ex)
{
    Console.WriteLine($"Girdi/çıktı hatası: {ex.Message}");
}
finally
{
    Console.WriteLine("Dosya okuma denemesi tamamlandı.");
}

catch blokları özelden genele doğru sıralanmalıdır. Önce Exception yakalanırsa daha özel bloklara sıra gelmez. Ayrıca her yerde genel Exception yakalayıp hatayı sessizce yutmak, yangın alarmının pilini çıkarmaya benzer: ortam sessizleşir ama yangın devam eder.

Bir istisnayı aynı çağrı yığını bilgisiyle yeniden göndermek için throw; kullanılmalıdır. throw ex; ifadesi yığın izini değiştirerek hatanın gerçek kaynağını bulmayı zorlaştırabilir.

Özel hata sınıfları

İş kuralları için hazır istisnalar her zaman yeterince açıklayıcı değildir. Örneğin stok miktarının yetersiz olması teknik değil, alan odaklı bir problemdir:

public class YetersizStokException : Exception
{
    public int MevcutStok { get; }

    public YetersizStokException(string mesaj, int mevcutStok)
        : base(mesaj)
    {
        MevcutStok = mevcutStok;
    }
}

public static void SiparisVer(int istenen, int stok)
{
    if (istenen > stok)
    {
        throw new YetersizStokException(
            "İstenen miktar stoktan fazla.", stok);
    }
}

Bu sınıf, hataya yalnızca mesaj değil, MevcutStok gibi yapılandırılmış bağlam da ekler. Üst katman böylece kullanıcıya uygun bildirim gösterebilir veya işlemi başka bir depoya yönlendirebilir.

Sağlam kullanım ilkeleri

• İstisnaları yalnızca gerçekten olağan dışı durumlarda kullanın; normal kontrol akışını throw ile kurmayın.
• ArgumentException, InvalidOperationException ve FileNotFoundException gibi uygun hazır türleri tercih edin.
• Hataları bağlam bilgisiyle loglayın; parola ve erişim anahtarı gibi hassas verileri kaydetmeyin.
• IDisposable kaynaklarında mümkünse using kullanın; derleyici gerekli temizliği güvenli biçimde oluşturur.
• Kullanıcıya sade mesaj, geliştiriciye ise ayrıntılı log sağlayın.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları sınırlar, görünür kılar ve uygulamanın güvenli biçimde toparlanmasına yardımcı olur. Kısacası try-catch-finally, kodun emniyet kemeridir: kazayı engellemeyebilir ama sonucunu ciddi ölçüde kontrol eder.

C++ ile nesne yönelimli programlama yaparken kurucu içinde sanal bir fonksiyon çağırmak ilk bakışta gayet mantıklı görünebilir. Sonuçta fonksiyon virtual olarak tanımlanmıştır; nesne türetilmiş sınıfa aitse onun sürümü çalışmalıdır, değil mi? Ne yazık ki C++ burada bilinçli biçimde farklı davranır. Kurucu çalışırken sanal çağrı, o anda kurulmakta olan sınıfın uygulamasına bağlanır; henüz hazır olmayan türetilmiş sınıfa gönderilmez. ``

Temel örnek

Aşağıdaki kod, sık karşılaşılan beklenti ile gerçek davranış arasındaki farkı gösterir:

#include <iostream>

class Base {
public:
    Base() {
        std::cout << "Base kuruluyor\n";
        initialize();
    }

    virtual void initialize() {
        std::cout << "Base::initialize\n";
    }

    virtual ~Base() = default;
};

class Derived : public Base {
public:
    Derived() : value(42) {
        std::cout << "Derived kuruluyor\n";
    }

    void initialize() override {
        std::cout << "Derived::initialize, value = "
                  << value << '\n';
    }

private:
    int value;
};

int main() {
    Derived object;
}

Programın önemli çıktısı şöyledir:

Base kuruluyor
Base::initialize
Derived kuruluyor

object, Derived türünde olmasına rağmen Base kurucusundaki çağrı Derived::initialize() fonksiyonuna gitmez. Bu bir derleyici hatası veya polimorfizm arızası değil, nesnenin yaşam döngüsünü koruyan dil kuralıdır.

Nesne hangi sırayla oluşur?

Bir Derived nesnesinin kurulumu basitleştirilmiş biçimde şu sırayı izler:

1. Bellek ayrılır.
2. Base alt nesnesi kurulur.
3. Derived üyeleri başlatılır.
4. Derived kurucusunun gövdesi çalışır.
5. Nesne tam bir Derived olarak kullanılabilir.

Kurulum ilerlemesini yaklaşık olarak $P = c / n$ ile düşünebiliriz. Burada $c$ tamamlanan aşama, $n$ toplam aşama sayısıdır. Base kurucusu çalışırken $P < 1$ olduğundan, türetilmiş bölüm henüz geçerli durumuna ulaşmamıştır.

Eğer çağrı Derived::initialize() fonksiyonuna yönlendirilseydi, bu fonksiyon henüz başlatılmamış value üyesini okuyabilirdi. Böyle bir erişim tanımsız veya anlamsal açıdan bozuk davranışlara kapı açardı. C++ bu nedenle kurulum sırasında nesnenin dinamik türünü geçici olarak kurulmakta olan sınıfla sınırlar.

Aynı kural yıkıcılar için de geçerlidir. Yıkım ters sırada gerçekleştiği için temel sınıf yıkıcısı çalışırken türetilmiş bölüm artık yaşamını tamamlamıştır.

Daha güvenli tasarım: iki aşamalı başlatma

Polimorfik davranış gerekiyorsa sanal fonksiyonu nesne tamamen kurulduktan sonra çağırabilirsiniz:

class Base {
public:
    virtual void initialize() = 0;
    virtual ~Base() = default;
};

class Derived : public Base {
public:
    void initialize() override {
        // Tüm üyeler artık güvenle kullanılabilir.
    }
};

int main() {
    Derived object;
    object.initialize();
}

Daha kontrollü bir seçenek fabrika fonksiyonudur. Fabrika önce nesneyi oluşturur, ardından sanal başlatmayı gerçekleştirir:

#include <memory>

std::unique_ptr<Base> createDerived() {
    auto object = std::make_unique<Derived>();
    object->initialize();
    return object;
}

Özetle, kurucu içindeki sanal çağrı polimorfizmi tamamen kapatmaz; çağrıyı nesnenin güvenli biçimde kurulmuş bölümüne sınırlar. Gerçek dinamik gönderim gerekiyorsa işlemi kurulum sonrasına taşımak veya fabrika deseni kullanmak en temiz çözümdür.

``

Bağlama tam olarak nedir?

Bağlama, bir çağrı ifadesinin çalıştırılacak fonksiyon gövdesiyle eşleştirilmesidir. Statik bağlamada karar, değişkenin derleme zamanındaki türüne göre verilir. Dinamik bağlamada ise virtual mekanizması üzerinden nesnenin çalışma zamanındaki gerçek türü kullanılır.

Bunu kabaca şöyle düşünebiliriz:

Fonksiyon sanal değilse çoğunlukla $T_{statik}$ belirleyicidir. Sanal fonksiyon çağrısında ise uygun koşullarda $T_{dinamik}$ devreye girer.

Hata 1: Sanal olmayan yıkıcı

Polimorfik bir taban sınıfın yıkıcısını sanal yapmamak, en tehlikeli karışıklıklardan biridir:

#include <iostream>

class Kaynak {
public:
    ~Kaynak() { std::cout << "Kaynak kapandı\n"; }
};

class Dosya : public Kaynak {
public:
    ~Dosya() { std::cout << "Dosya kapandı\n"; }
};

int main() {
    Kaynak* kaynak = new Dosya;
    delete kaynak; // Tanımsız davranış!
}

delete işlemi taban işaretçisi üzerinden yapıldığı için yıkıcının dinamik davranması gerekir. Çözüm basittir:

virtual ~Kaynak() = default;

Bir sınıfta sanal metot varsa yıkıcının da genellikle sanal olması beklenir.

Hata 2: Varsayılan argümanların sanal olduğunu sanmak

Sanal fonksiyonun gövdesi dinamik, varsayılan argümanı ise statik olarak seçilir:

#include <iostream>

struct Bildirim {
    virtual void gonder(int oncelik = 1) {
        std::cout << oncelik << '\n';
    }
};

struct Alarm : Bildirim {
    void gonder(int oncelik = 9) override {
        std::cout << oncelik << '\n';
    }
};

int main() {
    Alarm alarm;
    Bildirim& b = alarm;
    b.gonder(); // Alarm::gonder çalışır, fakat argüman 1 olur.
}

Ortaya hibrit bir sonuç çıkar: gövde alt sınıftan, değer taban sınıftan gelir. Varsayılan değeri tek yerde tanımlamak veya parametresiz ayrı bir sanal olmayan arayüz kullanmak daha güvenlidir.

Hata 3: Kurucuda sanal çağrı

Kurucu sırasında nesnenin alt sınıf bölümü henüz hazır değildir. Bu nedenle taban kurucusundan yapılan sanal çağrı, alt sınıf sürümüne gitmez:

struct Motor {
    Motor() { baslat(); }
    virtual void baslat() { /* taban davranışı */ }
};

struct TurboMotor : Motor {
    void baslat() override { /* turbo henüz hazır olmayabilir */ }
};

Nesneyi oluşturduktan sonra çağrılan bir initialize() metodu veya fabrika fonksiyonu kullanmak daha açık bir yaşam döngüsü sağlar.

Hata 4: Nesne dilimleme

Alt sınıf nesnesini değer olarak taban türe kopyalamak dinamik tür bilgisini keser:

void calistir(Motor motor) { // Kopyalama ve dilimleme
    motor.baslat();
}

Bunun yerine Motor&, Motor* veya uygun bir akıllı işaretçi kullanılmalıdır.

Sağlam tasarım kontrol listesi

• Ezilen her metoda override ekleyin.
• Polimorfik tabanlarda sanal yıkıcı kullanın.
• Sanal metotlarda farklı varsayılan argümanlardan kaçının.
• Kurucu ve yıkıcılarda sanal dispatch’e güvenmeyin.
• Polimorfik nesneleri değer yerine referans veya işaretçiyle taşıyın.
• Overload ile override kavramlarını aynı şey sanmayın.

Kısacası virtual, tasarıma sihir serpiştiren bir kelime değildir. Hangi kararın derleyiciye, hangisinin çalışma zamanına bırakıldığını açıkça belirlemek gerekir; aksi hâlde kod derlenir, çalışır ve tam en kötü anda yanlış şeyi yapar.

``

Temel fark: dosya sistemi ve dosyalar

df, adını “disk free” ifadesinden alır. Bağlı dosya sistemlerinin toplam, kullanılmış ve boş blok sayılarını çekirdek üzerinden sorgular:

df -h

Buradaki -h, değerleri GiB ve MiB gibi okunabilir birimlerle gösterir. Basitleştirilmiş biçimde df hesabı şöyledir:

du ise “disk usage” anlamına gelir ve belirtilen yoldaki dosya ağacını dolaşır. Bulabildiği dosyaların kapladığı blokları toplar:

du -sh /var

-s yalnızca toplam sonucu, -h ise okunabilir birimleri verir. Yaklaşık hesap şu şekilde düşünülebilir:

Dolayısıyla df bütün dosya sistemini, du ise seçilen dizin ağacında erişebildiği girdileri raporlar.

En yaygın fark: silinmiş ama açık dosyalar

Bir uygulama büyük bir log dosyasını açık tutarken dosya rm ile silinirse dizin girdisi kaldırılır. Ancak süreç dosya tanımlayıcısını kapatıncaya kadar veri blokları serbest bırakılmaz. Bu durumda du dosyayı bulamaz, fakat df blokları hâlâ kullanımda görür.

Bu hayalet dosyaları bulmak için:

sudo lsof +L1

Çıktıda büyük bir dosya görürseniz ilgili servisi kontrollü biçimde yeniden başlatmak genellikle alanı serbest bırakır:

sudo systemctl restart uygulama-servisi

Üretim ortamında süreci doğrudan öldürmek yerine önce servis etkisini ve log yapılandırmasını incelemek daha güvenlidir.

Diğer ayrışma nedenleri

Dosya sistemleri, normal kullanıcıların diski tamamen doldurmasını engellemek için ayrılmış bloklara sahip olabilir. Örneğin ext4 üzerinde yüzde 5 rezerv varsa normal kullanıcı boş alan göremezken root bu alanı kullanabilir. df çıktısındaki “available” değeri bu nedenle basit boş blok sayısından farklı olabilir.

Sparse, yani seyrek dosyalar da ayrı bir tuzaktır. Dosyanın mantıksal boyutu 10 GB olduğu hâlde diskte yalnızca birkaç MB blok ayrılmış olabilir:

truncate -s 10G seyrek.img
ls -lh seyrek.img
du -h seyrek.img
du --apparent-size -h seyrek.img

ls ve du --apparent-size mantıksal boyutu, standart du ise gerçekten ayrılmış alanı gösterir.

Ayrıca du / komutu /mnt veya /proc gibi alt bağlama noktalarına geçebilir. Yalnızca kök dosya sistemini incelemek için -x kullanmak daha doğru bir karşılaştırma sağlar:

sudo du -xsh /
df -h /

Pratik teşhis sırası

Önce df -hT ile dolu dosya sistemini ve türünü belirleyin. Ardından aynı bağlama noktasında du -x kullanın. Sonuçlar ciddi ölçüde farklıysa lsof +L1 ile silinmiş açık dosyaları, df -i ile inode tükenmesini ve bağlama noktalarını kontrol edin.

Kısacası df diskin muhasebecisi, du ise klasörleri tek tek gezen envanter görevlisidir. Raporların farklı çıkması çoğu zaman hata değil, iki aracın farklı sorulara cevap vermesidir.

Yürüme döngüsü neden periyodiktir?

Bir gait cycle, aynı ayağın iki benzer teması arasındaki hareket dizisidir. Döngü genellikle tek destek, çift destek, salınım ve temas geçişi evrelerine ayrılır. Eklem açıları tam olarak tekrarlanmasa bile sistem durumunun benzer bir yörüngeyi izlemesi beklenir.

Robotun durumu şu vektörle gösterilebilir:

Burada $\mathbf{q}$ eklem konumlarını, $\dot{\mathbf{q}}$ ise hızları temsil eder. Kararlı yürüyüşte durum uzayındaki hareket, limit döngü adı verilen kapalı bir yörünge oluşturur. Robot küçük bir itme aldığında yörüngeden uzaklaşabilir; önemli olan birebir aynı noktaya değil, tekrar bu döngüye yaklaşmasıdır. Buna yörüngesel kararlılık denir.

Zaman değil, faz neden önemlidir?

Sadece saate bakarak “robot adımın yüzde 40’ında” demek yanıltıcı olabilir. Yokuş, zemin esnekliği veya dışarıdan gelen bir itme adım süresini değiştirir. Faz değişkeni ise hareketin fiziksel ilerleyişini takip eder:

Örneğin kalça açısı ve açısal hızı birlikte kullanılarak faz düzleminde bir yörünge çizilebilir. Böylece kontrolcü, kronometreden bağımsız biçimde ayağın salınımın başında mı yoksa yere temas etmek üzere mi olduğunu anlayabilir.

Kararlılık nasıl ölçülür?

Yürümenin belirli bir olayında, örneğin sağ topuk temasında, sistem durumu örneklenebilir. Bu kesite Poincaré kesiti denir. Ardışık adımlar arasındaki ilişki

şeklinde yazılır. Sabit yürüyüş için $\mathbf{x}^=P(\mathbf{x}^)$ olmalıdır. Haritanın sabit nokta çevresindeki özdeğerleri, yani Floquet çarpanları, kritik bilgiyi verir. Baskın çarpanın mutlak değeri $\vert \lambda_{max}\vert <1$ ise sapmalar küçülür; $\vert \lambda_{max}\vert >1$ ise robot birkaç adım sonra dramatik bir “yerçekimiyle tanışma” yaşayabilir.

Basit bir faz portresi

Aşağıdaki Python kodu, idealize edilmiş bir eklem hareketinin açı-hız faz portresini üretir. Kapalı eğri, periyodik davranışın görsel imzasıdır:

import numpy as np
import matplotlib.pyplot as plt

# Bir adımlık örnek kalça açısı
phase = np.linspace(0, 2 * np.pi, 500)
angle = 0.35 * np.sin(phase)
angular_velocity = 0.35 * np.cos(phase)

plt.plot(angle, angular_velocity)
plt.xlabel("Eklem açısı (rad)")
plt.ylabel("Açısal hız (rad/s)")
plt.title("Kalça Eklemi Faz Portresi")
plt.grid(True)
plt.axis("equal")
plt.show()

Gerçek robotta eğrinin kalınlaşması sensör gürültüsünü, giderek genişlemesi kararsızlığı, bozucu sonrası yeniden daralması ise toparlanmayı gösterebilir. Bu analiz; ZMP, basınç merkezi ve gövde kütle merkezi ölçümleriyle birleştirildiğinde daha anlamlı hâle gelir.

Kontrolcüye sağladığı avantaj

Faz analizi sayesinde kontrol sistemi ayağın yere temas zamanını ayarlayabilir, adım uzunluğunu değiştirebilir ve gövde momentumunu dengeleyebilir. Ayrıca farklı hızlardaki yürüyüşler tek bir faz koordinatında karşılaştırılabilir. Kısacası faz, robotun yalnızca ne yaptığını değil, hareketin hangi bölümünde ve ne kadar kararlı biçimde yaptığını söyler. Dengeli bir humanoid için doğru adım kadar, doğru anda atılan adım da belirleyicidir.

İki bacak üzerinde yürümek insanlar için sıradan, robotlar için ise sürekli çözülmesi gereken bir denge problemidir. Robotun kütle merkezi destek alanının dışına çıktığında yer çekimi hemen devreye girer ve pahalı metal kahramanımız yere doğru dramatik bir yolculuğa başlar. Ters sarkaç modeli, bu karmaşık gövde ve eklem sistemini daha anlaşılır bir fizik problemine dönüştürerek denge denetleyicilerinin tasarlanmasını kolaylaştırır.

``

Robot neden ters sarkaç olarak modellenir?

Klasik sarkaçta kütle aşağıdadır ve sistem doğal olarak kararlı durumuna dönmek ister. Ters sarkaçta ise kütle dönme noktasının üzerindedir. Küçük bir eğim bile kütlenin daha fazla uzaklaşmasına yol açar. İki bacaklı robot da ayakları üzerinde dururken benzer biçimde doğal olarak kararsızdır.

Basitleştirilmiş modelde robotun toplam kütlesi, kütle merkezinde bulunan noktasal bir $m$ kütlesi olarak kabul edilir. Bacak ise uzunluğu $l$ olan, kütlesiz bir çubuk gibi düşünülür. Robotun dikey eksene göre açısı $\theta$ ise temel dinamik yaklaşık olarak şöyledir:

Burada $g$ yer çekimi ivmesini, $\tau$ ise ayak bileği veya eş değer eklem torkunu gösterir. Denge çevresindeki küçük açılarda $\sin(\theta)\approx\theta$ kabulü yapılabilir:

$\theta$ katsayısının pozitif olması kritik ayrıntıdır: kontrol uygulanmazsa eğim kendiliğinden büyür.

Basitleştirme seçenekleri

Özellikle Doğrusal Ters Sarkaç Modeli (LIPM), kütle merkezinin yatay hareketini incelemek için kullanılır. Sabit $z_c$ yüksekliğinde yatay dinamik:

şeklindedir. Buradaki $x$ kütle merkezinin yatay konumu, $p$ ise basınç merkezi veya ideal koşullarda Zero Moment Point (ZMP) konumudur. Dengeyi korumak için $p$ değerinin ayağın oluşturduğu destek çokgeni içinde kalması gerekir.

Denetleyici nasıl müdahale eder?

Robot; IMU, eklem enkoderleri ve ayak tabanı kuvvet sensörlerinden veri toplar. Bu ölçümlerle açı, açısal hız ve kütle merkezi durumu tahmin edilir. Ardından PID, durum geri besleme veya LQR gibi bir denetleyici düzeltici tork üretir.

Durum vektörü $X=[\theta,\dot{\theta}]^T$ seçildiğinde LQR yaklaşımı

kontrol yasasını kullanır. $K$ kazancı, açı hatası ile enerji tüketimi arasında sistematik bir denge kurar. Aşağıdaki Python örneği, basitleştirilmiş bir geri besleme döngüsünü simüle eder:

import numpy as np

m, l, g = 20.0, 0.8, 9.81
dt = 0.002
K = np.array([450.0, 90.0])
state = np.array([0.12, 0.0])  # açı ve açısal hız

for _ in range(3000):
    theta, omega = state
    torque = -K @ state
    acceleration = (g / l) * theta + torque / (m * l**2)

    omega += acceleration * dt
    theta += omega * dt
    state = np.array([theta, omega])

print(f"Son açı: {np.degrees(state[0]):.4f} derece")

Kod, robot öne eğildiğinde ters yönde tork uygulayarak açıyı sıfıra yaklaştırır. Gerçek robotta tork sınırları, sensör gürültüsü, gecikme ve ayağın kayması da modele eklenmelidir.

Ayakta durmaktan yürümeye

Yürüme sırasında destek noktası sürekli değişir. Denetleyici yalnızca mevcut düşüşü engellemez; bir sonraki ayağın nereye basacağını da planlar. Küçük bozucular ayak bileği torkuyla, daha büyük bozucular kalça hareketiyle, çok güçlü itmeler ise yeni bir adımla karşılanır. Böylece ters sarkaç modeli, kusursuz bir robot kopyası olmaktan ziyade, karmaşık denge problemini gerçek zamanlı çözülebilen kullanışlı bir haritaya dönüştürür.

MRO tam olarak nedir?

MRO, bir özellik veya metot aranırken sınıfların hangi sırayla ziyaret edileceğini belirtir. Python 3 bu sırayı oluşturmak için C3 doğrusallaştırma algoritmasını kullanır. Amaç; çocuk sınıfları ebeveynlerden önce tutmak, sınıf bildirimindeki soldan sağa önceliği korumak ve kalıtım ağında tutarlı bir sıra üretmektir.

Bir C sınıfı, B1, B2, ..., Bn sınıflarından türetiliyorsa sıralama kabaca şöyle ifade edilir:

Buradaki merge, başka listelerin kuyruklarında bulunmayan uygun bir baş elemanı seçer. Bu kural, bir sınıfın kendi alt sınıfından önce aranmasını engeller.

Beklenmedik davranış örneği

Aşağıdaki örnekte iki ara sınıf aynı metodu değiştirir:

class Temel:
    def mesaj(self):
        return "Temel"

class A(Temel):
    def mesaj(self):
        return "A -> " + super().mesaj()

class B(Temel):
    def mesaj(self):
        return "B -> " + super().mesaj()

class C(A, B):
    pass

nesne = C()
print(nesne.mesaj())
print(C.mro())

Çıktı şu yapıdadır:

A -> B -> Temel
[C, A, B, Temel, object]

Şaşırtıcı nokta, A içindeki super() çağrısının doğrudan Temel sınıfına gitmemesidir. super(), “ebeveynimi çağır” anlamına gelmez; mevcut MRO’da benden sonraki sınıfa geç demektir. Dolayısıyla C(A, B) için A sonrasında B çalışır.

Ebeveynlerin sırasını değiştirirsek sonuç da değişir:

class D(B, A):
    pass

print(D().mesaj())
# B -> A -> Temel

Yalnızca sınıf bildirimindeki sıra değişmesine rağmen davranış tersine dönmüştür. Özellikle mixin kullanılan büyük projelerde bu durum sessiz ve zor bulunan hatalar doğurabilir.

super() zinciri nasıl güvenli kurulur?

İşbirlikçi çoklu kalıtımda zincire katılan bütün sınıflar uyumlu davranmalıdır. Her sınıf super() çağırmalı, metot imzaları birbiriyle çelişmemeli ve zincir doğrudan sınıf adıyla kesilmemelidir.

class KayitMixin:
    def kaydet(self, **kwargs):
        print("Kayıt günlüğü oluşturuldu")
        return super().kaydet(**kwargs)

class DogrulamaMixin:
    def kaydet(self, **kwargs):
        if not kwargs.get("ad"):
            raise ValueError("ad gerekli")
        return super().kaydet(**kwargs)

class Depo:
    def kaydet(self, **kwargs):
        return f"Kaydedildi: {kwargs['ad']}"

class Servis(KayitMixin, DogrulamaMixin, Depo):
    pass

Bu tasarımda her katman yalnızca kendi görevini yapar ve kontrolü sıradaki sınıfa bırakır. Servis.mro() çağrısı, gerçek yürütme yolunu incelemenin en pratik yöntemidir.

Akılda tutulması gerekenler

MRO’yu bir soy ağacından çok, Python’ın önceden hazırladığı bir ziyaret listesi gibi düşünün. super() bu listede tek adım ilerler. Beklenmedik bir sonuçla karşılaştığınızda Sinif.__mro__ veya Sinif.mro() çıktısını kontrol edin; ebeveyn sırasını bilinçli belirleyin ve doğrudan A.metot(self) çağrılarından kaçının. Çoklu kalıtım güçlüdür, fakat MRO okunmadan kullanıldığında kod tabanına küçük bir labirent yerleştirebilir.

Dekoratör aslında ne yapar?

Bir dekoratör, bir fonksiyonu parametre olarak alır ve yerine genellikle başka bir fonksiyon döndürür. Matematiksel olarak dekoratör dönüşümünü şöyle düşünebiliriz:

Burada $f$ orijinal fonksiyon, $D$ dekoratör ve $g$ çağrıların yönlendirildiği yeni fonksiyondur. Python’daki @dekorator sözdizimi ise temelde şu eşitliğin kısa yazımıdır:

Basit bir zamanlama dekoratörü yazalım:

import time

def zaman_olc(func):
    def wrapper(*args, **kwargs):
        baslangic = time.perf_counter()
        sonuc = func(*args, **kwargs)
        sure = time.perf_counter() - baslangic
        print(f"Çalışma süresi: {sure:.6f} saniye")
        return sonuc

    return wrapper

@zaman_olc
def topla(a, b):
    """İki sayıyı toplar."""
    return a + b

wrapper, farklı imzalara sahip fonksiyonlarla çalışabilmek için *args ve **kwargs kullanır. Önce zamanı kaydeder, orijinal fonksiyonu çalıştırır ve geçen süreyi ekrana yazar.

Metadata neden kaybolur?

Dekoratör uygulandıktan sonra topla değişkeni artık orijinal fonksiyonu değil, döndürülen wrapper fonksiyonunu gösterir. Bu nedenle aşağıdaki sonuçlar şaşırtıcı olabilir:

print(topla.__name__)  # wrapper
print(topla.__doc__)   # None

Python açısından ortada gizem yoktur: Yeni nesnenin metadata’sı okunmaktadır. Sorun özellikle dokümantasyon araçlarında, hata ayıklamada, testlerde ve fonksiyon adını kullanan framework’lerde belirginleşir.

functools.wraps kurtarmaya geliyor

Çözüm, iç fonksiyonun üzerine @wraps(func) eklemektir:

import time
from functools import wraps

def zaman_olc(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        baslangic = time.perf_counter()
        sonuc = func(*args, **kwargs)
        sure = time.perf_counter() - baslangic
        print(f"Çalışma süresi: {sure:.6f} saniye")
        return sonuc

    return wrapper

@zaman_olc
def topla(a, b):
    """İki sayıyı toplar."""
    return a + b

print(topla.__name__)  # topla
print(topla.__doc__)   # İki sayıyı toplar.

wraps, kendi başına sihirli bir kopyalama motoru değildir; functools.update_wrapper fonksiyonunun dekoratör biçiminde kullanılmasını sağlar. Varsayılan olarak __module__, __name__, __qualname__, __doc__, __annotations__ ve __type_params__ gibi nitelikleri wrapper’a aktarır. Ayrıca wrapper’ın sözlüğünü günceller.

Bonus: __wrapped__ ve introspection

wraps, wrapper’a __wrapped__ niteliğini de ekler. Böylece orijinal fonksiyona doğrudan ulaşılabilir:

print(topla.__wrapped__(3, 4))  # 7; zaman ölçümü yapılmaz

inspect.signature gibi introspection araçları da bu zinciri takip ederek anlamlı sonuçlar üretir:

from inspect import signature

print(signature(topla))  # (a, b)

Bu özellik yalnızca kozmetik değildir. IDE desteği, otomatik API dokümantasyonu, bağımlılık enjeksiyonu ve test araçları doğru metadata’ya güvenir. Özetle dekoratör yazarken @wraps(func) kullanmak, emniyet kemeri takmak gibidir: Kod onsuz da ilerleyebilir, fakat ilk sert virajda neden gerekli olduğunu anlarsınız.

``

Sınıf değişkeni nedir?

Sınıf değişkeni, sınıf gövdesinde tanımlanır ve sınıfın bütün örnekleri tarafından paylaşılır. Bir sınıftan $n$ adet nesne üretilse bile ilgili sınıf değişkeni için genellikle tek bir ortak nesne bulunur:

Örnek değişkeni ise çoğunlukla __init__ içinde self üzerinden oluşturulur. Her örnek kendi değerini taşır:

Temel farkı şöyle özetleyebiliriz:

Tehlikeli örnek: Ortak liste

Aşağıdaki sınıfta gorevler, sınıf seviyesinde tanımlanmıştır:

class Kullanici:
    gorevler = []

    def __init__(self, ad):
        self.ad = ad

    def gorev_ekle(self, gorev):
        self.gorevler.append(gorev)

ayse = Kullanici('Ayşe')
mehmet = Kullanici('Mehmet')

ayse.gorev_ekle('Raporu hazırla')

print(ayse.gorevler)
print(mehmet.gorevler)

Her iki çıktı da ['Raporu hazırla'] olur. Mehmet rapor hazırlamak istememişti; ancak Python onu projeye gönüllü yazdı! Bunun nedeni, ayse.gorevler ile mehmet.gorevler ifadelerinin aynı listeyi bulmasıdır.

Bunu kimlik kontrolüyle doğrulayabiliriz:

print(ayse.gorevler is mehmet.gorevler)  # True
print(id(ayse.gorevler) == id(mehmet.gorevler))  # True

Python bir niteliği ararken önce örneğin kendi alanına, ardından sınıfa bakar. gorevler örneklerin içinde bulunmadığı için sınıftaki ortak listeye ulaşılır. append, yeni bir liste atamak yerine mevcut listeyi yerinde değiştirir.

Doğru çözüm: Listeyi örnekte oluşturmak

Her kullanıcının bağımsız görev listesine sahip olması için liste __init__ içinde tanımlanmalıdır:

class Kullanici:
    def __init__(self, ad):
        self.ad = ad
        self.gorevler = []

    def gorev_ekle(self, gorev):
        self.gorevler.append(gorev)

ayse = Kullanici('Ayşe')
mehmet = Kullanici('Mehmet')

ayse.gorev_ekle('Raporu hazırla')

print(ayse.gorevler)    # ['Raporu hazırla']
print(mehmet.gorevler)  # []

Artık her Kullanici oluşturulduğunda bellekte yeni bir liste üretilir. Dolayısıyla kimlik karşılaştırması False sonucunu verir.

Her sınıf değişkeni kötü müdür?

Hayır. Değişmez veya gerçekten ortak olması gereken bilgiler için sınıf değişkenleri oldukça kullanışlıdır:

class Kullanici:
    uygulama_adi = 'Görev Ustası'
    kullanici_sayisi = 0

    def __init__(self, ad):
        self.ad = ad
        self.gorevler = []
        Kullanici.kullanici_sayisi += 1

Burada uygulama_adi bütün kullanıcılar için ortaktır. kullanici_sayisi ise oluşturulan toplam örnek sayısını izler. Buna karşılık ad ve gorevler, kullanıcıya özgüdür.

Atama ile değiştirme arasındaki ince fark

nesne.gorevler = [] yazmak, örnek üzerinde yeni bir nitelik oluşturabilir ve sınıf değişkenini gölgeleyebilir. Fakat nesne.gorevler.append(...) ortak nesneyi doğrudan değiştirir. Bu nedenle yalnızca çıktıya bakmak yerine verinin nerede tanımlandığını sorgulamak önemlidir.

Pratik kural şudur: Bir değer nesneye özgüyse self ile oluşturun. Liste, sözlük veya küme gibi değiştirilebilir yapıları sınıf gövdesine koymadan önce mutlaka “Bunun bütün örneklerce paylaşılmasını gerçekten istiyor muyum?” diye sorun. Cevap hayırsa doğru adres __init__ metodudur.

``

Yer çekimi robot kolunu nasıl etkiler?

Robot kolunun her bağlantısının bir kütlesi ve kütle merkezi vardır. Yer çekimi bu merkezlerde kuvvet oluşturur; eklem motorları da ters yönde tork üretmek zorunda kalır. Basit, tek eklemli bir kol için gerekli dengeleme torku yaklaşık olarak şöyledir:

Burada $m$ bağlantının kütlesi, $g$ yer çekimi ivmesi, $l_c$ eklem ile kütle merkezi arasındaki mesafe, $\theta$ ise kolun açısıdır. Çok eklemli robotlarda tüm bağlantılar birbirini etkiler ve denklem vektörel hâle gelir:

$G(q)$ terimi, eklemlerin yer çekimine karşı üretmesi gereken torkları temsil eder. Telafinin temel fikri, denetleyiciye önceden hesaplanmış $G(q)$ değerini eklemektir:

Böylece geri besleme denetleyicisi büyük konum hataları oluşmasını beklemeden doğru torku uygular.

Yazılımsal ve mekanik telafi aynı şey mi?

Hayır. Yazılımsal telafi hareket kalitesini artırır ancak motorun fiziksel olarak tork üretme zorunluluğunu ortadan kaldırmaz. Mekanik telafi ise yükün bir kısmını gerçekten yaylara veya karşı ağırlıklara aktarabilir.

En iyi sonuç çoğu zaman hibrit çözümdür: mekanik sistem yükün büyük bölümünü taşırken yazılım kalan hatayı düzeltir.

Enerji tasarrufu nasıl hesaplanır?

Bir eklemde elektriksel tüketimi kabaca tork ve açısal hızla ilişkilendirebiliriz:

Kol sabitken $\omega=0$ olduğundan mekanik güç sıfır görünür. Fakat motor sargılarından akım geçtiği için $P_{bakır}=I^2R$ kaybı devam eder. Bu önemli ayrıntı, “hareket etmeyen robot enerji harcamaz” düşüncesini bozar.

Aşağıdaki Python kodu, telafi öncesi ve sonrası bakır kaybını yaklaşık olarak karşılaştırır:

import math

mass = 8.0          # kg
length = 0.45       # metre
angle = math.radians(30)
torque_constant = 0.8  # Nm/A
resistance = 1.2       # ohm
compensation = 0.70    # mekanik olarak karşılanan oran

gravity_torque = mass * 9.81 * length * math.cos(angle)
current_before = gravity_torque / torque_constant
current_after = gravity_torque * (1 - compensation) / torque_constant

loss_before = current_before**2 * resistance
loss_after = current_after**2 * resistance
saving = 100 * (1 - loss_after / loss_before)

print(f"Yer çekimi torku: {gravity_torque:.2f} Nm")
print(f"Tahmini bakır kaybı azalması: %{saving:.1f}")

Akım azaldığında kayıp karesel olarak düştüğü için yüzde 70 tork telafisi, ideal koşullarda yüzde 91 civarında bakır kaybı azalması sağlayabilir. Gerçek sistemlerde sürücü kayıpları, sürtünme ve değişken yük nedeniyle sonuç daha düşük olur.

Tasarımda dikkat edilmesi gerekenler

Yanlış kütle veya kütle merkezi tahmini robotun titremesine, sürüklenmesine ya da gereğinden fazla tork üretmesine yol açabilir. Ayrıca karşı ağırlık enerji kazandırırken robotun ataletini yükseltip hızlı hareketleri pahalılaştırabilir. Bu nedenle başarı yalnızca “daha büyük yay” seçmekten değil; görev çevrimi, yük değişimi, güvenlik ve hareket hızını birlikte değerlendirmekten geçer.

Doğru tasarlanan yer çekimi telafisi daha küçük motorlar, daha düşük sıcaklık, uzun batarya ömrü ve daha güvenli insan-robot etkileşimi sağlar. Robot koluna görünmez bir destek eli vermek, enerji verimliliğinin en etkili yollarından biridir.