Mehmet Cem Yücel

Java Virtual Threads vs Go Goroutines: Project Loom ve Concurrency Performans Kıyaslaması

Tue, 04 Nov 2025 10:00:00 +0000

Kurumsal tarafta, büyük ölçekli projelerde en uzun zaman geçirdiğim dil için Java diyebilirim. Sebebi aşikar, bu yazıda uzun uzun anlatmıştım. Ancak her gücün ağır bir bedeli oluyor, o da runtime… Örneğin 2GB bellek ayırmadan bir Spring Boot projesini kullanmak zordu. 1:1 modelde her thread bir kernel thread iken hafiflik kelimesi Java’ya uzun süre hiç uğramadı.

Green Threads / Light Threads

Gerçi hiç uğramadı demek bazı eski toprakları rahatsız etmiştir. Java’nın Sun Microsystems zamanında JDK 1.1 versiyonu ile birlikte Green Threads kavramı karşımıza çıkmıştı. Light threads veya Fiber ismi de tanıdık gelmiş olabilir. Alametifarikası, direk kernel threadlere maplenen threadler değil JVM seviyesinde yönetilen user-threadler olmasıydı. Evet concurrency açısından avantaj sağlıyorlardı ancak tek bir Operating System(OS) Thread üzerinde çalıştığı için parallelism sağlayamıyorlardı. Çok çekirdekli bilgisayarların yaygınlaşmaya başlamasıyla birlikte 1.3 versiyonu ile birlikte o da tarihe karıştı. Yerine uzunca bir süre(2021e kadar) 1:1 thread modeli, yani platform threadleri ile çalışmak zorunda kalındı.

Go’nun Performansı

Biraz da bunlardan sebepli 10 küsür yıl Java ile kodlamamın ardından son 5–6 yıldır birincil tercihim Go’ya doğru döndü. Bunun ardında yatan sebepler daha verimli, hızlı ve hafif olması idi özetle. Düşük kaynak tüketimi ve hızlı açılması ile özellikle mikroservis mimarilerde ciddi avantaj sağlıyordu ve özellikle yük altında eşzamanlılık ve paralelliği yönetebilmek için sunduğu özelliklerle hem yazılım geliştirme rahat yapılıyor hem de büyük yüklerin altında ezilmiyordu.

Project Loom & Virtual Threads

Tabii Java 21 ile hayatımıza giren diğer bir gerçek de Project Loom. Java seneler sonra geliştiricileri ağır OS threadlerinden kurtarmak için butona bastı. OS threadleri neden ağır diyor olabilirsiniz, şu videoya göz atmanızı öneririm. Günün sonunda Java 21 ile birlikte Virtual Threads kavramı hayatımıza dahil oldu. Zaten bundan sebepli de her yerde Java 21 dönüşüm projelerini görüyor duyuyorsunuz muhtemelen :)

Project Loom’un Virtual Threadler ile yaptığı tıpkı Green Threadler gibi threadlerin kısmen JVM tarafından yönetilmesidir. Farkı ise birden fazla virtual thread, bir havuzdaki platform threadleri üzerine çoklanır(multiplexed) ve havuzdaki bu treadler kullanılarak çalıştırılır. Yani dünya sanal bir N:M modeline dönüşür. N adet sanal threade karşılık genellikle 2^x (2,4,8,..) yani M adet gerçek platform threadi yaratılması ve bu threadlerin efektif şekilde kullanılması için JVM’in schedular vb mekanizmalarının aracılık etmesini ifade eder.

Tabii mevzunun derinlerinde çok daha fazlası da var. Eski treadlerde bir threadin yaratılması için ~1MB kadar bir stack belleğe duyulan ihtiyaç sanal threadlerde default 1KB ile başlıyor. Bu majör değişim eskiye nazaran çalışmak üzere bekleyen virtual threadlerin ciddi azalmış bir footprintle çok daha fazlasının hazırda bekleyebilmesini ve JVM’in bunun da sayesinde daha fazla işi kendi sınırlarında optimize edebilmesini sağlıyor.

Performans Ölçüm Testleri

Hadi gelin şimdi Java Platform Threadleri, Virtual Threadleri ve en son olarak Go Routineleri bir performans testine sokalım. Bakalım neler olacak?

Java zamanla ısınan bir motora sahip :) Just In Time(JIT) derleyicilerin nasıl çalıştığı ile ilgili şuradaki podcaste göz atabilirsiniz. Özetle, direk yükü vurmadan önce ufak bir warm-up seti ile çalıştırmak genel performans kıyası açısından daha doğru sonuç verecektir. Go ise Ahead Of Time(AOT) derleyici ile çalışır, teknik olarak Java gibi warm-up’ a ihtiyacı yoktur. Ancak ufak da olsa ilk sistem structlarının oluşmasında, P/M/G tablosunun kurulmasında minimal bir etkisi olabilir. Aynı şartlarda olması adına ikisinde de warm-up’ı tutacağım. Ayrıca direk yüksek rakamlarla denemek yerine tüm testlerde ramp-up stratejisi ile ilerleyeceğiz.

Java Platform Thread

Java Platform Threadleri aslında kıyas yapmaktan ziyade Virtual Threadlerle nereden nereye geldik görebilmek için ekliyorum. Keza altındaki mimarinin farkında olmak Goroutine’ler ile kıyas yaparken farkı anlayabilmek için de önemli olacak.

Şöyle bir kod yazdım, bunun benzerini virtual threadler için de kullanacağız. Önce makinemin özelliklerini yazdırıyorum, sonra ufak bir ısınma sonrası 1000 threadlik bulk bir set ile çalışmayı başlatıp bir nefes arası veriyorum. Bu sırada bellekteki son durumu görüp bir sonraki bulk sete geçe geçe devam ediyorum. Kodu çalıştırır çalıştırmaz Visual VM ile ekran görüntüsü almaya çalışacağım, umarım ss alabilmek için yetişirim :)

package com.mehmetcemyucel;  
  
import java.util.concurrent.ExecutorService;  
import java.util.concurrent.Executors;  
  
public class MainPlatformThread {  
  
    public static void main(String[] args) throws InterruptedException {  
        new MainPlatformThread().run();  
    }  
  
    private void run() throws InterruptedException {  
        printInfo();  
        warmup();  
  
        // Kademeli artış planı — Platform thread'lerde limit daha düşük tutulmalı  
        long[] steps = {1_000L, 5_000L, 10_000L, 25_000L, 50_000L};  
  
        for (long count : steps) {  
            System.out.println("\n=== RUNNING " + count + " TASKS ===");  
            runStep(count);  
            System.gc(); // her adım sonrası GC tetikle  
            Thread.sleep(2000); // JVM'e nefes arası ver  
        }  
  
        System.out.println("\nAll ramped-up steps completed.");  
    }  
  
    private void runStep(long count) {  
        long starttime = System.currentTimeMillis();  
        long memBefore = usedMemoryMB();  
  
        // Her task için 1 OS thread (ağır)  
        try (ExecutorService executor = Executors.newThreadPerTaskExecutor(Thread.ofPlatform().factory())) {  
            for (int i = 0; i < count; i++) {  
                if (i % 1_000 == 0 && i > 0)  
                    System.out.printf("Submitted %d tasks%n", i);  
                executor.submit(() -> {  
                    try {  
                        Thread.sleep(1000); // I/O-bound benzetimi  
                    } catch (InterruptedException e) {  
                        Thread.currentThread().interrupt();  
                    }  
                });  
            }  
        }  
  
        long memAfter = usedMemoryMB();  
        long endtime = System.currentTimeMillis();  
  
        System.out.printf("→ Completed %d tasks | Time: %d ms | Mem before: %d MB | Mem after: %d MB%n",  
                count, (endtime - starttime), memBefore, memAfter);  
    }  
  
    private void warmup() throws InterruptedException {  
        System.out.println("Warmup starting...");  
        try (ExecutorService executor = Executors.newThreadPerTaskExecutor(Thread.ofPlatform().factory())) {  
            for (int i = 0; i < 1_000; i++) { // platform threads ağır, warmup küçük tut  
                executor.submit(() -> {  
                    try {  
                        Thread.sleep(10);  
                    } catch (InterruptedException e) {  
                        Thread.currentThread().interrupt();  
                    }  
                });  
            }  
        }  
        System.out.println("Warmup done.");  
    }  
  
    private static void printInfo() {  
        System.out.println("JVM Details:");  
        System.out.println(System.getProperty("java.vm.name"));  
        System.out.println(System.getProperty("java.version"));  
        System.out.println(System.getProperty("java.vendor"));  
        System.out.println("Available processors: " + Runtime.getRuntime().availableProcessors());  
        System.out.println("Max Memory (MB): " + Runtime.getRuntime().maxMemory() / (1024 * 1024));  
        System.out.println("-----------------------------------");  
    }  
  
    private static long usedMemoryMB() {  
        Runtime rt = Runtime.getRuntime();  
        return (rt.totalMemory() - rt.freeMemory()) / (1024 * 1024);  
    }  
}

Kodumuz çalıştı çıktımız şu şekilde oldu:

JJVM Details:  
OpenJDK 64-Bit Server VM  
24  
Oracle Corporation  
Available processors: 8  
Max Memory (MB): 4096  
-----------------------------------  
Warmup starting...  
Warmup done.  
  
=== RUNNING 1000 TASKS ===  
→ Completed 1,000 tasks | Time: 1063 ms | Mem before: 66 MB | Mem after: 4 MB  
  
=== RUNNING 5000 TASKS ===  
Submitted 1000 tasks  
Submitted 2000 tasks  
Submitted 3000 tasks  
Submitted 4000 tasks  
[3.558s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 2048k, guardsize: 16k, detached.  
[3.558s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-6067"  
Exception in thread "main" java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached  
 at java.base/java.lang.Thread.start0(Native Method)  
 at java.base/java.lang.Thread.start(Thread.java:1417)  
 at java.base/java.lang.System$1.start(System.java:2221)  
 at java.base/java.util.concurrent.ThreadPerTaskExecutor.start(ThreadPerTaskExecutor.java:226)  
 at java.base/java.util.concurrent.ThreadPerTaskExecutor.submit(ThreadPerTaskExecutor.java:264)  
 at java.base/java.util.concurrent.ThreadPerTaskExecutor.submit(ThreadPerTaskExecutor.java:270)  
 at com.mehmetcemyucel.MainPlatformThread.runStep(MainPlatformThread.java:38)  
 at com.mehmetcemyucel.MainPlatformThread.run(MainPlatformThread.java:21)  
 at com.mehmetcemyucel.MainPlatformThread.main(MainPlatformThread.java:9)

Gördüğünüz gibi platform threadlerinde her bir treadin yaratılma maliyeti bizi 4bin civarında thread yaratıldığı anda stack memory anlamında sıkıştırdı, 4GB’lık memory yetersiz kaldı ve daha fazla thread yaratımına çalışılmaya devam edildiği için uygulama crash oldu ve kapandı.

Java Virtual Thread

Bu kez kodda sadece thread yaratımı yapılan yeri aşağıdaki gibi değiştirdik.

Executors.newThreadPerTaskExecutor(Thread.ofPlatform().factory()) _>>  
Executors.newVirtualThreadPerTaskExecutor()

package com.mehmetcemyucel;  
  
import java.util.concurrent.ExecutorService;  
import java.util.concurrent.Executors;  
  
public class MainVirtualThread {  
  
    public static void main(String[] args) throws InterruptedException {  
        new MainVirtualThread().run();  
    }  
  
    private void run() throws InterruptedException {  
        printInfo();  
        warmup();  
  
        // Kademeli artış planı (örnek)  
        long[] steps = {100_000L, 1_000_000L, 5_000_000L, 10_000_000L};  
  
        for (long count : steps) {  
            System.out.println("\n=== RUNNING " + count + " TASKS ===");  
            runStep(count);  
            System.gc(); // her adım sonrası GC tetikle  
            Thread.sleep(2000); // JVM'e nefes arası ver  
        }  
  
        System.out.println("\nAll ramped-up steps completed.");  
    }  
  
    private void runStep(long count) {  
        long starttime = System.currentTimeMillis();  
        long memBefore = usedMemoryMB();  
  
        try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {  
            for (int i = 0; i < count; i++) {  
                if (i % 1_000_000 == 0 && i > 0)  
                    System.out.printf("Submitted %d tasks%n", i);  
                executor.submit(() -> {  
                    try {  
                        Thread.sleep(1000);  
                    } catch (InterruptedException e) {  
                        Thread.currentThread().interrupt();  
                    }  
                });  
            }  
        }  
  
        long memAfter = usedMemoryMB();  
        long endtime = System.currentTimeMillis();  
  
        System.out.printf("→ Completed %d tasks | Time: %d ms | Mem before: %d MB | Mem after: %d MB%n",  
                count, (endtime - starttime), memBefore, memAfter);  
    }  
  
    private void warmup() throws InterruptedException {  
        System.out.println("Warmup starting...");  
        try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {  
            for (int i = 0; i < 10_000; i++) {  
                executor.submit(() -> {  
                    try {  
                        Thread.sleep(10);  
                    } catch (InterruptedException e) {  
                        Thread.currentThread().interrupt();  
                    }  
                });  
            }  
        }  
        System.out.println("Warmup done.");  
    }  
  
    private static void printInfo() {  
        System.out.println("JVM Details:");  
        System.out.println(System.getProperty("java.vm.name"));  
        System.out.println(System.getProperty("java.version"));  
        System.out.println(System.getProperty("java.vendor"));  
        System.out.println("Available processors: " + Runtime.getRuntime().availableProcessors());  
        System.out.println("Max Memory (MB): " + Runtime.getRuntime().maxMemory() / (1024 * 1024));  
        System.out.println("-----------------------------------");  
    }  
  
    private static long usedMemoryMB() {  
        Runtime rt = Runtime.getRuntime();  
        return (rt.totalMemory() - rt.freeMemory()) / (1024 * 1024);  
    }  
}

JVM Details:  
OpenJDK 64-Bit Server VM  
24  
Oracle Corporation  
Available processors: 8  
Max Memory (MB): 4096  
-----------------------------------  
Warmup starting...  
Warmup done.  
  
=== RUNNING 100000 TASKS ===  
→ Completed 100,000 tasks | Time: 1211 ms | Mem before: 37 MB | Mem after: 164 MB  
  
=== RUNNING 1000000 TASKS ===  
→ Completed 1,000,000 tasks | Time: 2374 ms | Mem before: 13 MB | Mem after: 949 MB  
  
=== RUNNING 5000000 TASKS ===  
Submitted 1000000 tasks  
Submitted 2000000 tasks  
Submitted 3000000 tasks  
Submitted 4000000 tasks  
→ Completed 5,000,000 tasks | Time: 11722 ms | Mem before: 19 MB | Mem after: 2393 MB  
  
=== RUNNING 10000000 TASKS ===  
Submitted 1000000 tasks  
Submitted 2000000 tasks  
Submitted 3000000 tasks  
Submitted 4000000 tasks  
Submitted 5000000 tasks  
Submitted 6000000 tasks  
Submitted 7000000 tasks  
Submitted 8000000 tasks  
Submitted 9000000 tasks

Bu kez farkettiğiniz üzere heap space daha aktif. Stack memory’deki ihtiyacın 1MB’dan 1KB civarına düşmesi daha fazla threadin çalışmaya hazır şekilde bekleyebilmesine olanak sağlıyor. Ama farkettiyseniz thread yaratımı için stack memory’nin düştüğünden bahsetmemize rağmen bizi deli gibi şişiren heap memory. Bunun sebebi virtual thread’in metadatasının, scheduling state’i gibi alanların halen heap’te tutuluyor olması. Ki zaten platform threadlerinde 4bin istekte uygulamamız crash olmuşken burada 9milyon threadi uygulamaya yükleyebildik. Ancak Visual VM görüntüsünün sağ alt tarafına baktığımızda 8.4 milyon Virtual Thread(VT) queue’da çalıştırılmak üzere beklemesine rağmen sadece 8 tanesi gerçek OS threadleri üzerinde çalıştırılabiliyor.

Bekleyen VTler memoryi o kadar doldurmuş durumda ki sürekli Garbage Collector(GC) tetikleniyor. Ancak bekleyen nesnelerin hepsi erişilebilir nesneler, bu sebeple GC memory alanı açamıyor, ya da daha doğrusu birkaç byte açabiliyor. Her bir thread 1sn uyuduğu için de saniyede ancak ~8 byte yer açılabiliyor(bu başlangıç alanları daha da yükselebilir, en iyi senaryoyu örnekliyorum). Yani her saniyede yeni thread çalıştırmak için GC’ye mahrum kalınıyor ama bu sırada yeni VT’ler de memory’e yazılmaya devam ediyor.

Bunun tek bir özeti var, hata alıp kapanmıyor çünkü çalışıyor. Ama öyle bir darboğaza girdi ki yaşayacak kadar nefesi ancak alıyor.

Go Goroutines

Go’nun default davranışı bulabildiği memory’i kullanmak üzeredir. Bunu engellemek için Go19+’ta kullanabildiğimiz env değişkeni olarak GOMEMLIMIT=4GiB set ederek koşulları eşitliyoruz. Bu kez go kodumuz aynı mantıkla aşağıdaki gibi;

package main  
  
import (  
 "fmt"  
 "github.com/go-echarts/statsview"  
 "runtime"  
 "runtime/debug"  
 "sync"  
 "time"  
)  
  
func main() {  
 mgr := statsview.New()  
 go mgr.Start()  
  
 printInfo()  
 warmup()  
  
 steps := []int{100_000, 1_000_000, 5_000_000, 10_000_000}  
 for _, count := range steps {  
  fmt.Printf("\n=== RUNNING %d TASKS ===\n", count)  
  runStep(count)  
  runtime.GC()  
  time.Sleep(2 * time.Second)  
 }  
  
 fmt.Println("\nAll ramped-up steps completed.")  
}  
  
func printInfo() {  
 fmt.Println("Go Runtime Details:")  
 fmt.Printf("Version: %s\n", runtime.Version())  
 fmt.Printf("NumCPU: %d\n", runtime.NumCPU())  
 fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))  
 var m runtime.MemStats  
 runtime.ReadMemStats(&m)  
 fmt.Printf("Initial Alloc = %v MB\n", m.Alloc/1024/1024)  
  
 memLimit := debug.SetMemoryLimit(-1) // sadece okur, değiştirmez  
 fmt.Printf("Memory Limit: %.2f MB\n", float64(memLimit)/(1024*1024))  
 fmt.Println("-----------------------------------")  
}  
  
func warmup() {  
 fmt.Println("Warmup starting...")  
 var wg sync.WaitGroup  
 for i := 0; i < 10_000; i++ {  
  wg.Add(1)  
  go func() {  
   defer wg.Done()  
   time.Sleep(10 * time.Millisecond)  
  }()  
 }  
 wg.Wait()  
 fmt.Println("Warmup done.")  
}  
  
func runStep(count int) {  
 var memBefore, memAfter runtime.MemStats  
 runtime.ReadMemStats(&memBefore)  
 start := time.Now()  
  
 var wg sync.WaitGroup  
 for i := 0; i < count; i++ {  
  if i%1_000_000 == 0 && i > 0 {  
   fmt.Printf("Started %d goroutines\n", i)  
  }  
  wg.Add(1)  
  go func() {  
   defer wg.Done()  
   time.Sleep(1 * time.Second)  
  }()  
 }  
 wg.Wait()  
  
 runtime.ReadMemStats(&memAfter)  
 duration := time.Since(start)  
  
 fmt.Printf("→ Completed %d tasks | Time: %v | Mem before: %d MB | Mem after: %d MB\n",  
  count,  
  duration,  
  memBefore.Alloc/1024/1024,  
  memAfter.Alloc/1024/1024,  
 )  
}

Go Runtime Details:  
Version: go1.25.3  
NumCPU: 8  
GOMAXPROCS: 8  
Initial Alloc = 0 MB  
Memory Limit: 4096.00 MB  
-----------------------------------  
Warmup starting...  
Warmup done.  
  
=== RUNNING 100000 TASKS ===  
→ Completed %!,(int=100000)d tasks | Time: 1.298472791s | Mem before: 4 MB | Mem after: 56 MB  
  
=== RUNNING 1000000 TASKS ===  
→ Completed %!,(int=1000000)d tasks | Time: 2.588294292s | Mem before: 46 MB | Mem after: 475 MB  
  
=== RUNNING 5000000 TASKS ===  
Started 1000000 goroutines  
Started 2000000 goroutines  
Started 3000000 goroutines  
Started 4000000 goroutines  
→ Completed %!,(int=5000000)d tasks | Time: 9.01629775s | Mem before: 342 MB | Mem after: 789 MB  
  
=== RUNNING 10000000 TASKS ===  
Started 1000000 goroutines  
Started 2000000 goroutines  
Started 3000000 goroutines  
Started 4000000 goroutines  
Started 5000000 goroutines  
Started 6000000 goroutines  
Started 7000000 goroutines  
Started 8000000 goroutines  
Started 9000000 goroutines  
→ Completed 10000000 tasks | Time: 15.502655416s | Mem before: 671 MB | Mem after: 1166 MB  
  
All ramped-up steps completed.  
  
Process finished with the exit code 0  

Biraz daha zorlamak istedim, acaba 10M isteği 100M yapsam görüntüde ne değişirdi acaba

Go Runtime Details:  
Version: go1.25.3  
NumCPU: 8  
GOMAXPROCS: 8  
Initial Alloc = 0 MB  
Memory Limit: 4096.00 MB  
-----------------------------------  
Warmup starting...  
Warmup done.  
...  
...  
...  
Started 99000000 goroutines  
→ Completed 100000000 tasks | Time: 3m1.683121833s | Mem before: 645 MB | Mem after: 1296 MB  
  
All ramped-up steps completed.  
  
Process finished with the exit code 0

Ne oldu da 100Milyon istek biterken yaklaşık 2GB bir memory kullanımı ile bu işi en ufak tekleme olmadan tamamladı? Aslında bu 2 runtime’ın concurrency modellerinin temel felsefelerinin tamamen farklı olmasından kaynaklı.

Kıyaslama

Detaylarıyla bu kıyaslamayı yapmak gerçekten ayrı bir yazının konusu olabilir. Ama en özet haliyle;

Java VT:

user space’te yönetilen ama os threadlerine 1:1 map edilen thread kullanıyor
Context Switchi JVM OS ile birlikte yapıyor
Bloklu Thread yönetimi OS seviyesinde yapılıyor
GC thread stack taraması heap tabanlı

Go:

user spacete yönetilen M:N mimarisini kullanıyor
Context Switch tamamen runtime’ın kontrolünde
Schedular tüm thread managementı kendisi yapıyor
GC thread stack taraması M tabanlı (P/M/G mimarisi)

En özetle fark Go’nun tamamen concurrency ve performans üzerine bir mimaride odaklanmış mekanizmalara(user-space concurrency engine) sahip iken Java halen eldekileri daha iyi kullanmaya çalışan(managed kernel-level carrier thread abstraction) bir mimaride çalışmaktadır.

Sonraki yazılarda görüşmek üzere.

Mehmet Cem Yücel

Kaynak:
https://wiki.openjdk.org/display/loom/Main

Java'da Aspect Oriented Programming (AOP) ve Decorator Pattern: Adım Adım Örneklerle

Thu, 23 Oct 2025 12:00:00 +0000

Java ve Spring dünyasında Aspect Oriented Programming (AOP) meslekteki ilk yıllarımda bana hep ilginç gelen başlıklardan olmuştu. AOP sayesinde metoda bir annotation ekliyorsun, hop metodun çalışmasından önce ve/veya sonra başka özel bir kod çalışıyor. Bu sıradan bir GOTO gibi değil; o metodun tüm giriş ve çıkış noktalarını kontrol edip gerektiğinde düzenleyebileceğiniz tam tabiri caizse o metodu elinde tutan sihir gibi mekanizma sunuyor. Vay be! Bişiy yaparım ben bunla ki!..

Aspect Oriented Programming

Tabi çalıştığınız şirketteki büyükleriniz eğer izin verirse hemen kolları sıvıyorsunuz. İlk iş loglama! Gelen parametreleri ve dönen response’u debug seviyesinde loglara yansıtacak ilk ASPECT’inizi yazıyorsunuz.

package com.mehmetcemyucel.aspect;  
  
import org.aspectj.lang.ProceedingJoinPoint;  
import org.aspectj.lang.annotation.*;  
import org.springframework.stereotype.Component;  
  
@Aspect  
@Component  
public class LoggingAspect {  
  
    // Pointcut   
    // com.mehmetcemyucel.service paketi altındaki tüm metodlar  
    @Pointcut("execution(* com.mehmetcemyucel.service.*.*(..))")  
    public void serviceMethods() {}  
  
    // Before Advice   
    @Before("serviceMethods()")  
    public void beforeAdvice() {  
        System.out.println("[Before] Metod çağrılmadan önce çalıştı");  
    }  
  
    // After Advice   
    @After("serviceMethods()")  
    public void afterAdvice() {  
        System.out.println("[After] Metod çağrıldıktan sonra çalıştı");  
    }  
  
    // Around Advice   
    @Around("serviceMethods() && args(username)")  
    public Object aroundAdvice(ProceedingJoinPoint pjp, String username) throws Throwable {  
        System.out.println("[Around] Metoddan önce: username = " + username);  
  
        // Parametreyi değiştirebilirsin  
        String modifiedUsername = username.toUpperCase();  
  
        Object result = pjp.proceed(new Object[]{modifiedUsername});  
  
        System.out.println("[Around] Metoddan sonra: username değiştiyse yeni değer = " + modifiedUsername);  
        return result;  
    }  
}

package com.mehmetcemyucel.service;  
  
import org.springframework.stereotype.Service;  
  
@Service  
public class UserService {  
  
    public void createUser(String username) {  
        System.out.println("User created: " + username);  
    }  
  
    public void deleteUser(String username) {  
        System.out.println("User deleted: " + username);  
    }  
}

POINTCUT’larda hangi metotlara uygulayacağınızı söylüyorsunuz (serviceMethods() ile tüm servislere örneğin). JOIN POINT’lerde yani createUser, deleteUser gibi metotlar çağırıldığı noktalarda da ADVICE’larınız yani sihiriniz uygulanmaya başlıyor.

Bugün Fırat’tan gidiyoruz :) Neyse loglama tamam, hadi bir de performans takibi yapalım, metotlar ne kadar sürüyor önemli değil mi? Ya yetkilendirmeye ne demeli? Exception handling? Transaction yönetimi de güzel olurdu değil mi, başladık her yeri yatayda değil dikeyde kesen kodlar ile doldurmaya. He olur mu, olur tabi bir engel yok. Tekrar eden süreçleriniz varsa, tabi buyrun. Ancak kodu yönetebilmeye de devam edebilmelisiniz; izleyebilmeli, müdahale edebilmelisiniz. Show must go on! Ee güzel de bu aletin bu sihri nasıl yaptığını bilmeden yaptığınız bunca şeyin size, kodunuza ve performansa etkisini nasıl öngöreceksiniz? Hadi alın çayınızı kahvenizi, magmaya doğru yola çıkıyoruz!

İhtiyaç

Bir işleve sahip sınıfımız olsun. Bugün kahveler benden:

public class Coffee {  
    public int cost() {  
        return 10;  
    }  
}

Güzel de ben kahvemi sütlü içiyorum diyenleri duyar gibiyim. Tabi bunun maliyete bir yansıması var. 3 lira fazla alacağım ama bunu mevcut bir sınıfın davranışını genişleterek yapmam lazım, bunun için de genelde inheritance yani kalıtım kullanırız:

public class MilkCoffee extends Coffee {  
    public int cost() {  
        return super.cost() + 3;  
    }  
}

İşte halloldu, üst sınıfın costuna gerekli eklemeyi yaptık. Ama bir saniye, karamelsiz içemem diyenleri üzdük! Sanırım Çarşı yavaş yavaş karışıyor çünkü sütlü, karamelli, sütlü karamelli, sade gibi 2^n ihtimal seti kodu şu hale getiriyor:

public class Coffee {  
    public int cost() {  
        return 10;  
    }  
}  
public class MilkCoffee extends Coffee {  
    public int cost() {  
        return super.cost() + 3;  
    }  
}  
public class CaramelCoffee extends Coffee {  
    public int cost() {  
        return super.cost() + 2;  
    }  
}  
public class MilkAndCaramelCoffee extends Coffee {  
    public int cost() {  
        return super.cost() + 5;  
    }  
}

Amacım temel davranışa ufak bir şey eklemekti. Aynı yukarıdaki aspect örneğindeki createUser(..) servisine bir loglama eklemek gibi. Geldiğimiz yer ise kazanımdan uzaklaştı, hele bir de bir farklı bir şurup vs de eklersek kod üstsel olarak büyümeye devam edecek. Peki bunu nasıl ele alacağız?

Decorator Pattern

Normalde inheritance kullandığımızda kombinasyonların nasıl hızlıca sonsuza gittiğini gördük. Kalıtım kullanmadan bir nesnenin davranışını dinamik olarak değiştirmek istiyorsak Decorator güzel bir pattern. Bu dinamikliği de yeni sınıf türetmek yerine mevcut nesneyi başka bir nesne ile sararak gerçekleştiriyor. Temel bileşenleri:

Component(Arayüz): Ortak davranışı tanımlar
ConcreteComponent: Asıl işi yapan sınıf yani yukarıdaki Coffee
Decorator: Component arayüzünü uygulayan ve içinde başka bir Component referansı tutan yer
ConcreteDecorator: İşte tüm bu dinamikliği yöneten yer.

Gelin koddan bakalım:

// Ortak arayüz yani Component  
interface Coffee {  
    int cost();  
    String description();  
}  
  
// Temel sınıf yani ConcreteComponent  
class SimpleCoffee implements Coffee {  
    public int cost() { return 10; }  
    public String description() { return "Basit kahve"; }  
}  
  
// Decorator  
class CoffeeDecorator implements Coffee {  
    protected Coffee decoratedCoffee;  
    public CoffeeDecorator(Coffee coffee) {  
        this.decoratedCoffee = coffee;  
    }  
    public int cost() { return decoratedCoffee.cost(); }  
    public String description() { return decoratedCoffee.description(); }  
}  
  
// Süt eklentisi  
class MilkDecorator extends CoffeeDecorator {  
    public MilkDecorator(Coffee coffee) {  
        super(coffee);  
    }  
    public int cost() { return super.cost() + 3; }  
    public String description() { return super.description() + ", süt"; }  
}  
  
// Karamel eklentisi  
class CaramelDecorator extends CoffeeDecorator {  
    public CaramelDecorator(Coffee coffee) {  
        super(coffee);  
    }  
    public int cost() { return super.cost() + 2; }  
    public String description() { return super.description() + ", karamel"; }  
}

Artık ihtiyacıma göre kahvemi aşağıdaki gibi kurgulayabilirim:

Coffee coffee = new SimpleCoffee();  
coffee = new MilkDecorator(coffee);  
coffee = new CaramelDecorator(coffee);  
  
System.out.println(coffee.description() + " → " + coffee.cost() + "₺");  
  
  
-----------  
Basit kahve, süt, karamel → 15₺

Gerçekten tertemiz kod oldu. Şimdi herkesten kahvelerini nasıl istediğini alabilirim.🙃

Gerçek Hayattan Kesitler

Temel fikri şekerden şerbetten anladığımıza göre gerçek hayat örneğine geçelim:

public class SimpleApp {  
    public static void main(String[] args) {  
        SimpleApp app = new SimpleApp();  
        int val1 = app.generateRandomInt1(10, 1);  
        System.out.printf("generateRandomInt1 Generated value: %d\n\n", val1);  
        ///////////////////////////////  
        int val2 = app.generateRandomInt2(10, 1);  
        System.out.printf("generateRandomInt2 Generated value: %d\n\n", val2);  
        ///////////////////////////////  
        int val3 = app.generateRandomInt3(10, 1);  
        System.out.printf("generateRandomInt3 Generated value: %d\n\n", val3);  
    }  
  
    public int generateRandomInt1(int max, int min) {  
        return ThreadLocalRandom.current().nextInt(min, max + 1);  
    }  
  
    public int generateRandomInt2(int max, int min) {  
        System.out.printf("inbound max: %d, min: %d\n", max, min);  
        int val = ThreadLocalRandom.current().nextInt(min, max + 1);  
        System.out.printf("outbound val: %d\n", val);  
        return val;  
    }  
  
    public int generateRandomInt3(int max, int min) {  
        System.out.printf("inbound max: %d, min: %d\n", max, min);  
        long start = System.nanoTime();  
        int val = ThreadLocalRandom.current().nextInt(min, max + 1);  
        long end = System.nanoTime();  
        long duration = end - start;  
        System.out.printf("Execution time: %d nanoseconds%n", duration);  
        System.out.printf("outbound val: %d\n", val);  
        return val;  
    }  
}

Burada verilen min ve max değerlere göre random değer üreten ve dönen bir generateRandomInt1 metodumuz var, temel davranışı gerçekleştiriyor.

Eğer biz bu metoda bir loglama ekleyelim, metot her çalıştığında gelen değerler ve üretilen değer loglansın istersek kodumuz generateRandomInt2 gibi bir şeye dönüşecek.

Bize yetmez bir de bu metotta ne kadar zaman harcandığını görmek istiyorum derseniz buyrun bir de manzaraya generateRandomInt3 ten bakın…

Tabii ki kimse kodunun bu şekilde olmasını istemez, hele bir de tekrar tekrar aynı davranışı farklı yerlerde kullanabilmeyi istiyorsanız. Gelin Decorator Pattern’i burada uygularsak konu neye evriliyor birlikte bakalım:

public class SimpleApp {  
  
    // Ortak arayüz yani Component  
    public interface RandomIntGenerator {  
        int generateRandomInt(int max, int min);  
    }  
  
    // Temel sınıf yani ConcreteComponent  
    public static class SimpleRandomIntGenerator implements RandomIntGenerator {  
        @Override  
        public int generateRandomInt(int max, int min) {  
            return ThreadLocalRandom.current().nextInt(min, max + 1);  
        }  
    }  
  
    // Decorator  
    public static abstract class RandomIntGeneratorDecorator implements RandomIntGenerator {  
        protected final RandomIntGenerator decoratedGenerator;  
  
        public RandomIntGeneratorDecorator(RandomIntGenerator generator) {  
            this.decoratedGenerator = generator;  
        }  
  
        @Override  
        public int generateRandomInt(int max, int min) {  
            return decoratedGenerator.generateRandomInt(max, min);  
        }  
    }  
  
    // Loglama eklentisi  
    public static class LoggingRandomIntGenerator extends RandomIntGeneratorDecorator {  
  
        public LoggingRandomIntGenerator(RandomIntGenerator generator) {  
            super(generator);  
        }  
  
        @Override  
        public int generateRandomInt(int max, int min) {  
            System.out.printf("inbound max: %d, min: %d%n", max, min);  
            int val = super.generateRandomInt(max, min);  
            System.out.printf("outbound val: %d%n", val);  
            return val;  
        }  
    }  
    // Performans eklentisi  
    public static class TimingRandomIntGenerator extends RandomIntGeneratorDecorator {  
  
        public TimingRandomIntGenerator(RandomIntGenerator generator) {  
            super(generator);  
        }  
  
        @Override  
        public int generateRandomInt(int max, int min) {  
            long start = System.nanoTime();  
            int val = super.generateRandomInt(max, min);  
            long end = System.nanoTime();  
            long duration = end - start;  
            System.out.printf("Execution time: %d nanoseconds%n", duration);  
            return val;  
        }  
    }  
  
    // Ana uygulama  
    public static void main(String[] args) {  
        RandomIntGenerator generator =  
                new TimingRandomIntGenerator(  
                        new LoggingRandomIntGenerator(  
                                new SimpleRandomIntGenerator()  
                        )  
                );  
  
        int val = generator.generateRandomInt(10, 1);  
        System.out.printf("Generated value: %d%n", val);  
    }  
}  
  
  
------------------------------------  
inbound max: 10, min: 1  
outbound val: 1  
Execution time: 35659167 nanoseconds  
  
Generated value: 1

Özellikle main kısmındaki kod dikkatli gözlerden kaçmamıştır diye tahmin ediyorum. Bir yerlerden tanıdık geliyor değil mi:

InputStream in = new BufferedInputStream(new FileInputStream("data.txt"));

Java’da I/O fonksiyonalitelerini kullanmak için InputStream’i nasıl alacağımızı BufferedInputStream ve FileInputStream ile dekore etmişiz. Harika, Decorator mantığını artık tam anlamıyla cebimize koyduk!

Spring Dünyasında Durum, IoC ve DI

Yazı uzadıkça uzuyor ama bu işi anlatmanın temiz başka bir yolu yok! Hadi devam.

IoC, yani Inversion of Control(Kontrolün Tersine Çevrilmesi) yazılımımızda nesnelerin yönetimi, nasıl ilkleneceği vb ile ilgili konuları ele alan bir tasarım prensibi. Normalde bir sınıf bağımlı olduğu diğer sınıfları şu şekilde yaratır:

public class UserService {  
    private UserRepository repo = new UserRepository(); // kendisi oluşturuyor  
  
    public void createUser(String name) {  
        repo.save(name);  
    }  
}

Tabii burada sıkı sıkıya bağımlı(tight coupling) hale geldiğini söylemeye gerek bile yok. Keza farklı bir UserRepository implementasyonu kullanmak ve bu kodu test edebilmek de gerçekçi durmuyor.

IoC prensibinde ise kontrol tersine çevrilir, yani bağımlılığı sınıf yaratmaz. Bu bağımlılık dışarıda yaratılır ve sınıfa iletilir(inject edilir).

public class UserService {  
    private final UserRepository repo;  
  
    // Bağımlılık dışarıdan veriliyor  
    public UserService(UserRepository repo) {  
        this.repo = repo;  
    }  
  
    public void createUser(String name) {  
        repo.save(name);  
    }  
}  
-----------------------------  
  
// Kullanımı da şu şekilde  
UserRepository repo = new UserRepository();  
UserService service = new UserService(repo);

Spring de yukarıdaki hareketi bir IoC Container’ı olarak otomatik yapar. Mülakatlarda hep sorulan DI, yani Dependency Injection(Bağımlılık Enjeksiyonu/Zerki) Spring’in IoC’yi uygulama şeklidir. Örnek kod da şöyle olur:

@Service  
public class UserService {  
    private final UserRepository repo;  
  
    // bu annotationa gerek bile yok,   
    // hatta tamamen kaldırılacağı konuşuluyor ama   
    // eski günlerin hatrına diyelim :)  
    @Autowired   
    public UserService(UserRepository repo) {  
        this.repo = repo;  
    }  
}

Decorator örneğindeki hatırlarsanız nasıl dekore etmek istiyorsak instanceları o şekilde çevreleye çevreleye(wrap) yaratıyorduk. Ee şimdi objelerin yaratımı da Spring’in kontrolünde ise benzer şekilde Spring de aynısını yapabilir değil mi? Cevap: mantık aynı fakat yaklaşım farklı.

Spring Proxy Nesneleri

Spring IoC container’ı bir @Bean oluştururken o nesnede bir AOP referansı olup olmadığını kontrol eder. Yani hepinizin kullandığı @Transactional ,@Cachable , @Around gibi ADVICE’lar(yazının başında anlatmıştık değil mi, bu kadar çabuk unutmayın😆) kullanılacaksa o nesnenin yerine bir Proxy oluşturur. Yani şöyle bir kodumuz olsun:

@Repository  
public class UserRepository {  
    public void createUser(String name) { ... }  
}

ve buna şu şekilde bir **Aspect** tanımlayalım:

@Aspect  
@Component  
public class LoggingAspect {  
    @Before("execution(* com.mehmetcemyucel.UserRepository.*(..))")  
    public void log() {  
        System.out.println("DB'ye kaydediliyor..");  
    }  
}

UserRepositoy ‘e bağımlı olan UserService bean’i aslında direk repository’nin bir instance’ını değil o instance’ı wrapleyen bir Proxy nesnesini servis sınıfına döner. Bu proxy createUser(...) çağrımını yakalar, önce loglama aspectini çalıştırır ve sonra gerçek metodu çağırır. Yani sıralama şuna döner:

client → UserRepositoryProxy → (aspect logic) → real UserRepository

Yeter mi? Yetmez… JDK Dynamic Proxy & CGLIB

Bu kadar geldik, sıkın dişinizi! Size arkadaş ortamında hava atmalık bilgiler veriyorum, yazın kafanıza 😜.

Hani SOLID prensiplerinde D-> Dependency Inversion vardı ya. Üst seviye modüller düşük sebiye modüllere bağımlı olmaması gerekiyordu ve biz bu yüzden direk bağlamak yerine bir interface ile bağlıyorduk. Yani şunu kastediyorum:

public interface UserRepository {  
    void createUser(String name);  
}  
  
public class UserRepositoryPostgre implements UserRepository{  
   ...  
}

İşte bu durumda Spring proxy yaratmak için java.lang.reflect.Proxy sınıfını kullanır ve aşağıdaki gibi bir instance oluşur:

UserRepository proxy = (UserRepository) Proxy.newProxyInstance(  
    classLoader,  
    new Class[]{UserRepository.class},  
    new InvocationHandler() {  
        public Object invoke(Object proxy, Method method, Object[] args) {  
            // Aspect öncesi çalıştırılacak ADVICE  
            Object result = method.invoke(target, args);  
            // Aspect sonrası çalıştırılacak ADVICE  
            return result;  
        }  
    }  
);

Yani metodu intercept etmek için kullandığımız her şey reflection ile yapıldı ve baya direk java kütüphanelerini kullandık. Maliyet minimum, gayet native bir kod, şahane!

Ee peki ya interface’imiz yoksa? İşte orada da Spring CGLIB(Code Generation library) Proxy kullanır. Yani runtime’da hedef sınıfın alt sınıfı hedef sınıfı override edecek şekilde oluşturulur. Yani baya runtime’da bytecode üretilir, bu bytecode memory’e alınır ve çalıştırılır. Tabii ki interface çağırımına göre daha yavaştır ancak korkulacak bir durum yok, bu bizler tarafından hissedilmeyecek kadar düşük bir süre. Ancak ufak bir memory ve cpu usage olacağının da farkında olmak iyidir.

Sonuç

Yaa işte, bir Aspect’in kabaca hikayesi bu şekilde. Aspect dedik tasarım paternlerine zıpladık, Spring dedik IoC, DI, Proxyleme konularına değinmeden geçemedik. Ama artık uçtan uca neler yaşandığını biliyoruz. Daha fazlası için takibi unutmayın, Youtube kanalıma da beklerim.

Kendinize iyi bakın 🤙

Mehmet Cem Yücel

Dependency Inversion Principle (DIP) Nedir? — SOLID'in Beşinci ve Son Adımı

Thu, 27 Feb 2025 12:00:00 +0000

Not: İçeriğin orjinali ve alternatif dağıtımları hakkındaki bilgiler aşağıda paylaşılmıştır.

YouTube (orjinal içerik)
Blog (orjinal içerik temelli AI destekli)
Podcast (orjinal içeriğe ait ses)

“High-level modules should not depend on low-level modules. Both should depend on abstractions.”
— Robert C. Martin

Bu yazıda SOLID prensiplerinin son adımı olan Dependency Inversion Principle (DIP) konusunu inceliyoruz.
Yani: Bağımlılık yönünü tersine çevirerek esnek ve sürdürülebilir bir mimari kurmak.

🧩 DIP Nedir?

Klasik bir sistemde üst seviye (high-level) sınıflar, alt seviye (low-level) sınıflara doğrudan bağımlıdır.
Bu durumda, alt katmandaki bir değişiklik yukarıdaki katmanları da etkiler.

DIP der ki:

Üst seviye modüller, alt seviye modüllere değil, soyutlamalara (interfaces) bağımlı olmalıdır.

⚠️ Sorun: Doğrudan Bağımlılık

class ReportRepository {
    public String generateOrderReport() {
        return "Order Report generated.";
    }
}

class ReportService {
    private final ReportRepository reportRepository;

    public ReportService(ReportRepository reportRepository) {
        this.reportRepository = reportRepository;
    }

    public void printReport() {
        System.out.println(reportRepository.generateOrderReport());
    }
}

Burada ReportService, doğrudan ReportRepository sınıfına bağımlı.
Yarın farklı bir veri kaynağı (örneğin Redis, MongoDB, PostgreSQL) kullanmak istersen, ReportService’i değiştirmek zorundasın.
Bu da DIP ihlali anlamına gelir.

✅ Çözüm: Abstraction (Interface) ile Bağımlılığı Tersine Çevir

DIP’nin temel fikri: Detaylar soyutlamaya bağlı olmalı, soyutlamalar detaya değil.

interface ReportRepository {
    String generateOrderReport();
}

class PostgresReportRepository implements ReportRepository {
    public String generateOrderReport() {
        return "PostgreSQL report generated.";
    }
}

class RedisReportRepository implements ReportRepository {
    public String generateOrderReport() {
        return "Redis report generated.";
    }
}

Ve artık ReportService doğrudan bir sınıfa değil, interface’e bağımlı:

class ReportService {
    private final ReportRepository repository;

    public ReportService(ReportRepository repository) {
        this.repository = repository;
    }

    public void printReport() {
        System.out.println(repository.generateOrderReport());
    }
}

Bu yapı sayesinde ReportService hangi repository’nin kullanıldığını bilmek zorunda değil.
Sadece ReportRepository arayüzünü tanıyor.
Yani bağımlılık yönü tersine çevrilmiş oldu.

🔁 Katmanlı Mimaride DIP

Katmanlı bir mimaride ideal bağımlılık yönü:

Controller  →  Service  →  Interface  ←  Repository Implementation

Servis, doğrudan repository’ye değil, repository interface’ine bağımlıdır.
Repository implementasyonu da bu interface’i uygular.
Böylece iki katman arasındaki bağ zayıf (loosely coupled) hale gelir.

🧠 DIP ve IoC (Inversion of Control)

DIP genellikle IoC (Inversion of Control) ve Dependency Injection (DI) kavramlarıyla birlikte kullanılır.
Örneğin Spring veya Guice gibi frameworkler, bağımlılıkları constructor üzerinden otomatik olarak enjekte eder:

@Service
public class ReportService {
    private final ReportRepository repository;

    @Autowired
    public ReportService(ReportRepository repository) {
        this.repository = repository;
    }
}

Artık hangi repository implementasyonunun kullanılacağına framework karar verir — sen değil.
Bu da sistemin test edilebilirliğini ve esnekliğini büyük ölçüde artırır.

🧱 Gerçek Hayattan Analogi

Bir elektrikli cihazın prize takılan kablosunu düşün.
Cihaz, prizde ne tür bir enerji altyapısı olduğunu bilmez — sadece bir arayüz (interface) üzerinden enerji alır.
Aynı şekilde, sisteminin üst katmanları da alt katmanların detaylarına bağlı olmamalıdır.

🎬 Sonuç ve Serinin Sonu

Bu videoda Dependency Inversion Principle (DIP)’i inceledik.
Yüksek seviyeli modüllerin, düşük seviyeli detaylardan bağımsız olmasının neden hayati olduğunu gördük.

Böylece SOLID prensiplerinin beşini de tamamlamış olduk 🎯
Artık elinizde sürdürülebilir, genişletilebilir ve bakımı kolay sistemler kurmak için güçlü bir temel var.

🎥 Videoyu izlemek istersen:

Interface Segregation Principle (ISP) Nedir? — SOLID'in Dördüncü Adımı

Tue, 18 Feb 2025 12:00:00 +0000

Not: İçeriğin orjinali ve alternatif dağıtımları hakkındaki bilgiler aşağıda paylaşılmıştır.

YouTube (orjinal içerik)
Blog (orjinal içerik temelli AI destekli)
Podcast (orjinal içeriğe ait ses)

“Clients should not be forced to depend upon interfaces that they do not use.”
— Robert C. Martin

Bu yazıda SOLID prensiplerinin dördüncü adımı olan Interface Segregation Principle (ISP) konusunu inceliyoruz.
Yani: Bir sınıf, ihtiyacı olmayan metodları implement etmek zorunda kalmamalıdır.

🧩 ISP Nedir?

Interface Segregation Principle (ISP), yazılımda interfacerin gereğinden fazla sorumluluk almaması gerektiğini söyler.

Eğer bir interface içerisinde farklı ve alakasız davranışlar yer alıyorsa, o interface’i kullanan sınıflar bu davranışları implement etmek zorunda kalır.
Bu da gereksiz bağımlılık yaratır.

⚠️ Klasik Örnek: Tek Bir Dev Interface

interface Order {
    void createOrder();
    void cancelOrder();
}

Şimdi PhysicalOrder ve VirtualOrder sınıflarını ele alalım:

class PhysicalOrder implements Order {
    public void createOrder() { ... }
    public void cancelOrder() { ... }
}

class VirtualOrder implements Order {
    public void createOrder() { ... }
    public void cancelOrder() { 
        throw new UnsupportedOperationException("Virtual orders cannot be cancelled.");
    }
}

Burada VirtualOrder, Order interface’ini tam olarak karşılamıyor çünkü “cancel” davranışına sahip değil.
Yine de interface’te tanımlandığı için implement etmek zorunda kalıyor.
Bu, Interface Segregation Principle ihlalidir.

✅ Doğru Yaklaşım: Küçük ve Odaklı Interface’ler

Davranışları, birbirinden bağımsız küçük interface’lere bölmeliyiz:

interface Creatable {
    void createOrder();
}

interface Cancelable {
    void cancelOrder();
}

Artık her sınıf yalnızca ihtiyaç duyduğu interface’leri implement eder:

class PhysicalOrder implements Creatable, Cancelable {
    public void createOrder() { ... }
    public void cancelOrder() { ... }
}

class VirtualOrder implements Creatable {
    public void createOrder() { ... }
}

Bu yapı sayesinde VirtualOrder, yalnızca oluşturulabilir (Creatable) bir sipariştir,
ama iptal edilemez (Cancelable) bir sipariş değildir.
Kod daha sade, daha doğru ve daha güvenlidir.

🧠 ISP’nin Faydaları

Gereksiz bağımlılıklar ortadan kalkar.
Sınıflar yalnızca kendi işine yarayan davranışları implement eder.
Kod daha esnek, okunabilir ve test edilebilir hale gelir.
Yeni interface eklemek, mevcut yapıyı bozmaz.

🧱 Örnek: E-Ticaret Senaryosu

Bir Order sistemi düşünelim:

Fiziksel siparişler kargolanır ve iptal edilebilir.
Sanal siparişler (örneğin bir hediye kodu), gönderildikten sonra iptal edilemez.

Bu durumda Cancelable davranışını ayırmak doğru yaklaşımdır.

interface Creatable {
    void createOrder();
}

interface Cancelable {
    void cancelOrder();
}

class PhysicalOrder implements Creatable, Cancelable {
    public void createOrder() { System.out.println("Order created."); }
    public void cancelOrder() { System.out.println("Order cancelled."); }
}

class VirtualOrder implements Creatable {
    public void createOrder() { System.out.println("Virtual order created."); }
}

Artık sınıflar yalnızca gerçekten sahip oldukları davranışları uygular.
Gereksiz metotlar yok, UnsupportedOperationException yok.

🎬 Sonuç ve Devam

Bu videoda Interface Segregation Principle (ISP)’yi inceledik.
Bir interface’in çok fazla sorumluluk taşımasının nasıl bağımlılık ve karmaşıklık yarattığını gördük.
Bir sonraki videoda SOLID’in son adımı olan Dependency Inversion Principle (DIP) üzerine konuşacağız.

🎥 Videoyu izlemek istersen:

Liskov Substitution Principle (LSP) Nedir? — SOLID'in Üçüncü Adımı

Tue, 11 Feb 2025 12:00:00 +0000

Not: İçeriğin orjinali ve alternatif dağıtımları hakkındaki bilgiler aşağıda paylaşılmıştır.

YouTube (orjinal içerik)
Blog (orjinal içerik temelli AI destekli)
Podcast (orjinal içeriğe ait ses)

“Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.”
— Barbara Liskov

Bu yazıda, SOLID prensiplerinin üçüncü adımı olan Liskov Substitution Principle (LSP)’yi ele alıyoruz.
Yani: “Child class, parent class’ın yerine geçebilmeli — ve sistemin davranışı bozulmamalı.”

🧩 LSP Nedir?

LSP der ki:

Bir sınıfın alt sınıfı, üst sınıfın sözleşmesini (davranışlarını) tam olarak yerine getirebilmelidir.

Eğer bir child sınıf, parent’ın beklenen davranışını eksik ya da ters şekilde gerçekleştiriyorsa, sistemde tutarsızlık oluşur.

Bunun klasik örneği: Kuş problemi.

class Bird {
    void fly() { ... }
}

class Penguin extends Bird {
    void fly() { throw new UnsupportedOperationException(); }
}

Burada Penguin bir kuştur ama uçmaz.
Dolayısıyla Bird sınıfının fly() davranışını yerine getiremiyor.
Yani Penguin, Bird’ün yerine geçemediği için LSP ihlali meydana geliyor.

🧱 Bizim Örneğimiz: Order Hiyerarşisi

Bir e-ticaret sisteminde Order adında bir sınıf düşünelim.

abstract class Order {
    protected String orderId;
    protected double price;

    abstract void startDelivery();
}

Şimdi iki farklı türde siparişimiz var:

class PhysicalOrder extends Order {
    private double desi;

    void startDelivery() {
        System.out.println("Physical shipment started.");
    }
}

class VirtualOrder extends Order {
    private String code;

    void startDelivery() {
        System.out.println("Virtual delivery started via email or SMS.");
    }
}

Her iki sınıf da startDelivery() metodunu kendi davranışıyla uygun şekilde implemente ediyor.
Yani Order yerine PhysicalOrder veya VirtualOrder kullanıldığında sistemin davranışı değişmiyor.
Bu durumda LSP sağlanmış oluyor.

⚠️ LSP İhlali Ne Zaman Olur?

Eğer alt sınıf, parent’ın beklediği bir davranışı boş geçerse veya desteklemezse, LSP ihlali ortaya çıkar.

class VirtualOrder extends Order {
    void startDelivery() {
        // hiçbir şey yapmıyor
    }
}

Bu durumda VirtualOrder, Order sözleşmesini tam olarak yerine getirmiyor.
Kodun bir yerinde “her order gönderilebilir” beklentisi varsa, VirtualOrder bu beklentiyi kırar.
Yani LSP ihlali.

🧠 Doğru Soyutlama: Interface ile Davranış Ayırımı

Tüm siparişlerin “teslim edilebilir” olması gerekmeyebilir.
Bu durumda interface ayrımı yapabiliriz.

interface Deliverable {
    void startDelivery();
}

class PhysicalOrder extends Order implements Deliverable {
    public void startDelivery() {
        System.out.println("Physical shipment started.");
    }
}

class VirtualOrder extends Order implements Deliverable {
    public void startDelivery() {
        System.out.println("Virtual delivery started via email or SMS.");
    }
}

Artık sadece “teslim edilebilir” sınıflar bu interface’i uygular.
Parent–child ilişkisi doğal, tutarlı ve esnektir.

💡 Pratik İpucu

Eğer bir child sınıfın içinde if (this instanceof ...) veya throw new UnsupportedOperationException() gibi kontroller görüyorsan, LSP’yi ihlal ediyorsundur.
Böyle durumlarda kalıtım yerine interface veya composition (bileşim) kullanmak çok daha sağlıklıdır.

🎬 Sonuç ve Devam

Bu videoda Liskov Substitution Principle (LSP)’yi inceledik.
Kalıtımın yanlış kullanımıyla nasıl gizli hatalar oluşabileceğini gördük.
Bir sonraki videoda Interface Segregation Principle (ISP) konusuna geçeceğiz.

🎥 Videoyu izlemek istersen:

Open/Closed Principle (OCP) Nedir? — SOLID'in İkinci Adımı

Sun, 02 Feb 2025 12:00:00 +0000

Not: İçeriğin orjinali ve alternatif dağıtımları hakkındaki bilgiler aşağıda paylaşılmıştır.

YouTube (orjinal içerik)
Blog (orjinal içerik temelli AI destekli)
Podcast (orjinal içeriğe ait ses)

“Software entities should be open for extension, but closed for modification.”
— Bertrand Meyer

Bu yazıda SOLID prensiplerinin ikinci adımı olan Open/Closed Principle (OCP) konusunu ele alıyoruz.
Kısaca: Kodunuzu değiştirmeden yeni davranışlar ekleyebilmek.

🎯 Hatırlatma: SRP ile Başlamıştık

Önceki yazıda Single Responsibility Principle (SRP)’yi incelemiş, bir e-ticaret sistemi örneği üzerinden kodumuzu tek sorumluluğa sahip sınıflara bölmüştük:

OrderProcessor siparişi yönetiyordu,
InvoiceService faturayı oluşturuyordu,
EmailService bildirim gönderiyordu,
ReportGenerator raporlamayı üstleniyordu.

Ancak bu hâl hâlâ mükemmel değil. Yeni bir iletişim kanalı (örneğin SMS veya Push Notification) eklemek istesek, bazı yerlerde kodu değiştirmemiz gerekir.
İşte OCP burada devreye giriyor.

🧱 OCP Nedir?

Open/Closed Principle, yazılım bileşenlerinin:

Yeni davranışlar eklemeye açık (open for extension),
Mevcut kodu değiştirmeye kapalı (closed for modification)

olması gerektiğini söyler.

Yani yeni bir gereksinim geldiğinde, var olan sınıfı değiştirmek yerine yeni bir sınıf eklemelisin.

⚠️ Sorun: Kodun Değişmesi Gerekiyor

class InvoiceService {
    private final EmailService emailService;

    public InvoiceService(EmailService emailService) {
        this.emailService = emailService;
    }

    public void sendInvoice(Order order) {
        emailService.send(order);
    }
}

Bu haliyle InvoiceService doğrudan EmailService’e bağımlı.
Yarın “SMS gönder” veya “Push Notification gönder” dersen, sendInvoice() metodunu değiştirmek zorundasın.

Kodun içine “if (sms) … else if (push)” gibi koşullar eklemeye başlarsan — OCP ihlal edilir.

✅ Çözüm: Ortak Bir Arayüz (Interface) ile Davranışı Ayırmak

Tüm bildirim servislerinin (email, sms, push) ortak bir davranışı var: Notify etmek.
Bu davranışı soyutlayarak Notifiable adında bir interface tanımlayabiliriz.

interface Notifiable {
    void notify(Order order);
}

Her iletişim kanalı bu interface’i uygular:

class EmailService implements Notifiable {
    public void notify(Order order) {
        System.out.println("Sending Email...");
    }
}

class SMSService implements Notifiable {
    public void notify(Order order) {
        System.out.println("Sending SMS...");
    }
}

class PushNotificationService implements Notifiable {
    public void notify(Order order) {
        System.out.println("Sending Push Notification...");
    }
}

Ve artık InvoiceService yalnızca bu interface’i bilir:

class InvoiceService {
    private final Notifiable notifier;

    public InvoiceService(Notifiable notifier) {
        this.notifier = notifier;
    }

    public void sendInvoice(Order order) {
        notifier.notify(order);
    }
}

Yeni bir bildirim yöntemi eklemek mi istiyorsun?
Yeni bir sınıf oluşturup Notifiable’ı implement etmen yeterli.

Kodun geri kalanına tek satır bile dokunmazsın.

⚙️ Daha Esnek Bir Adım: Strateji Patterni

OCP’nin en güçlü destekçisi Design Patternlerdir.
Burada Strategy Pattern kullanarak hangi bildirim stratejisinin çalışacağını runtime’da belirleyebilirsin.

public class NotificationStrategyFactory {
    public static Notifiable create(String strategyName) {
        try {
            Class<?> clazz = Class.forName(strategyName);
            if (!Notifiable.class.isAssignableFrom(clazz)) {
                throw new IllegalArgumentException("Invalid Notifiable type: " + strategyName);
            }
            return (Notifiable) clazz.getDeclaredConstructor().newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

Ve main metodunda:

public static void main(String[] args) {
    String notifierClass = "com.technicaldebt.SMSService"; // runtime'da alınabilir
    Notifiable notifier = NotificationStrategyFactory.create(notifierClass);
    InvoiceService invoiceService = new InvoiceService(notifier);

    invoiceService.sendInvoice(new Order());
}

Artık hangi bildirimin gönderileceğini kodu değiştirmeden belirleyebilirsin.

Sadece runtime argümanını değiştir:
EmailService → SMSService → PushNotificationService
ve sistem dinamik olarak genişler.

🧠 Tasarım Desenleriyle Bağlantısı

OCP, yazılım mimarisinde değişimden etkilenmeyen esneklik sağlar.
Design pattern’ler bu ilkenin pratik araçlarıdır:

Strategy Pattern: Dinamik davranış seçimi
Factory Pattern: Nesne yaratımında soyutlama
Decorator Pattern: Davranışı genişletme
Observer Pattern: Yeni tepkiler ekleme

Hepsi OCP’nin felsefesini destekler: Var olan kodu değiştirmeden genişletebilmek.

🎬 Sonuç ve Devam

Bu yazıda Open/Closed Principle (OCP)’yi inceledik.
Yeni davranışları mevcut sistemi bozmadan nasıl ekleyebileceğimizi gördük.

Bir sonraki yazıda SOLID’in üçüncü adımı olan Liskov Substitution Principle (LSP) üzerine konuşacağız.

🎥 Videoyu izlemek istersen:

Context Switch Nedir?

Wed, 22 Jan 2025 12:00:00 +0000

Kelime anlamı ‘Bağlam Değiştirme’ olsa da daha anlaşılır haliyle ‘bir işi bırakıp başka bir işe odaklanma’ manasına gelen bu kavram günümüzde gerek insanlar için gerekse CPU’lar için kullanılabilmektedir. Çünkü gün içerisinde her ne kadar aynı anda birden fazla işlem yapabildiğimizi zannetsek de insan beyni de CPU’lar da aynı anda bir işleme odaklı çalışabilmektedir. Bu yanılgıya sebep veren şey ise çok hızlı şekilde bu switchi gerçekleştirebiliyor olmamız olabilir çünkü aynı anda hem omzumuza sıkıştırdığımız telefonla konuşup hem de saatlerce araç kullanabiliyorsunuz öyle değil mi :)

Beynimiz bir konu ile uğraşırken 5 duyu organımızdan gelen uyaranlara ek eski bilgileri hatırlama, bilgiler arasında ilişki kurma ve bağlam yaratma gibi başka fonksiyonları da kullanarak bir output üretir. Bu süreç bağlam dışı uyaranlar tarafından tetiklenmediği sürece maksimum verimle çalışmalarınızı tamamlarsınız. Bu verim dahi günümüzde tartışmalıdır lakin dikkati kaybetme süreleri 2000’li yılların başında dakikalarla ifade edilirken günümüzde teknolojik uyaranların artmasıyla artık saniyelerle ifade ediliyor. Yine de 1 saattir üzerinde uğraştığınız bir bugı çözmenin eşiğine geldiğiniz anda dışarıdan gelen ‘Yemekte ne yiyelim?’ sorusu beyninizin üzerinde çalıştığı bağlamı kenara atacaktır. Aklınızdan geçirdiğiniz yemekler saatin de gelmesiyle parasempatik sinir sisteminizi uyaracak, ağzınız sulanacak, açlık hissiniz tavan yapacak ve mideniz salgı üretimini artırarak kendisine gelecek yemekleri sindirmeye hazır hale gelecek. Artık bug üzerinde geçirdiğiniz 1 saat rafa kalktı, hormonal olarak da tetiklenen vücudunuzun tekrar aynı odağa dönmesi için yemeğin hazırlanması, karnınızın doyması, yükselen şekerinizin tekrar normal seviyelere dönmesi lazım. Bu da tabii ki hemen olabilen bir şey değil.

Her zaman sınavımızı yemekle vermeyebiliriz, bazen gün içerisinde gelen farklı işler de bizi context switchinge sürükleyebilir. Her işin kendi çapında acelesi ve dinamizmi de olabilir. Ancak yapılan araştırmalar şunu gösteriyor ki aynı anda yapılan birden fazla iş hem iş kalitesini düşürmüş hem de totaldeki yapılan işlerin tek tek yapılsa tamamlanacağı süreden daha uzun sürede tamamlanabilmiş. Gerald Weinberg’ın Quality Software Management kitabından aşağıdaki tabloyu paylaşıyorum.

scrum.org

Buradaki en büyük kayıp context switchingden kaynaklanan kayıp. Bir mimarlık öğrencisi olsanız bunu anlaması daha kolay olabilirdi çünkü kocaman bir masanın üzerinde 3 boyutlu modelini yaptığınız bina ödevini kaldırıp başka bir ödevin modelini yapmak önce masayı boşaltmanıza sonra ilk malzemeleri kaldırıp yerine yenilerini açmaya itecekti. Bu tabii ki daha görünür bir switch örneği, çoğunlukla bilgisayar başında çalışan çalışanlar olarak bu maliyetin farkına yeterince varamasak da istatistik bilimi bizi yanıltmıyor. Kendi yönettiğim ekiplerde de yaptığım gözlemler ve ölçümler de switch maliyetinin küçümsenmeyecek etkilerini hep ortaya koydu. Dolayısı ile bazen hızlanmak için yavaşlamak da iyi bir tercih olabilir. Yeter ki doğru planlama ile doğru işleri sırasına koyalım, doğru yerlerde hayır demeyi bilelim ve riski, stresi ve time2market dinamizmini doğru yönetelim öyle değil mi?

Olayın diğer yönü de CPU üzerinde yaşanan context switching konusu. Ama onu burada anlatmaktansa teknik açıdan adım adım ele aldığım videoyu aşağıya bırakıyorum. İlgilenenler göz atabilir.

Sonuç olarak genelde refleks hep değişime mesafeli yaklaşıp var olanı koruma yöneliminde oluyor. Buna ister safe area diyin ister başka bir şey. Ancak içinizi rahatlatmak için omzunuzla kulağınız arasına yerleştirdiğiniz telefonu araç telefonuna bağlayarak konuyu çözüme ulaştırdığınız kanısına varmayın. Kısa süreli bir görüşme riski minimal tutabilir lakin sürekli yaşanan bu multitasking durumu bugün veya yarın, ya kendinize ya da trafikteki başka bir kişiye o zararı vermenize sebebiyet verecek.

En yalın haliyle.

UUID'yi Doğru Kullanıyor Musunuz?

Wed, 15 Jan 2025 12:00:00 +0000

Hepimizin unique bir ID gereksinimi duyduğumuzda sığındığımız güvenilir liman UUID’ler. Peki UUID’nin 7 farklı versiyonu olduğunu ve hepsinin farklı konulara göre özel çözümler sunduğunu biliyor musunuz? Gelin birlikte inceleyelim.

UUID Kırılımları

Type	Version	Description
Timestamp + MAC	`v1` `v2` `v6`	Zaman Damgası + MAC Adresine ek bazı bilgiler
Random	`v4`	Tamamen Gelişigüzel
Namespace	`v3` `v5`	Namespace ve ek bir bilgi ile üretilen hash fonksiyonu örneği
Hybrid	`v7`	Timestamp + Random kombinasyonu

Timestamp + MAC (UUID v1, UUID v2, UUID v6)

Bu versiyonlarda Zaman Damgası kullanılarak bir unique id üretilmeye çalışılır. Nanosaniye seviyesinde bile olsa dünyanın üzerinde herhangi başka bir makinede aynı zamana denk gelebilecek başka bir yaratım söz konusu olabileceği için bu ihtimali azaltmak üzere MAC adresi de eklenerek ihtimal uzayı daraltılır. Farklı versiyonlarda farklı bilgiler daha eklenir, sıralı olarak id yaratımı mümkün olabilir(v6).

Random (UUID v4)

Bu yöntemde herhangi bir input yoktur, doğrudan rastgele olarak UUID yaratımı yapılır. Bu da sıralılık avantajını kaybetmeye sebep olur. Yeterli entropi şartlarında oldukça geniş bir sonuç uzayına sahip olduğu için güvenle kullanılabilir.

Namespace (UUID v3 MD5, UUID v5 SHA-1)

Belirli bir namespace ve verilen ekstra bir input değeri ile birlikte hash fonksiyonlarından geçirilerek üretilen UUID örneğidir. Avantajı, verdiğiniz aynı input değerleri için her zaman aynı output’u üretecektir. Sıralı değildir. Dikkat edilmesi gereken nokta, yeterince geniş bir output uzayına sahipseniz kullanılan hash fonksiyonlarından sebepli verdiğiniz inputlar tahmin edilebilir hale gelecektir. Bu sebeple hassas verilerle UUID üretimi yapılmamalıdır.

Hybrid (UUID v7)

Random ve Timestamp yöntemlerinin kombinasyonu ile UUID üretimini ifade eder. Birçok modern veritabanında bu yöntem kullanılmaktadır.

Ek Detaylar

Aşağıdaki videoda ID, Unique ID, Universally Unique ID kavramlarını ve ayrıca:

UUID Çözüm Uzayı
Entropi
Collision
UUID Versiyonları Detayları
Farklı versiyonların kod örnekleri gibi bir çok ekstra konuyu inceledik. İlgileniyorsanız göz atabilirsiniz.

Sonuç

Farkında olmadan kullanılan hatalı versiyon UUID’ler gerek güvenlik, gerek performans gerek ise sıralılık gibi avantajları ıskalamak açılarından yazılımımızı etkileyecektir. “One Fit Size All” yaklaşımından sıyrılıp ihtiyaca yönelik yöntemi kullanmak her zaman daha doğru bir tercih olacaktır.

En yalın haliyle

Technical Debt

Wed, 01 Jan 2025 12:00:00 +0000

Son paylaşımın ardından yaklaşık 1,5 sene geçti. Bu zamanın çoğunluğu 2 yaşına basmak üzere olan oğlumla geçti diyebilirim. 2025 tekrar bir şeyler paylaşmak için güzel bir zaman. Umarım yeni yıl tüm milletimiz için güzel bir sene olur.

Zamanla birlikte trendler değişti, hayatımız değişti. Hızla değişmeye de devam ediyor, insanların yaşam tarzından tutun da geçimlerini sağlayacakları alanların çeşitliliğine kadar her şey her gün farklılaşıyor. Yeni bir devrim, yapay zeka devrimi, hayatımızı derinden etkileyecek şekilde kapımızda. Bütün bunlar ve daha fazlası hakkında detaylıca konuşma vaktimiz de geldi diyebilirim.

Geçtiğimiz sene başladığım eğitim macerasına bu sene de hız kesmeden devam ederken yeni yılda da teknik bloglamaya devam edeceğim. Asıl yeni haber, zamanla değişen koşullarla birlikte bilgi paylaşımı için artık YouTube platformunu da kullanmaya başlayacağım. “Technical Debt” isminde açtığım kanalda videolarla yine paylaşımlarıma devam edeceğim.

Bu kanalı niçin açtığım, kimlere hitap ettiği, ne tür içerikler olacağı gibi konuları paylaştığım “Niçin Technical Debt” videosuna göz atmak isteyebilirsiniz.

Eğer içerikler hoşunuza giderse birlikte büyüyebilmek için zaten artık ezbere bilinen :) bazı şeyleri sizden rica edeceğim. Ayrıca aktif bir yön çizebilmek için de yorumlarınızla feedbacklerinize ihtiyacım olacak.

Sonraki yazılarda ve videolarda görüşmek üzere.

En yalın haliyle…

Single Responsibility Principle (SRP) Nedir? — SOLID'in İlk Adımı

Sun, 17 Nov 2024 12:00:00 +0000

Not: İçeriğin orjinali ve alternatif dağıtımları hakkındaki bilgiler aşağıda paylaşılmıştır.

YouTube (orjinal içerik)
Blog (orjinal içerik temelli AI destekli)
Podcast (orjinal içeriğe ait ses)

“Bir sınıfın yalnızca tek bir sorumluluğu olmalı.”
— Robert C. Martin (Uncle Bob)

Bu yazıda, SOLID prensiplerinin ilk adımı olan Single Responsibility Principle (SRP) konusunu ele alıyoruz. Yazının ana kaynağı YouTube videosudur. Bu içerik AI destekli olarak YouTube videosu temel alınarak oluşturulmuştur.

Eğer yazılım projelerinde modülerlik, test edilebilirlik ve sürdürülebilirlik hedefliyorsan, bu prensip seni doğrudan ilgilendiriyor.

🎯 SOLID Prensipleri Neden Var?

SOLID prensipleri yazılım geliştirme sürecinde bizi daha düzenli, modüler ve ölçeklenebilir kodlar yazmaya yönlendirir.
Her bir madde, kodun:

Gelişmeye açık, değişime kapalı kalmasını,
Bağımsız bileşenlerden oluşmasını,
Bakımı kolay ve test edilebilir bir yapıya sahip olmasını amaçlar.

Böylece hem tek başına hem de ekiple çalışırken yazdığın kodun ömrü uzar,
hatayı bulmak ve düzeltmek çok daha kolay hale gelir.

🧱 Single Responsibility Principle (SRP) Nedir?

Single Responsibility Principle (SRP), adından da anlaşılacağı üzere her sınıfın tek bir sorumluluğu olmasını söyler.

“Bir sınıfın değişmesi için yalnızca bir nedeni olmalıdır.”

Bu, bir sınıfın yalnızca tek bir iş yapması gerektiği anlamına gelir.
Bu sayede kodun:

Okunabilirliği artar,
Yönetimi kolaylaşır,
Nerede hangi davranışı arayacağını tahmin etmek kolaylaşır.

🧩 Yanlış Uygulama: Her Şeyi Yapan Tek Servis

class OrderService {

    void processOrder() {
        createOrder();
        createInvoice();
        sendEmail();
        generateReport();
    }

    void createOrder() {
        // Sipariş oluşturma işlemleri
    }

    void createInvoice() {
        // Fatura oluşturma işlemleri
    }

    void sendEmail() {
        // E-posta gönderimi
    }

    void generateReport() {
        // Rapor oluşturma işlemleri
    }
}

Bu yapı başlangıçta basit görünse de, zamanla tek bir sınıfa birden fazla sorumluluk yüklediği için:

Kod karmaşıklaşır,
Değişiklik yapmak riskli hale gelir,
Yeni özellikler eklemek mevcut davranışları bozabilir.

✅ Doğru Yaklaşım: Her Sınıfın Tek Bir Sorumluluğu Olmalı

class OrderProcessor {
    void process(Order order) {
        // Siparişi işleme al
    }
}

class InvoiceService {
    void createInvoice(Order order) {
        // Fatura oluşturma işlemleri
    }
}

class EmailService {
    void sendInvoiceEmail(Invoice invoice) {
        // Fatura e-postası gönder
    }
}

class ReportGenerator {
    void generateReport(Order order) {
        // Rapor oluşturma işlemleri
    }
}

Artık:

OrderProcessor sadece sipariş sürecinden,
InvoiceService fatura oluşturma işinden,
EmailService iletişimden,
ReportGenerator raporlamadan sorumlu.

Bu sayede kod:
✔️ Daha okunabilir
✔️ Daha modüler
✔️ Daha kolay test edilebilir hale gelir.

⚙️ Neden Bu Kadar Önemli?

SRP, kodun uzun ömürlü olmasının temelidir.
Bir sınıfa gereğinden fazla sorumluluk yüklersen:

Değişiklik yapmak zorlaşır,
Yeni gereksinimler mevcut davranışları kırar,
Test yazmak zaman alır,
Hatalar gizlenir, bakım maliyeti artar.

Ancak tek sorumluluğa sahip sınıflarla:

✅ Hataları daha hızlı izole edebilirsin
✅ Değişiklikler minimum etkiyle yapılır
✅ Kodun “neden değiştiğini” kolayca takip edebilirsin

🧠 Tasarım Desenleriyle Bağlantısı

SRP uygulandığında tasarım desenlerini (Design Patterns) uygulamak da kolaylaşır.
Örneğin:

Strategy pattern ile email yerine SMS veya push notification geçişini kolaylaştırabilirsin.
Factory pattern ile farklı order tipleri yaratabilirsin.
Observer pattern ile yeni bir “raporlama servisini” sisteme ekleyebilirsin.

Hepsi, temelinde SRP’nin sağladığı modüler yapı sayesinde mümkündür.

🎬 Sonuç ve Devam

Bu videoda SOLID prensiplerinin ilk adımı olan Single Responsibility Principle (SRP)’yi ele aldık.
Bir sonraki bölümde SOLID’in ikinci adımı olan Open/Closed Principle (OCP) üzerinden aynı örnekle devam edeceğiz.

🎥 Videoyu izlemek istersen: