``

Önce problemi doğru tarif edelim

Kaynak optimizasyonunun temelinde yöneylem araştırması bulunur. Sistem; karar değişkenlerini, kısıtları ve hedefleri matematiksel bir modele dönüştürür. Örneğin karar, uygun bir elektif yatışın belirli bir güne planlanıp planlanmayacağı olabilir. Kısıtlar ise kullanılabilir yatakları, bakım saatlerini ve cihaz kapasitesini temsil eder.

Ancak kaynaklar birbirinin yerine geçmez. Boş bir servis yatağı, yoğun bakım yatağının alternatifi değildir; müsait bir çalışan da her uzmanlık görevini üstlenemez. Bu nedenle toplam kapasiteden önce klinik uygunluk ve yetkinlik kontrol edilir.

Matematik: Kapasiteyi aşmadan değer üretmek

Basitleştirilmiş bir günlük modelde $x_i$, aday yatış planlanırsa $1$, aksi durumda $0$ olsun. $u_i$ klinik ekipçe belirlenen öncelik puanını, $a_{ir}$ adayın kaynak tüketimini, $C_r$ ise kapasiteyi göstersin:

Bu yapı, çok boyutlu sırt çantası problemine benzer: Çantamız hastane, bölmeleri ise kaynaklardır. Gerçek modeller ayrıca bekleme süresi, fazla mesai ve iş yükü dengesizliğini ele alır. Bu hedeflerin ağırlıkları gelişigüzel seçilmemeli; klinik yönetişimle belirlenmelidir. Güvenlik şartları, birkaç puan uğruna esnetilen tercihler değil, zorunlu kısıtlardır.

Hangi algoritma, hangi iş için?

Önceliği en yüksek hastayı sırayla yerleştirmek caziptir. Fakat bu hasta kıt bir cihazın çoğunu kullanıyorsa, başka uygun kombinasyonlar toplamda daha iyi sonuç verebilir. Optimizasyonun farkı, kararları tek tek değil, birbirleriyle etkileşimleri içinde değerlendirmesidir.

Python ile küçük bir planlama modeli

Aşağıdaki örnek, OR-Tools üzerinden günlük elektif yatış adaylarını seçer. Kurulum için pip install ortools kullanılabilir. Her satır sırasıyla yatak, hemşirelik saati, cihaz saati ve öncelik puanı içerir; değerler tamamen örnektir.

from ortools.sat.python import cp_model

adaylar = [(1, 8, 6, 9), (1, 10, 8, 8),
           (1, 6, 4, 6), (1, 4, 0, 4)]
kapasiteler = [3, 24, 16]

model = cp_model.CpModel()
x = [model.new_bool_var(f"aday_{i}")
     for i in range(len(adaylar))]

for r, kapasite in enumerate(kapasiteler):
    model.add(sum(adaylar[i][r] * x[i]
                  for i in range(len(adaylar))) <= kapasite)

model.maximize(sum(adaylar[i][3] * x[i]
                   for i in range(len(adaylar))))

solver = cp_model.CpSolver()
solver.parameters.max_time_in_seconds = 2.0
sonuc = solver.solve(model)

if sonuc in (cp_model.OPTIMAL, cp_model.FEASIBLE):
    print([i for i in range(len(adaylar)) if solver.value(x[i])])
else:
    print("Süre içinde uygulanabilir plan bulunamadı.")

Bu veride en iyi seçim, sıfırdan başlayan indekslerle [0, 1, 3] olur. Toplam tüketim üç yatak, 22 hemşirelik saati ve 14 cihaz saatidir. FEASIBLE, uygulanabilir çözüm bulunduğunu söyler; OPTIMAL ise en iyiliğin kanıtlandığını belirtir.

Önemli ayrıntı: Günlük saat toplamı, aynı anda yeterli personel veya cihaz bulunduğunu garanti etmez. Gerçek çizelgelemede zaman aralıkları tanımlanır; NoOverlap tek cihazdaki çakışmaları, Cumulative eşzamanlı kapasite kullanımını sınırlar. Personel yetkinliği ve hasta bakım oranları ayrıca modellenir.

Planı yaşayan bir sisteme dönüştürmek

Acil başvurular, geciken taburculuklar ve cihaz arızaları planı değiştirir. Bu yüzden tahminler senaryolarla sınanmalı, beklenmedik talep için kapasite tamponu bırakılmalı ve plan düzenli güncellenmelidir. Her değişimde tüm vardiyayı dağıtmak yerine, mevcut plana sadakati gözeten cezalar kullanılabilir.

Başarıyı yalnızca yatak doluluğuyla ölçmeyin: Bekleme süresi, fazla mesai, iptaller, bakım güvenliği ve çalışan yükü birlikte izlenmelidir. Sistem karar desteğidir; acil bakımın reddini otomatikleştirmez. Klinik onay, insan müdahalesi, erişim kontrolü ve denetlenebilir karar kayıtları korunmalıdır. İyi algoritma, hastaneyi bir elektronik tabloya değil, daha uyumlu çalışan bir ekibe dönüştürür.

``

Önce mantık: Başlık dosyası ne sağlar?

#include, ilgili başlık dosyasını programa dahil eder. Başlıklar, fonksiyon bildirimlerini, türleri ve gerekli makroları sunar; fonksiyonların gerçek uygulamaları ise kütüphanelerdedir. Derleyici çağrının türlerini denetler, bağlayıcı gerekli uygulamaları birleştirir. Kısacası başlık dosyası menüdür; yemeği hazırlayan mutfak, kütüphanenin uygulamasıdır. Bu ayrım, derleme hatasıyla bağlama hatasını birbirinden ayırmayı kolaylaştırır.

Matematik: Formülü yeniden icat etmeyin

<math.h>, kayan noktalı hesaplamalar için temel araç kutusudur. sqrt(x) karekök, pow(x, y) üs, fabs(x) mutlak değer hesaplar. Tamsayılar için kullanılan abs ise <stdlib.h> içindedir. floor, ceil ve round farklı yuvarlama kurallarına sahiptir; özellikle negatif sayılarda birbirlerinin yerine kullanılmamalıdır.

İki noktanın uzaklığı şu bağıntıyla bulunur:

Bu hesap için hypot(dx, dy), ara işlemlerde taşma ve aşırı küçülme riskini azaltabilir. Trigonometrik fonksiyonlar radyan bekler. Ayrıca kayan nokta sonuçları yaklaşık olabilir; matematikteki eşitlik, bilgisayarda her zaman birebir eşitlik değildir. Negatif bir değerin karekökü gibi tanım dışı girdilerin hata davranışı da kontrol edilmelidir.

Metin işleme: Sonlandırıcı karakteri unutmayın

C dizeleri, \0 karakteriyle biten karakter dizileridir. strlen, bu sonlandırıcıdan önceki baytların sayısını verir; UTF-8 metindeki görünen harf sayısını garanti etmez. strcmp eşitlik durumunda sıfır döndürür, diğer durumlarda işaretine bakılır; yalnızca -1 veya 1 döneceğini varsaymayın.

memcpy, belirtilen sayıda baytı kopyalar ve bölgeler örtüşmemelidir. Örtüşme ihtimali varsa memmove kullanılır. strncpy ise her durumda sonlandırıcı eklemez; adı güvenlik garantisi değildir. Dize fonksiyonları sonlandırıcıya, bellek fonksiyonları verilen uzunluğa güvenir.

<ctype.h> fonksiyonlarına sıradan bir char verirken (unsigned char) dönüşümü yapmak önemlidir; negatif karakter değerleri tanımsız davranışa neden olabilir.

Bellek yönetimi: Alanın sahibi sizsiniz

Dinamik bellek, boyutu çalışma sırasında belirlenen verileri saklamaya yarar. Ayırdığınız alanın kapasitesi ile içine koyduğunuz verinin uzunluğu farklı kavramlardır. Dize için gereken kapasite genellikle $uzunluk + 1$ bayttır; fazladan bayt sonlandırıcı içindir. Ayırma işleminin başarısız olabileceğini de unutmamak gerekir.

Birlikte çalışan küçük bir örnek

Aşağıdaki program bir metni dinamik belleğe kopyalar, kapasitesini artırır ve matematik fonksiyonlarıyla sonuç üretir. Böylece üç araç kutusunu aynı yerde görürüz.

#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void) {
    const char *kaynak = "Merhaba C";
    size_t kapasite = strlen(kaynak) + 1;
    char *metin = malloc(kapasite);
    if (metin == NULL) {
        return EXIT_FAILURE;
    }

    memcpy(metin, kaynak, kapasite);
    char *yeni = realloc(metin, kapasite + 16);
    if (yeni == NULL) {
        free(metin);
        return EXIT_FAILURE;
    }
    metin = yeni;
    strcat(metin, "!");

    printf("%s | Uzunluk: %zu | Kok: %.2f | Us: %.2f\n",
           metin, strlen(metin), sqrt(9.0), pow(2.0, 3.0));
    free(metin);
    return EXIT_SUCCESS;
}

memcpy, sonlandırıcı dahil bütün diziyi kopyalar. Eklenen kapasite, ünlem ve sonlandırıcı için yeterlidir. realloc sonucu geçici işaretçide tutulur: Sıfırdan büyük boyutla yapılan çağrı başarısız olursa eski alan geçerliliğini korur. Sonucu doğrudan metin üzerine yazmak, eski adresi kaybettirebilir.

Birçok Unix benzeri ortamda matematik kütüphanesini ayrıca bağlamak gerekir:

cc -std=c11 -Wall -Wextra main.c -o uygulama -lm

Son kontrol listesi basittir: Kapasiteleri doğrulayın, dönüş değerlerini inceleyin ve ayırdığınız belleği bırakın. Genel boyut hesaplarında n * sizeof(eleman) çarpımının taşmasını önceden denetleyin. Serbest bırakılmış belleğe erişmeyin. Hazır fonksiyonlar işi hızlandırır; güvenli kullanım ise hâlâ programcının sorumluluğudur.

``

Temel Mantık: Olay, Koşul ve Eylem

IFTTT adı, “If This Then That” ifadesinden gelir: “Bu olursa, şunu yap.” Platformdaki otomasyon tariflerine Applet denir. Basit bir Applet, bir servisin tetikleyicisini başka bir servisin eylemine bağlar.

Burada üç kavramı ayırmak önemlidir. Olay, sistemde gerçekleşen değişikliktir. Koşul, olayın işlenmeye değer olup olmadığını belirler. Eylem ise başka bir sistemde oluşturulan sonuçtur. Örneğin yeni bir kayıt olaydır; kaydın acil olması koşuldur; bildirim göndermek eylemdir.

Bu ilişkiyi şöyle gösterebiliriz:

Burada $E$, ilgili olayın gerçekleşmesini; $C$, ek koşulun sağlanmasını; $A$ ise eylemin çalıştırılmasını temsil eder. Yalnızca tetikleyici kullanan basit tariflerde ek koşulu sürekli doğru kabul edebilirsiniz.

Önemli ayrıntı: İki bağımsız tetikleyiciyi otomatik olarak “VE” mantığıyla birleştiremezsiniz. Ek filtreler, çoklu eylemler ve kullanılabilir servisler hesap planına veya entegrasyona göre değişebilir. Karmaşık kararlar için araya kendi küçük uygulamanızı koyabilirsiniz.

Zincirler Neden Asenkron Çalışır?

Servisler aynı programın fonksiyonları değildir. Aralarında ağ bağlantıları, kimlik doğrulama ve bekleme süreleri bulunur. Bazı tetikleyiciler değişiklikleri belirli aralıklarla kontrol eder; bazıları ise olay geldiğinde doğrudan haber verir. Bu ikinci yaklaşımın yaygın araçlarından biri webhook mekanizmasıdır.

Webhook, kabaca “Bir şey olduğunda şu adrese HTTP isteği gönder” anlaşmasıdır. Kapıyı sürekli kontrol etmek yerine zil takmak gibi düşünün. Yine de zilin çalması, içerideki herkesin işini tamamladığı anlamına gelmez!

Bir zincirin yaklaşık gecikmesi şöyle modellenebilir:

Bu yüzden bildirim otomasyonları için uygun bir zincir, milisaniyelik tepki gerektiren kontrol sistemleri için uygun olmayabilir.

Uygulama: Acil GitHub Kaydını Telefona Taşıyalım

Örnek mimarimiz şöyle olsun: GitHub webhook → Python uygulaması → IFTTT Webhooks → telefon bildirimi. GitHub olayını alan uygulama, issue verisini inceler; yalnızca urgent etiketli kayıtları IFTTT’ye iletir.

IFTTT tarafında önce Webhooks servisindeki Receive a web request tetikleyicisini seçin. Olay adını urgent_issue yapın. Ardından Notifications servisindeki bildirim eylemini seçerek mesajda Value1 ve Value2 alanlarını kullanın. Webhooks anahtarınızı ortam değişkenine kaydedin; kaynak koduna veya herkese açık depoya koymayın.

Aşağıdaki fonksiyon, sunucunuzun doğruladığı webhook içeriğindeki issue nesnesini işler. requests paketinin kurulu olması gerekir:

import os
import requests

processed = set()

def route_issue(issue):
    issue_id = str(issue["id"])
    labels = {item["name"] for item in issue.get("labels", [])}

    if "urgent" not in labels or issue_id in processed:
        return "atlandı"

    key = os.environ["IFTTT_WEBHOOK_KEY"]
    url = f"https://maker.ifttt.com/trigger/urgent_issue/with/key/{key}"
    response = requests.post(
        url,
        json={"value1": issue["title"], "value2": issue["html_url"]},
        timeout=5,
    )
    response.raise_for_status()
    processed.add(issue_id)
    return "iletildi"

Fonksiyon etiketi denetler, başlık ve bağlantıyı gönderir, başarılı HTTP yanıtından sonra kaydı işaretler. Bu yanıt, telefon bildiriminin kesin teslim edildiğini kanıtlamaz. GitHub webhook imzasının doğrulanması ve ilgili olay türlerinin seçilmesi, bu fonksiyonu çağıran sunucunun sorumluluğudur.

Sağlam Zincirin Görünmeyen Kuralları

Örnekteki bellek kümesi yalnızca prototip içindir: uygulama yeniden başladığında temizlenir ve eşzamanlı çağrılarda yarış koşullarını engellemez. Üretimde kalıcı kayıtlar ve atomik kontroller kullanın. Aynı girdinin tekrar işlenmesinin istenmeyen ek sonuç üretmemesine idempotent davranış denir.

Son olarak her adımı kaydedin, ancak anahtarları ve hassas verileri loglardan çıkarın. Başarısızlıkları görünür kılın ve yeniden denemeleri sınırlayın. İyi otomasyon, her şeyi körlemesine yapan değil; ne zaman duracağını da bilen dijital yardımcıdır.

1. Önce fizik: Dinlediğimiz şey ne?

Vücuttaki su ve yağ molekülleri bol miktarda hidrojen içerir. Hidrojen çekirdeklerinin manyetik özellikleri, güçlü bir ana manyetik alan içinde ölçülebilir bir toplam mıknatıslanma oluşturur. Çekirdeklerin karakteristik dönme hareketinin frekansı, Larmor bağıntısıyla açıklanır:

Burada $B_0$ ana manyetik alan, $\gamma$ ise jiromanyetik orandır. Protonlar için $\gamma/(2\pi)$ yaklaşık $42{,}58$ MHz/T olduğundan, 3 teslalık bir cihazda rezonans frekansı yaklaşık 128 MHz olur.

Radyo frekansı darbesi mıknatıslanmayı dengeden uzaklaştırır. Darbe sonrasında değişen mıknatıslanma, alıcı bobinlerde elektriksel sinyal indükler. Dokuların $T_1$ ve $T_2$ gevşeme özellikleri farklıdır; çekim parametreleriyle birlikte görüntü kontrastını belirler. Yani parlaklık, yalnızca “burada ne kadar hidrojen var?” sorusunun cevabı değildir.

2. Konum bilgisi sinyale nasıl eklenir?

Tek bir toplu sinyal, hangi dokunun nerede olduğunu söylemez. Bu, kalabalık bir odadaki bütün konuşmaları tek mikrofonla kaydetmeye benzer. MR’ın çözümü, manyetik alanı konuma göre değiştiren gradyan alanlarıdır.

Kesit seçimi sırasında gradyanla birlikte uygulanan uygun frekans aralığındaki bir RF darbesi, hedeflenen kesiti uyarır. Diğer gradyanlar, sinyale konuma bağlı faz ve frekans farklılıkları ekler.

Her eksendeki k-uzayı koordinatı, ilgili gradyanın zaman içindeki birikimiyle ilişkilidir:

Burada önemli programlama fikri şudur: Cihaz doğrudan piksel adreslerini okumaz. Ölçüm zamanlamasını ve gradyanları kontrol ederek görüntüyü hesaplamaya yetecek veriyi toplar. Böylece donanımın zaman çizelgesi, yazılımın veri koordinatlarına dönüşür.

3. K-uzayı: Görüntünün frekans günlüğü

Toplanan veriler k-uzayı denen uzaysal frekans alanına yerleştirilir. Basitleştirilmiş iki boyutlu model şöyledir:

$m(x,y)$, proton yoğunluğu, gevşeme ve faz etkilerini içeren etkin görüntüdür. Bu sade modelde bobin duyarlılığını sabit kabul ediyoruz.

Ancak tek bir k-uzayı noktası, tek bir görüntü pikseline karşılık gelmez. Her ölçüm, görüntünün tamamına yayılan bir örüntü hakkında bilgi taşır. Asıl sürpriz burada!

4. Bilgisayarın iş akışı

Alıcı sistem sinyali yükseltir, sayısallaştırır ve demodülasyonla karmaşık taban bant verisine dönüştürür. Karmaşık sayılar hem genliği hem fazı saklar; fazı erkenden atmak, konum bilgisini kaybetmek demektir.

Kartezyen örneklemede rekonstrüksiyonun temel adımı ters ayrık Fourier dönüşümüdür. FFT algoritmaları bu hesabı yaklaşık $O(N\log N)$ maliyetle gerçekleştirir. Ardından bobin görüntüleri birleştirilir, gerekli düzeltmeler uygulanır ve sonuç görüntülenir. Kartezyen olmayan örneklemelerdeyse doğrudan standart FFT yerine yeniden örnekleme veya farklı dönüşüm yöntemleri gerekir.

5. Python ile minik bir sanal deney

Aşağıdaki kod, yapay bir nesneden k-uzayı üretir ve ters dönüşümle nesneyi geri getirir. Gerçek MR fiziğini bütünüyle simüle etmez; Fourier ilişkisinin hesaplama tarafını gösterir.

import numpy as np
import matplotlib.pyplot as plt

n = 128
axis = np.linspace(-1, 1, n, endpoint=False)
x, y = np.meshgrid(axis, axis)
phantom = np.exp(-6 * (x**2 + y**2))
phantom += 0.6 * ((x - 0.3)**2 + y**2 < 0.08)

kspace = np.fft.fftshift(
    np.fft.fft2(np.fft.ifftshift(phantom))
)
image = np.fft.fftshift(
    np.fft.ifft2(np.fft.ifftshift(kspace))
)

fig, axes = plt.subplots(1, 2)
axes[0].imshow(np.log1p(np.abs(kspace)), cmap="gray")
axes[1].imshow(np.abs(image), cmap="gray")
plt.show()

fftshift, sıfır frekansı merkeze taşır. Logaritmik gösterim, k-uzayındaki geniş genlik aralığını görünür kılar. Son görüntüde abs, karmaşık sonucun büyüklüğünü gösterir; bazı MR uygulamalarında faz görüntüsü de ayrıca değerlidir.

6. Gerçek dünya neden daha zor?

Hasta hareketi, gürültü ve alan düzensizlikleri ideal modeli bozar. Eksik veri toplamak çekimi hızlandırabilir, fakat bedelsiz değildir:

Modern algoritmalar bu dengeyi yönetir. MR’ın bilgisayar bilimi tam da burada parlar: Görüntü, yalnızca ölçülen bir şey değil; fiziksel model, örnekleme stratejisi ve sayısal hesaplamanın birlikte ürettiği bir sonuçtur.

``

Önce mantık: SIR modeli

En yaygın başlangıç modellerinden biri SIR modelidir. Toplumu üç gruba ayırır:

• S — Duyarlı: Hastalığa yakalanabilecek kişiler.
• I — Bulaştırıcı: Hastalığı başkalarına aktarabilen kişiler.
• R — İyileşmiş: Bu modelde artık bulaştırmayan ve yeniden enfekte olmayan kişiler.

Doğum, ölüm ve göçü dışarıda bırakırsak toplam nüfus sabittir: $N=S+I+R$. İnsanlar önce S grubundan I grubuna, ardından R grubuna geçer. Bu, herkesin birbirine benzer olasılıkla temas ettiği varsayılan bir modeldir; gerçek hayattaki arkadaş çevreleri ve okul koridorları şimdilik sahne dışında kalır.

Modelin iki temel parametresi vardır. $\beta$, bulaşmayı belirleyen etkin temas hızıdır; $\gamma$ ise iyileşme hızıdır. İkisi de zamanın tersi birimine sahiptir. Sabit iyileşme hızı varsayımında ortalama bulaştırıcılık süresi $1/\gamma$ olur.

Bu denklemler, grupların değişim hızını anlatır. Yeni enfeksiyonlar hem duyarlı hem bulaştırıcı kişiler bulunduğunda oluşur; iyileşmeler ise bulaştırıcı grubunu küçültür.

Tamamen duyarlı bir toplumda temel üreme sayısı $R_0=\beta/\gamma$ olarak hesaplanır. Örneğin $\beta=0.3$ ve $\gamma=0.1$ için $R_0=3$ çıkar. Fakat duyarlı nüfus azaldıkça etkin üreme sayısı $R_e=R_0S/N$ düşer. Bu modelde $R_e<1$ olduğunda bulaştırıcı sayısının azalma eğilimi beklenir.

Hangi model, hangi soru?

Denklemleri doğrudan çözmek düzgün eğriler üretir. Olasılıksal simülasyonda ise günlük sayılar dalgalanır. Özellikle başlangıçta az sayıda bulaştırıcı varsa, aynı parametrelerle bazı salgınlar büyüyebilir, bazıları erken sönebilir. Rastgelelik burada süs değil, modelin önemli bir parçasıdır.

Python ile olasılıksal simülasyon

Aşağıdaki örnekte her adım çeyrek gündür. Bir duyarlı kişinin enfekte olma olasılığını $p=1-e^{-\beta(I/N)\Delta t}$, bir bulaştırıcının iyileşme olasılığını ise $q=1-e^{-\gamma\Delta t}$ olarak hesaplıyoruz. Ardından binom dağılımından geçiş sayıları çekiyoruz. NumPy için pip install numpy yeterlidir.

import numpy as np

rng = np.random.default_rng(42)
N = 10_000
S, I, R = N - 10, 10, 0
beta, gamma, dt = 0.3, 0.1, 0.25
history = [(0.0, S, I, R)]

for step in range(1, int(120 / dt) + 1):
    p_infection = 1 - np.exp(-beta * I / N * dt)
    p_recovery = 1 - np.exp(-gamma * dt)

    infections = rng.binomial(S, p_infection)
    recoveries = rng.binomial(I, p_recovery)

    S -= infections
    I += infections - recoveries
    R += recoveries

    assert S + I + R == N
    assert min(S, I, R) >= 0
    history.append((step * dt, S, I, R))

peak = max(history, key=lambda row: row[2])
print("Zirve günü:", peak[0])
print("Zirvedeki bulaştırıcı sayısı:", peak[2])

Geçişler adımın başındaki sayılardan hesaplanır; yeni enfekte olanlar aynı adımda iyileşmez. Bu, sürekli zamanlı sürecin ayrık zaman yaklaşımıdır. Daha küçük adımlar genellikle yaklaşımı iyileştirir, fakat hesaplama yükünü artırır. Sabit rastgelelik tohumu sonucu tekrarlanabilir kılar; assert ifadeleri de nüfus muhasebesini denetler.

Deney tasarlamak, tek eğriden değerlidir

Şimdi sanal laboratuvarın düğmeleriyle oynayabiliriz:

• Temasları azalt: Belirli bir günden sonra $\beta$ değerini düşür; zirvenin yüksekliğini ve zamanını karşılaştır.
• Başlangıç bağışıklığını değiştir: Kusursuz koruma varsayımıyla bazı kişileri başlangıçta R grubuna yerleştir.
• Tekrarlı koşular yap: Farklı tohumlarla yüzlerce simülasyon çalıştır; yalnızca ortalamayı değil, yüzdelik aralıkları da raporla.

Zirvedeki bulaştırıcı sayısı, toplam enfekte olan kişi sayısıyla aynı değildir. Ayrıca daha alçak bir zirve, salgının daha kısa süreceği anlamına gelmez. Ölçütü araştırma sorusuna göre seçmek gerekir.

Modelin sınırlarını unutma

Buradaki sayılar varsayımsaldır. Yaş, davranış değişimi, mevsimsellik, yeniden enfeksiyon ve eksik bildirim sonuçları değiştirebilir. Gerçek verilerle çalışırken parametre tahmini, duyarlılık analizi ve bağımsız doğrulama gerekir. İyi simülasyon kesinlik satmaz; varsayımlar açıkça belirtilirse, hangi koşullarda hangi sonuçların mümkün olduğunu anlamamıza yardım eder.

``

Önce fizik: Bir park yeri nasıl konuşur?

Sistem, her park alanının fiziksel durumunu dijital bir sinyale dönüştürür. Ultrasonik sensör mesafeyi ölçerken manyetik sensör, aracın oluşturduğu manyetik alan değişimini izler. Kamera tabanlı çözümler ise görüntüdeki araçları ve park sınırlarını analiz eder.

Buradaki temel ayrım, ölçüm ile durumun aynı şey olmamasıdır. Sensör mesafe üretir; yazılım bu mesafeyi değerlendirerek “boş” veya “dolu” kararı verir. Yağmur, yaya hareketi ve yanlış hizalama gibi etkenler nedeniyle tek ölçümle karar vermek risklidir. Kurulum sırasında zemine ve araç tiplerine uygun kalibrasyon gerekir.

Doluluk hesabında üçüncü bir durum var

Bir park yeri yalnızca boş veya dolu değildir: bağlantısı kesildiyse bilinmiyor olabilir. Toplam kapasiteyi $C$, boş yerleri $B$, dolu yerleri $D$, bilinmeyenleri $U$ ile gösterelim:

Güncel ölçümü bulunan alanların doluluk oranı, $B + D > 0$ olduğunda şöyle hesaplanır:

Bu oran tüm otoparkı değil, gözlemlenebilen bölümünü anlatır. Ekranda bilinmeyen alan sayısı da gösterilmelidir. Aksi halde çevrimdışı sensörler yüzünden otopark olduğundan daha boş görünebilir. Eski veri, boş yer vaadi değildir!

Verinin yolculuğu: Sensörden canlı haritaya

Tipik akış şöyledir: sensör → ağ geçidi → MQTT broker → durum servisi → mobil uygulama. Ağ geçidi ölçümlere park kimliği, zaman damgası ve sıra numarası ekler. MQTT, küçük mesajları yayınlama-abonelik modeliyle ilgili servislere taşır.

Durum servisi güncel haritayı saklar; değişiklikleri WebSocket veya SSE üzerinden uygulamaya iletir. Böylece telefon sürekli bütün otoparkı sorgulamaz. MQTT QoS 1 kullanıldığında yinelenen teslimatlar mümkün olduğundan, servis aynı mesajı tekrar işlese bile sonucu bozmamalıdır. Sıra numarası kontrolü bunun pratik yollarından biridir.

Python ile küçük ama temkinli bir durum motoru

Aşağıdaki örnek, eski mesajları reddeder ve aynı sonucu üç ardışık ölçümde gördüğünde durumu değiştirir. Olaylar slot_id, occupied, seq ve observed_at alanlarını içerir:

from time import time

slots = {}

def ingest(event):
    age = time() - event['observed_at']
    if not 0 <= age <= 10:
        return

    slot = slots.setdefault(event['slot_id'], {
        'seq': -1, 'candidate': None, 'hits': 0,
        'state': 'bilinmiyor', 'updated': 0
    })
    if event['seq'] <= slot['seq']:
        return

    value = 'dolu' if event['occupied'] else 'bos'
    slot['hits'] = slot['hits'] + 1 if value == slot['candidate'] else 1
    slot.update(candidate=value, seq=event['seq'],
                updated=event['observed_at'])
    if slot['hits'] >= 3:
        slot['state'] = value


def snapshot():
    now = time()
    return {
        key: item['state'] if now - item['updated'] <= 10
        else 'bilinmiyor'
        for key, item in slots.items()
    }

Üçlü doğrulama, gelip geçen bir yayayı otomobil sanma ihtimalini azaltır; fakat algılama gecikmesini artırır. On saniye boyunca güncellenmeyen alan, sorgu anında bilinmiyor olarak gösterilir. Üretimde bu eşikler ölçüm sıklığına göre ayarlanmalı, saatler senkronize edilmeli ve sıra numaraları cihaz yeniden başlatıldığında güvenle yönetilmelidir. Ayrıca bellek yerine kalıcı durum depolaması ve eşzamanlı işlem kontrolü gerekir.

“Anlık” demek sıfır gecikme demek değildir

Ölçümden ekrana toplam gecikme yaklaşık olarak $L = L_{ağ} + L_{işleme} + L_{iletim} + L_{arayüz}$ şeklinde modellenebilir. Örneğin bu aşamalar 80, 40, 100 ve 150 milisaniye sürerse toplam 370 milisaniyedir. Ancak aracın gelişi ile ilk ölçüm arasındaki bekleme ve doğrulama süresi de kullanıcı deneyimine eklenir.

Bu nedenle yalnızca ortalamayı değil, yoğun saatlerdeki yüksek gecikmeleri de izlemek gerekir. Arayüzde son güncelleme zamanı gösterilmeli; bağlantı kopunca yeşil kutular sonsuza kadar yeşil kalmamalıdır.

Boş yer bildirimi, rezervasyon değildir

İki sürücü aynı boşluğu aynı anda görebilir. Sistem yalnızca yönlendirme yapıyorsa müsaitliğin değişebileceğini belirtmelidir. Yer ayırma sunuluyorsa süreli rezervasyon ve atomik güncelleme gerekir; ilk başarılı işlem yeri alır.

Kamera kullanıldığında mümkünse görüntüler yerinde işlenmeli, merkeze yalnızca doluluk bilgisi gönderilmelidir. Başarılı sistemin sırrı daha çok veri toplamak değil; doğru, güncel ve gerekli veriyi sürücüye ulaştırmaktır.

``

Önce beklentiyi doğru ayarlayalım

Bir beyin–bilgisayar arayüzü, İngilizce kısaltmasıyla BCI, kas hareketlerini zorunlu tutmadan sinirsel etkinlik üzerinden iletişim kurmayı hedefler. Örneğin kullanıcı sağ veya sol elini hareket ettirdiğini hayal eder; sistem bu iki durumu ayırt etmeye çalışır. Bazı sistemlerdeyse kullanıcı yanıp sönen seçeneklerden birine odaklanır. Buradaki bilgi, serbest düşüncenin içeriği değil, önceden tanımlanmış bir görevle ilişkili örüntüdür.

Ölçüm yöntemleri aynı kapıya farklı yollardan ulaşır:

Sinyalden komuta: küçük bir çeviri fabrikası

Tipik işlem zinciri şöyledir:

Ölçüm → temizleme → özellik çıkarımı → sınıflandırma → komut → geri bildirim.

EEG, tek bir nöronun konuşması değildir. Çok sayıda kaynağın elektriksel etkileri, ölçüm noktasında birbirine karışır. Göz kırpması, çene kasları ve elektrik şebekesi de bu karışıma katılabilir. Dolayısıyla yüksek genlik, otomatik olarak güçlü bir niyet anlamına gelmez.

Motor imgelemede sık incelenen özellikler, yaklaşık 8–13 Hz mu ve 13–30 Hz beta bantlarındaki güç değişimleridir. Bu değişimler kişiye ve göreve göre farklılaşır; sabit bir düşünce sözlüğü oluşturmazlar. Özellik vektörünü $h$ ile gösterirsek, basit bir ikili sınıflandırıcı şöyle yazılabilir:

Burada $w$ öğrenilen ağırlıkları, $b$ sabit terimi, $p$ ise modelin bir sınıfa verdiği olasılık tahminini temsil eder. Bu tahminin güvenilirliği ayrıca değerlendirilmelidir. Model, kişinin niyetini doğrudan bilmez; eğitim verisindeki ilişkilere dayanarak karar verir. Korelasyon, zihin okuma değildir.

Python ile bant gücünden sınıflandırmaya

Aşağıdaki örnek, NumPy, SciPy ve scikit-learn kullanır. Dosyada artefaktları önceden ele alınmış EEG denemeleri bulunmalıdır: X boyutu (deneme, kanal, örnek), y sağ/sol imgeleme etiketleri, oturum kayıt oturumu kimlikleri, fs örnekleme frekansıdır. En az üç farklı oturum gerekir.

import numpy as np
from scipy.signal import welch
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import GroupKFold, cross_val_score

d = np.load("eeg_denemeleri.npz")
X, y, oturum = d["X"], d["y"], d["oturum"]
fs = float(d["fs"])
f, psd = welch(X, fs=fs,
               nperseg=min(256, X.shape[-1]), axis=-1)

bantlar = []
for alt, ust in [(8, 13), (13, 30)]:
    sec = (f >= alt) & (f < ust)
    guc = np.trapezoid(psd[..., sec], f[sec], axis=-1)
    bantlar.append(np.log(guc + 1e-12))
F = np.concatenate(bantlar, axis=1)

model = make_pipeline(StandardScaler(),
                      LogisticRegression(max_iter=1000))
skorlar = cross_val_score(
    model, F, y, groups=oturum,
    cv=GroupKFold(n_splits=3), scoring="balanced_accuracy"
)
print(skorlar.mean())

Welch yöntemi güç spektrumunu tahmin eder; bant integralleri kanal başına özellik üretir. Logaritma, güç değerlerinin geniş aralığını sıkıştırır. Pipeline, ölçekleyicinin yalnızca eğitim bölümünde öğrenilmesini sağlar. Oturum bazlı bölme ise aynı kaydın benzer parçalarının eğitim ve teste karışmasını önler. Kod, NumPy 2 veya üzerindeki trapezoid işlevini kullanır.

Laboratuvardan gerçek hayata geçiş

Yüksek test başarısı, kullanışlı bir arayüz için tek başına yeterli değildir. Gecikme, yanlış komut sıklığı, kalibrasyon süresi ve kullanıcı yorgunluğu da ölçülmelidir. Dengeli doğruluk, sınıfların ayrı ayrı başarılarını eşit ağırlıkla değerlendirir. Rastgele deneme bölmek yerine yeni oturumlarda sınamak, günlük kullanım performansını anlamaya daha çok yardımcı olur.

Gerçek zamanlı sistemde kararsız tahminler komuta dönüştürülmeyebilir. Kullanıcıya geri bildirim vermek ve gerektiğinde onay istemek, özellikle tekerlekli sandalye gibi fiziksel sonuç doğuran uygulamalarda önemlidir. Bu örnek, güvenlik doğrulaması yapılmış bir kontrol sistemi değildir.

Sinirsel kayıtlar da hassas verilerdir: açık rıza, sınırlı saklama ve güvenli erişim tasarımın parçası olmalıdır. Klinik uygulamalarda profesyonel değerlendirme gerekir. Sonuç olarak düşünceden komuta geçmek mümkün; fakat başarılı BCI, sihirli bir okuyucu değil, kullanıcıyla birlikte öğrenen kontrollü bir çevirmen gibi çalışır.

Bir robotun sabah depoda kutu taşıyıp öğleden sonra serada bitki kontrolü yaptığını düşünün. Bunu iki ayrı makineyle çözmek mümkün; ancak modüler tasarım, aynı gövdenin hareket, algılama ve tutma bileşenlerini değiştirerek farklı görevlere uyarlanmasını sağlar. Robot biraz LEGO setine benzer, fakat burada parçaların yalnızca birbirine oturması değil, birlikte güvenle çalışması gerekir. ``

Modülerlik: Parçalardan Daha Büyük Bir Fikir

Modüler robot, belirli işlevleri bağımsız birimlere ayıran robot mimarisidir. Tekerlek takımı hareketi, kamera çevreyi algılamayı, kavrayıcı ise nesnelerle etkileşimi üstlenebilir. Her birimin görev sınırı ve bağlantı kuralları açıkça tanımlanır. Böylece bir bileşeni değiştirmek, robotun tamamını yeniden tasarlamayı gerektirmez. Buradaki temel ilke, işlevsel ayrıştırma ve standart arayüzlerdir.

Bu yaklaşımın iki yaygın biçimi vardır. Sabit gövdeli sistemlerde uç araçlar ve sensörler değiştirilir. Yeniden yapılandırılabilir sistemlerde ise bağlantılı modüller robotun fiziksel biçimini de değiştirebilir. İlk yaklaşım endüstriyel uygulamalarda daha kolay yönetilirken ikincisi daha geniş hareket olanakları sunar; buna karşılık kontrol ve bağlantı tasarımı zorlaşır.

Mimariyi $G=(V,E)$ grafiğiyle düşünebiliriz: $V$ modülleri, $E$ ise aralarındaki bağlantıları temsil eder. Bağlantının mekanik, elektriksel veya veri taşıyan niteliği önemlidir. Bir kameranın takılabilmesi, kontrol yazılımının onu kullanabileceği anlamına gelmez!

Esnekliğin Gizli Kahramanı: Arayüzler

Başarılı modülerlik, bağlantı noktasında başlar. Mekanik arayüz; ölçüleri, kilitleme yöntemini ve taşınabilecek yükü belirlemelidir. Elektriksel arayüz; gerilim, akım sınırı, kutuplama ve koruma düzenini tanımlar. Veri arayüzü ise mesaj biçimini, haberleşme hızını ve hata davranışını kapsar. CAN veya Ethernet kullanmak tek başına yeterli değildir; modüllerin aynı mesajların anlamında da anlaşması gerekir.

Yazılım tarafında sürücüler, donanım ayrıntılarını ortak yeteneklere dönüştürebilir. Örneğin farklı kavrayıcılar aynı “aç”, “kapat” ve “durum oku” işlemlerini sunar. Böylece görev planlayıcısı marka veya model yerine yeteneklerle çalışır. Yine de kavrama kuvveti ve konum hassasiyeti gibi sınırlar ayrıca bildirilmelidir.

Fizik kuralları ise tak-çıkar heyecanına kapılmaz. Bir kolun yükten kaynaklanan torku basitçe $T=F r$ ile hesaplanır. Burada $F$ kuvvet, $r$ dönme eksenine olan dik uzaklıktır. Aynı yükü iki kat uzağa taşımak, tork ihtiyacını iki katına çıkarır. Dolayısıyla daha uzun modül, daha güçlü motor veya daha düşük taşıma kapasitesi gerektirebilir.

Python ile Göreve Uygun Yapılandırma

Aşağıdaki örnek, seçilen modüllerin besleme gerilimini ve görev yeteneklerini denetler. Donanımı hareket ettirmez; yapılandırmanın yazılım düzeyindeki bir ön kontrolüdür. Python 3.9 ve üzeriyle çalışır.

from dataclasses import dataclass

@dataclass(frozen=True)
class Module:
    name: str
    capabilities: frozenset[str]
    voltage: int = 24

modules = {
    "drive": Module("Tekerlek", frozenset({"hareket"})),
    "gripper": Module("Kavrayıcı", frozenset({"kavrama"})),
    "camera": Module("Kamera", frozenset({"görüntüleme"})),
}

def configure(names, required):
    selected = [modules[name] for name in names]
    if any(module.voltage != 24 for module in selected):
        raise ValueError("Besleme gerilimi uyumsuz")
    available = frozenset().union(
        *(module.capabilities for module in selected)
    )
    missing = set(required) - available
    if missing:
        raise ValueError(f"Eksik yetenekler: {sorted(missing)}")
    return [module.name for module in selected]

print(configure(["drive", "gripper"], {"hareket", "kavrama"}))
print(configure(["drive", "camera"], {"hareket", "görüntüleme"}))

İlk çağrı taşıma, ikinci çağrı gözlem görevine uygun parçaları seçer. Gerçek uygulamada bu kontrole mekanik uyumluluk, akım bütçesi, haberleşme protokolü ve güvenlik kısıtları da eklenmelidir. Yetenek etiketi, performans garantisi değildir.

Parça Değiştiğinde Ne Yeniden Kontrol Edilmeli?

Modül değişimi sonrasında robotun kütlesi, ağırlık merkezi ve durma mesafesi değişebilir. Kamera değişirse kalibrasyon; kavrayıcı değişirse kuvvet sınırları ve araç koordinat sistemi güncellenmelidir. Yapılandırma kaydı tutmak, hangi donanımın hangi yazılım sürümüyle test edildiğini izlemeyi kolaylaştırır. Bu kayıtlar bakım ekibinin “Dün çalışıyordu!” bilmecesini çözmesinde özellikle değerlidir.

Sistem özel olarak enerjiliyken değişime uygun tasarlanmamışsa parçalar güç kesilerek değiştirilmelidir. Ardından bağlantılar doğrulanmalı, düşük hızda işlev testi yapılmalı ve güvenlik sınırları yeniden değerlendirilmelidir.

Modülerlik her durumda daha ucuz veya daha hafif değildir. Ek bağlantılar maliyet, boşluk ve arıza noktası yaratabilir. Ancak görevler sık değişiyorsa ortak gövdeyi korumak ciddi avantaj sağlar. İyi tasarlanmış modüler robot, her işi kusursuz yapan sihirli makine değil; yeni işleri kontrollü biçimde öğrenebilen bir mühendislik platformudur.

``

Olay nedir, komuttan farkı ne?

Olay, gerçekleşmiş bir durumun kaydıdır: “Hareket algılandı.” Komut ise yapılması istenen iştir: “Lambayı aç.” Bu ayrım önemlidir; hareket sensörü lambanın nasıl çalıştığını bilmek zorunda değildir. Yalnızca gözlemini yayınlar, otomasyon kuralları da uygun komutları üretir.

Tipik mimaride üç rol vardır: olayı üreten sensör, mesajı taşıyan olay veri yolu ve mesajı işleyen tüketiciler. MQTT kullanılan sistemlerde aracı sunucu mesajları abonelere iletir. Bununla birlikte, MQTT tek başına otomasyon kurallarını değerlendirmez; bu görev uygulamanıza veya otomasyon platformuna aittir.

Bu yöntemler rakip değil, takım arkadaşıdır. Örneğin hareket olayı lambayı açarken, zamanlanmış bir görev gecenin sonunda açık kalan lambaları kapatabilir.

Zincirin matematiği: olay, koşul ve durum

Bir kuralı “olay geldi, koşul doğruysa eylemi gerçekleştir” şeklinde düşünebiliriz. Hareketi $H$, gece koşulunu $G$, lambayı açma kararını $L$ ile gösterirsek:

Ancak yalnızca koşulları değerlendirmek yetmez. Lambanın mevcut durumunu da bilmeliyiz. Durum geçişini $S_{t+1} = f(S_t, E_t)$ olarak yazabiliriz: yeni durum, önceki durum ve gelen olay tarafından belirlenir.

Lamba zaten açıksa tekrar açma komutu göndermemek, gereksiz işlemleri azaltır. Üstelik zincirin bir sonraki halkasını yalnızca gerçek durum değiştiğinde tetiklememizi sağlar. Böylece eviniz, aynı düğmeye heyecanla yüz kere basan bir robot gibi davranmaz.

Python ile küçük bir olay zinciri

Aşağıdaki örnek, sensör olayını bir kuyruğa bırakır. Hareket işleyicisi gece koşulunu değerlendirir; lamba açıldığında yeni bir olay üretir. İkinci işleyici de telefon bildirimini temsil eden çıktıyı oluşturur. Gerçek cihaz bağlantıları yerine simülasyon kullanıyoruz.

import asyncio
from dataclasses import dataclass

@dataclass
class Event:
    kind: str
    data: dict

bus = asyncio.Queue()
state = {"light": False}

async def on_motion(event):
    hour = event.data["hour"]
    is_night = hour >= 22 or hour < 6
    if is_night and not state["light"]:
        state["light"] = True
        print("Koridor lambası açıldı.")
        await bus.put(Event("light.changed", {"on": True}))

async def on_light(event):
    if event.data["on"]:
        print("Telefon bildirimi: Koridor aydınlatıldı.")

handlers = {
    "motion.detected": on_motion,
    "light.changed": on_light,
}

async def main():
    await bus.put(Event("motion.detected", {"hour": 23}))
    while not bus.empty():
        event = await bus.get()
        try:
            handler = handlers.get(event.kind)
            if handler:
                await handler(event)
        finally:
            bus.task_done()

asyncio.run(main())

handlers sözlüğü, olay türlerini ilgili fonksiyonlarla eşleştirir. Kuyruk ise üretici ile tüketiciyi birbirinden ayırır. Bu örnekte işleyiciler sırayla beklenir; async kullanılması bütün işlemlerin otomatik olarak paralel çalıştığı anlamına gelmez. Ayrıca döngü kuyruk boşalınca biter; sürekli çalışan uygulamada yeni olaylar await bus.get() ile beklenir.

Gerçek lambada durum değişikliğini, komut gönderildiği anda değil cihazdan doğrulama geldiğinde yayınlamak daha güvenilirdir. Aksi hâlde bağlantısı kopmuş bir lambayı yazılımda açık sanabilirsiniz.

Zinciri güvenilir tutmak

Olay tabanlı sistemlerin eğlenceli tarafı bağlantı kurmaktır; zor tarafı ise bağlantıları kontrol altında tutmaktır.

• Tekrarlanan mesajlar: Olay kimliği ve idempotent işleyiciler kullanın. Aynı olayın yeniden gelmesi sonucu değiştirmemelidir.
• Sonsuz döngüler: Lambanın değişimi sensör kuralını yeniden tetikliyorsa döngü oluşabilir. Kaynak bilgisi ve açık geçiş kuralları ekleyin.
• Sensör titreşimi: Çok kısa aralıklarla gelen sinyalleri filtrelemek için debounce uygulayın. Hareketli bir perdeyi misafir sanmayın!
• Bağlantı kesintileri: Yeniden deneme, zaman aşımı ve durum uzlaştırma mekanizmaları tasarlayın. Tek bir mesajı mutlak gerçek kabul etmeyin.
• Güvenlik: MQTT erişimini kimlik doğrulama ve konu bazlı yetkilerle sınırlandırın; kritik cihazlarda manuel kontrolü koruyun.

Sonuç olarak iyi otomasyon, yalnızca cihazları bağlamak değildir. Olayın anlamını, koşullarını ve oluşturduğu durum değişikliklerini açıkça tanımlamaktır. Bu temel sağlam olduğunda, tek bir sensör evinizin geri kalanıyla düzenli ve anlaşılır bir sohbet başlatabilir.

Bir banka hesabını programlamak istediğinizi düşünün: hesabın bakiyesi vardır, para çekilebilir ve işlemin sonucu öğrenilebilir. C# bu dünyayı sınıflar, nesneler ve metotlarla temsil eder. İşin eğlenceli kısmı, aynı hesaba iki farklı değişkenle ulaşabilmenizdir. Ancak bir nesneyi değiştirmekle, değişkenin gösterdiği nesneyi değiştirmek aynı şey değildir!

``

Sınıf plan, nesne çalışan örnektir

Sınıf, verileri ve davranışları bir araya getiren tür tanımıdır. Nesne, bu sınıftan oluşturulan somut örnektir. Metot ise bir nesnenin gerçekleştirebildiği işlemi tanımlar; ayrıca sınıfa ait statik metotlar da bulunabilir.

Bir sınıftan oluşturulan iki nesnenin bakiyeleri birbirinden bağımsız olabilir. Buna karşılık iki değişken aynı nesneye bağlanabilir. Aynı televizyonu yöneten iki kumanda düşünün: kumandalar farklıdır, fakat değiştirilen televizyon aynıdır.

C# sınıfları referans türüdür. Bir sınıf değişkeninin değeri, nesnenin kendisi değil, ona erişmeyi sağlayan referanstır. Referansı kopyalamak, nesneyi çoğaltmaz.

Durumu davranışla korumak

Aşağıdaki sınıf, bakiyenin dışarıdan doğrudan değiştirilmesini engeller. Kurucu metot başlangıç durumunu oluşturur; ParaCek ise çekim kurallarını uygular ve sonucu bildirir.

using System;

public class Hesap
{
    public decimal Bakiye { get; private set; }

    public Hesap(decimal bakiye)
    {
        if (bakiye < 0)
            throw new ArgumentOutOfRangeException(nameof(bakiye));

        Bakiye = bakiye;
    }

    public bool ParaCek(decimal tutar, out decimal kalan)
    {
        kalan = Bakiye;

        if (tutar <= 0 || tutar > Bakiye)
            return false;

        Bakiye -= tutar;
        kalan = Bakiye;
        return true;
    }
}

private set, bakiyenin yalnızca sınıf içinden atanabilmesini sağlar. Bu yaklaşım kapsülleme olarak adlandırılır: veriyi saklamaktan çok, geçerli durumları korumak önemlidir. Negatif başlangıç bakiyesi reddedilir; geçersiz çekim ise hesabı değiştirmez.

Başarılı çekimin matematiksel modeli şöyledir:

Burada $T$ çekilen tutardır; işlemin kabul koşulu $0 < T \leq B_{ilk}$ şeklindedir. Kod, bu koşulu denetleyerek nesnenin tutarlılığını korur. Para hesaplarında decimal, ondalık değerleri temsil etmek için genellikle double türünden daha uygundur.

Varsayılan aktarım, ref ve out

C# parametreleri varsayılan olarak değer ile aktarır. decimal parametresinde sayısal değer kopyalanır. Hesap parametresinde ise referansın değeri kopyalanır. Bu yüzden normal bir parametre üzerinden nesnenin özelliklerini değiştirmek mümkündür; bunun için ref gerekmez.

Ancak metot içinde normal parametreye new Hesap(...) atamak, çağıranın değişkenini başka nesneye yönlendirmez. Yalnızca parametrenin yerel kopyası değişir. İşte ref, çağıranın değişkenine erişim sağlayarak bu ayrımı görünür kılar.

ref ve out, hem metot bildiriminde hem çağrıda belirtilir. out parametresi, metot içinde okunmadan önce atanmalıdır. Örneğimizde kalan başlangıçta atanır; böylece başarısız çekimde bile kullanılabilir bir sonuç döner.

Referansı değiştirmek başka bir iştir

.NET 6+ konsol projesinde aşağıdaki üst düzey kullanım kodunu sınıf bildiriminden önce yerleştirebilirsiniz:

var hesap = new Hesap(100m);
var ortak = hesap;

bool basarili = hesap.ParaCek(30m, out decimal kalan);
Console.WriteLine($"Başarılı: {basarili}, kalan: {kalan}");

ortak.ParaCek(10m, out kalan);
Console.WriteLine(hesap.Bakiye); // 60

Yenile(ref hesap);
Console.WriteLine(hesap.Bakiye); // 0
Console.WriteLine(ortak.Bakiye); // 60

static void Yenile(ref Hesap hedef)
{
    hedef = new Hesap(0m);
}

İlk atamada ortak ve hesap aynı nesneyi gösterir. Dolayısıyla ortak üzerinden yapılan çekim, hesap üzerinden görülen bakiyeyi de değiştirir. Yenile ise ref sayesinde doğrudan hesap değişkeninin referansını değiştirir. ortak, eski nesneyi göstermeyi sürdürür; nesne topluca sıfırlanmamıştır.

Küçük bir seçim rehberi

Tek sonuç için çoğunlukla dönüş değerini kullanın. Başarı bilgisiyle ek sonuç gerekiyorsa out kullanışlıdır; int.TryParse bunun klasik örneğidir. Çağıranın mevcut değişkenini değiştirmek gerekiyorsa ref düşünülebilir. Son kontrol sorunuz şu olsun: “Nesnenin durumunu mu, değişkenin değerini mi değiştiriyorum?” Bu ayrım, referans karmaşasının büyük bölümünü çözer.