Yazılım Tasarım Desenleri: Factory, Observer, Strategy Pratik

JetBrains 2026 Developer Ecosystem raporuna göre kurumsal kod tabanlarının %71’inde en az üç GoF (Gang of Four) tasarım deseni aktif olarak kullanılıyor; doğru pattern seçimi bug yoğunluğunu %32 azaltırken yeni mühendisin onboarding süresini %41 kısaltıyor. 2026’da Factory, Observer ve Strategy desenleri özellikle event-driven mimari, modüler monolit ve AI agent orkestrasyonu yaklaşımıyla yeniden popülerleşti. Stack Overflow 2026 Developer Survey’e göre profesyonel geliştiricilerin %68’i en az bir GoF desenini haftalık olarak uyguluyor. Diğer yandan yanlış uygulanan tasarım deseni, overengineering tuzağına düşüp kod karmaşıklığını %58 artırabiliyor; ThoughtWorks Technology Radar Volume 31 raporu “Pattern obsession” başlığı altında bu riski ayrı bir anti-pattern olarak işaretledi.

Bu rehberde Factory, Observer ve Strategy desenlerini gerçek dünya senaryoları, anti-pattern uyarıları, dil idiomatic kalıpları ve 2026 uygulama örnekleriyle inceliyoruz. GitHub’da iluwatar/java-design-patterns reposunun 92.000 yıldızı geçmesi ve Refactoring Guru’nun ayda 4.2 milyon ziyaretçiye ulaşması, desenlerin hâlâ profesyonel literatürün omurgası olduğunu gösteriyor. Hedefimiz “her şeye desen uygulayalım” değil; doğru sorunu doğru desenle çözmektir.

Tasarım Desenleri Neden Hâlâ Önemli?

Gang of Four kitabının 1994’te yayınlanmasının üzerinden 32 yıl geçti, ancak desenlerin çözmeye çalıştığı temel sorunlar (nesne oluşturma, gevşek bağlılık, davranış değiştirilebilirliği, sorumluluk ayrımı) değişmedi. Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides’in orijinal kitabı bugüne kadar 750.000 baskı yaptı; Amazon’da yazılım mühendisliği kategorisinde hâlâ ilk 100’de. Modern dillerin (Kotlin, Swift, Rust, TypeScript) idiomatik kalıpları çoğu deseni daha az kodla ifade ediyor fakat kavramsal model olarak hâlâ vazgeçilmez. Desenler kod yazmaktan çok ekip içinde ortak dildir: “Burayı Strategy ile soyutladım” cümlesi 10 satırlık açıklamanın yerine geçer.

• Yaratıcı (Creational): Factory Method, Abstract Factory, Builder, Singleton, Prototype – nesne yaratımını yönetir.
• Yapısal (Structural): Adapter, Facade, Decorator, Proxy, Composite, Bridge – nesneleri ve sınıfları daha büyük yapılara birleştirir.
• Davranışsal (Behavioral): Observer, Strategy, Command, State, Chain of Responsibility, Iterator – nesneler arası iletişimi ve sorumluluk dağılımını yönetir.
• Eşzamanlılık (Concurrency): Reactor, Active Object, Half-Sync/Half-Async – GoF dışı ama eşit derecede modern.

GoF Desen Kategorileri ve Sıklık Tablosu

Desenlerin sınıflandırılması “ne işe yaradığına” göre yapılır. Refactoring Guru kaynaklı sınıflandırma 23 GoF desenini üç ana kategoriye ayırır. Hangi kategorinin daha sık kullanıldığı; ürün tipine, ekip olgunluğuna ve mimariye bağlıdır. Aşağıdaki tablo, JetBrains 2026 raporu ile GitHub design-patterns konulu repoların commit dağılımının kesişiminden üretildi.

Kategori	Temel Niyet	Popüler Desenler	Kurumsal Kullanım %	Tipik Anti-Pattern
Creational	Nesne yaratımını kontrol etme	Factory, Builder, Singleton	%78	Aşırı Singleton (global state)
Structural	Sınıf/nesne kompozisyonu	Adapter, Facade, Decorator	%64	Facade arkasına kütüphane gizleme zorlaması
Behavioral	Sorumluluk ve iletişim	Observer, Strategy, Command	%82	Tek implementasyonlu Strategy
Concurrency	Eşzamanlı işlem koordinasyonu	Reactor, Active Object	%41	Lock yerine pattern arayışı
Cloud-Native	Dağıtık sistem ihtiyaçları	Circuit Breaker, Saga, CQRS	%56	Her şeye Saga uygulamak

Tabloya göre davranışsal desenler en yaygın kategori; çünkü modern uygulamaların büyük kısmı “kim ne zaman ne yapacak” sorusunu çözer. Cloud-native desenler ise Saga, Outbox, Sidecar, Circuit Breaker gibi yeni nesil kalıpları kapsar ve GoF dışında kalsa da tamamlayıcı niteliktedir. Yapısal desenler kütüphane sınır katmanında (Adapter, Facade) en sık tercih edilirken yaratıcı desenler dependency injection container’larıyla bütünleşerek görünmez hale gelir. Bir kod tabanında her dört kategoriden de örnekler görülmesi sağlıklı bir mimarinin işaretidir; tek kategori baskınsa (örneğin sadece Singleton ve switch-case) takım pattern okuryazarlığı henüz olgunlaşmamış demektir.

Factory Pattern: Nesne Oluşturmayı Soyutlama

Factory deseninin temel niyeti, somut sınıf adını çağrı sahibinden gizleyerek “ne yaratıldığını” değil “ne döndürüldüğünü” görünür yapmaktır. Spring Framework’ün BeanFactory’si, .NET’in IServiceProvider’ı, Symfony’nin ContainerInterface’i ve Node.js NestJS modüllerindeki provider sistemi ticari ölçekte Factory uygulamalarıdır. Doğru kullanımda yeni bir alt tipin eklenmesi tek satır konfigürasyona indirgenir; çağrı yapan kod hiç değişmez. Factory Method tek bir ürün yaratırken Abstract Factory bir ürün ailesini (örneğin macOS button + macOS scroll bar + macOS dropdown) tutarlı şekilde üretir.

Factory, Abstract Factory ve Builder Karşılaştırması

Üç yaratıcı desen sıklıkla karıştırılır. Aralarındaki seçim, ürünün karmaşıklığına ve değişkenlik kaynağına bağlıdır. SourceMaking kaynağına göre kritik soru şudur: “Ne değişir, ürün tipi mi yoksa kurulum adımları mı?”. Aşağıdaki tablo karar çerçevesini özetler.

Boyut	Factory Method	Abstract Factory	Builder
Ürün sayısı	Tek ürün, çoklu alt tip	İlişkili ürün ailesi	Tek karmaşık ürün
Kurulum adımı	Tek adım	Tek adım, çoklu ürün	Çoklu adım
Parametre sayısı	0-3	0-3 her ürün için	4+ (telescoping kaçınma)
İmmutable destek	Orta	Orta	Yüksek (fluent API)
Tipik örnek	ORM, Plugin loader	UI toolkit, DB driver	StringBuilder, HTTP request
Test edilebilirlik	Yüksek (mock factory)	Yüksek (test factory ailesi)	Yüksek (deterministik kurulum)

Pratik kural: ürün tipi değişiyorsa Factory; ürün ailesi değişiyorsa Abstract Factory; yapım adımları değişiyor veya parametre sayısı dördü geçiyorsa Builder doğru tercihtir. Java 21’in record sınıfları ve Kotlin’in named arguments + data class kombinasyonu, basit Builder ihtiyaçlarını dil seviyesinde karşılar; bu durumlarda ayrı Builder sınıfı yazmak overengineering olur.

Observer Pattern: Olay Yayını Mimarisi

Observer deseni, bir subject (yayıncı) nesnesi ile bir veya daha fazla observer (abone) nesnesi arasında bire-çok bağımlılık tanımlar; subject’in durumu değiştiğinde tüm observer’lar otomatik bilgilendirilir. Reactor pattern, Node.js EventEmitter, C#’ın event keyword’ü ve Java’nın PropertyChangeSupport sınıfı Observer’ın modern türevleridir. Reactive Streams (RxJS, Project Reactor, Kotlin Flow) backpressure ekleyerek desenin asenkron versiyonunu sunar. Martin Fowler “Event Collaboration” yazısında klasik Observer ile modern event-driven mimarinin sürekliliğini detaylandırır.

Observer Modern Alternatifleri Karşılaştırması

ThoughtWorks 2026 Technology Radar’a göre Observer pattern, event-driven mikroservis mimarisinde “default” olarak benimsenmiş durumda; ancak ölçek büyüdükçe klasik Observer in-process kalıyor, üzerine Pub/Sub veya Reactive Stream katmanları ekleniyor. Aşağıdaki tablo üç alternatifin sınırlarını netleştirir.

Boyut	Klasik Observer	Pub/Sub (Broker)	Reactive Stream
Coupling	Subject observer’ı bilir	Tamamen decoupled	Decoupled + tip güvenli
Kapsam	In-process	Cross-process / cluster	In-process veya cluster
Backpressure	Yok	Broker’a göre değişir	Yerleşik (request-n)
Persistence	Yok	Var (Kafka, NATS JetStream)	Opsiyonel
Tipik araç	EventEmitter, C# event	Kafka, RabbitMQ, NATS, SNS	RxJS, Project Reactor, Kotlin Flow
Kullanım senaryosu	UI tepkileri, in-app callback	Mikroservis entegrasyonu	Stream işleme, UI state

Pratik kural: tek process içinde kalan tepki zincirleri için Observer veya Reactive Stream; servisler arası asenkron iletişim için Pub/Sub broker tercih edilmelidir. Aynı sistemde her üçü birlikte yaşar; örneğin Kafka’dan gelen event Reactive Stream’e dönüşüp UI içinde Observer ile dinlenebilir. Kurumsal projelerde sık karşılaşılan hata, in-process bir tepki için Kafka topic’i kullanmak veya basit UI olayını broker’a göndermektir; bu yanlış katman seçimi gereksiz latency, ek operasyonel yük ve borçlanılan operasyon ekibi anlamına gelir. Ölçek küçükken Observer ile başla, scope büyüyünce Pub/Sub’a geç.

Strategy Pattern: Algoritmaları Değiştirilebilir Kılma

Strategy deseni, bir algoritma ailesini tanımlar, her birini ayrı sınıfa alır ve birbiriyle değiştirilebilir hale getirir. Context sınıfı algoritmaya referans tutar; if/switch yerleştirmek yerine doğru strategy’i çalışma zamanında seçer. Ödeme akışları (kart, havale, kripto, BNPL), kargo yöntemleri, sıkıştırma algoritmaları, dil-spesifik formatter’lar ve fiyatlandırma kuralları kanonik Strategy örnekleridir. Doğru uygulamada yeni bir strateji eklemek tek bir sınıf yazmak ve DI container’a kaydetmek anlamına gelir; context sınıfı asla değişmez.

1. Algoritmanın değişen kısmını bir arayüzde izole edin (örnek: PaymentStrategy.calculate()).
2. Her somut algoritmayı ayrı sınıf olarak yazın; bağımlılık container’ı kullanarak çalışma zamanında inject edin.
3. Context sınıfında if/switch zinciri yerine strategy referansı tutun; Open-Closed Principle ihlallerini engelleyin.
4. Strategy seçimini dış konfigürasyona (feature flag, kullanıcı segmenti, A/B test variant) bağlayın; deploy gerektirmeden deneyim mümkün olsun.
5. Unit test her strategy’i izole olarak test edin; context yalnızca doğru strategy’nin çağrıldığını doğrulasın.
6. Eğer üç aydan fazla tek strateji kullanılıyorsa interface’i geri kaldırın; YAGNI ihlali engellenir.

Strategy ve State Pattern Ayrımı

UML diyagramı neredeyse aynı olan iki desen geliştiriciyi en çok şaşırtanlardandır. Ayrım yapı değil niyettir: Strategy “ne yapacağım?” sorusunu dışsal seçimle, State “şimdi hangi modda olduğumu?” sorusunu içsel geçişle yanıtlar. Aşağıdaki karşılaştırma karar verirken yararlı olur.

Boyut	Strategy	State
Seçim kaynağı	Dışsal (kullanıcı, config, A/B test)	İçsel (nesnenin mevcut durumu)
Geçişler	Tek seferlik enjeksiyon	State içinden başka State’e geçiş
Tarihçe	Önemsiz	Önemli (PENDING’den PAID’e doğru sıra)
Strateji bilinçliliği	Birbirinden habersiz	State’ler genelde komşularını bilir
Tipik örnek	Ödeme yöntemi, sıkıştırma	Sipariş yaşam döngüsü, yetkilendirme akışı
Karmaşıklık eşiği	3+ algoritma	3+ durum geçiş matrisi

Dil Bazlı Idiomatic Pattern Uygulamaları

Modern programlama dillerinde “Java vari” pattern uygulaması artık ideal değildir; her dilin idiomatik karşılıkları vardır. Python’da first-class function ve duck typing, Java’da functional interface, C#’ta delegate, TypeScript’te discriminated union sayesinde aynı niyet çok daha az kodla ifade edilir.

Desen	Python Idiomatic	Java 21 Idiomatic	C# .NET 9 Idiomatic	TypeScript Idiomatic
Strategy	Callable + Protocol	Functional interface + lambda	Func delegate	Type alias + arrow function
Factory	__init_subclass__ registry	Sealed interface + switch	Generic factory + DI	Discriminated union + factory fn
Observer	asyncio.Queue, async generator	java.util.concurrent.Flow	IObservable + Rx.NET	RxJS Subject, EventEmitter
Singleton	Module-level değişken	Enum singleton	DI container singleton lifetime	Module pattern + closure
State	Enum + dict dispatch	Sealed class + pattern match	Record + switch expression	Discriminated union + exhaustive check

Pratik sonuç: GoF deseninin niyetini anlayın ama dilin verdiği araçları kullanın. Python’da AbstractStrategy ABC’sini yazıp on satırlık alt sınıflara bölmek, yerine basit callable’ı dict’te tutmaktan daha kötü bir tasarımdır. ThoughtWorks Tech Radar‘ın Volume 31 raporundaki “pattern over-application” uyarısı tam olarak buna işaret eder; rapor 2025 ve 2026 yıllarında bu anti-pattern’i ısrarla işaretlemeye devam etti. Kotlin’in functional interface’leri (fun interface) ile single abstract method patterns’ları çağrılabilir hale getirmesi, ya da Rust’ın trait object + closure kombinasyonu, Java’nın eski “interface + 10 satır anonim class” çözümünden hem daha okunaklı hem daha az kod üretir. Karar verirken sorulacak soru her zaman aynıdır: “Bu abstraction olmadan kod hâlâ okunabilir mi?” Eğer cevap evetse pattern eklemeyin.

Modern Mimarilerde Desen Kombinasyonları

Tek desen nadiren tek başına çözer; gerçek kurumsal kod tabanlarında desenler birbirini tamamlar. Spring uygulamalarında Factory + Strategy + Observer üçlüsü en yaygın kombinasyondur: ödeme akışında PaymentStrategyFactory uygun stratejiyi seçer, strateji yürütülür ve PaymentEventPublisher abonelere bildirim yapar. Domain-Driven Design yaklaşımında Repository Factory ile, Specification ise Strategy’nin filtreleme alt türü olarak kullanılır. CQRS mimarisinde Command desenle yazma işlemleri ayrılırken, Query tarafında Observer event sourcing’i besler.

• Spring DI container: Bean tanımıyla Factory ve Strategy aynı anda sağlanır; @Qualifier annotation ile strategy seçimi run-time bağlanır.
• DDD aggregate ile Repository: Repository Pattern + Specification kombinasyonu sorgu mantığını encapsulate eder.
• CQRS + Event Sourcing: Command pattern ile değişimler kaydedilir, Observer ile projeksiyonlar güncellenir.
• Hexagonal Architecture: Port ve Adapter ikilisi, Strategy desenin yapısal varyantıdır; dış sistemler context’in stratejisi haline gelir.
• AI Agent orkestrasyonu: ReAct ve Plan-and-Execute akışları Chain of Responsibility + Strategy bileşimidir; her tool çağrısı bir strategy seçimi gibidir.

Anti-Pattern Uyarıları ve Overengineering Maliyeti

Tasarım desenlerinin yanlış kullanımı, doğru kullanımdan daha pahalıdır. Robert C. Martin’in Clean Code perspektifine göre üç tipik anti-pattern öne çıkar: gereksiz Singleton (global state kötülüğü), tek implementasyonlu Strategy (abstraction lüksü) ve unsubscribe edilmeyen Observer (bellek sızıntısı). DataDog 2026 production telemetrisine göre Java uygulamalarında bellek sızıntılarının %19’u observer listener’larının temizlenmemesinden kaynaklanıyor. Doğru uygulanan desen yatırımı 6-9 ayda amorti olur; yanlış uygulanan ise teknik borca dönüşerek 18 ay içinde kod tabanını yavaşlatır. Refactoring stratejisi doğru pattern eklemekle aşırı pattern temizliği arasında denge kurar.

Anti-Pattern	Tipik Belirti	Maliyet	Sağaltma
Tek-strateji Strategy	StrategyXImpl tek somut sınıf	Test kompleksitesi +%30	Interface’i kaldır, sınıfı direkt kullan
Singleton spam	Her servis static instance	Test mockability %40 düşer	DI container, scoped lifetime
Aboneliği unutulan Observer	Detach çağrılmıyor	JVM heap %19 sızıntı oranı	WeakReference, try-with-resources
God Factory	500+ satır switch-case	Yeni tip ekleme süresi 4x	Registry + auto-discovery
Decorator zinciri	15+ wrapper, debug imkansız	Mean time to debug %200 artar	Composition root sadeleştirme
Premature Visitor	İki ziyaretçi için 8 sınıf	Ekip onboarding +2 hafta	Pattern matching + sealed type

Karar kuralı: “İkinci uygulama gelene kadar abstraction yazma” (Rule of Three). İlk implementasyonda hard-coded çözüm kabul edilebilir; ikincisinde tekrar ortaya çıkarsa pattern’i çıkarın. Bu yaklaşım, Sandi Metz’in Practical Object-Oriented Design kitabında ve kod kalitesi metrikleri rehberinde teknik borcu en az tutan stratejidir.

Test Edilebilirlik ve SOLID İlkeleri

Tasarım desenlerinin asıl katkısı test edilebilirliği artırmasıdır. Strategy ve Factory dependency injection ile birleştiğinde test sırasında mock implementasyon vermeyi kolaylaştırır. Observer pattern asenkron davranışı test ederken event yakalama yardımcılarıyla doğrulamayı sadeleştirir. SOLID prensiplerinden Open-Closed Principle (OCP) ve Dependency Inversion (DIP), bu üç desenin doğal olarak desteklediği ilkelerdir. JetBrains 2026 raporuna göre OCP uyumlu modüllerde test kapsamı ortalaması %78, ihlal eden modüllerde %52.

• Constructor injection: Strategy seçimi test sırasında mock ile sağlanır; hard-coded factory çağrıları test bağımlılığı yaratmaz.
• Test doubles ayrımı: stub (sabit dönen), mock (çağrı doğrulayan), fake (basit gerçek implementasyon) ve spy (gerçek + kayıt) ayrımı net olmalı.
• Property-based testing: Strategy implementasyonlarının kontratını invariant’larla doğrular; QuickCheck, Hypothesis, FsCheck kütüphaneleri standart.
• Contract test: Aynı interface’i implemente eden tüm Strategy’ler için ortak test paketi, polimorfizmin doğru çalıştığını garantiler.

Sık Sorulan Sorular

Sonuç

Yazılım tasarım desenleri 2026’da hâlâ kurumsal kod tabanının iskeletidir, ancak araç değil dildir. Factory soyutlamayı, Observer gevşek bağlılığı, Strategy davranış değişebilirliğini sağlar; üç desen birleştiğinde modern event-driven mimarinin %80’i çözülür. Pragmatik benimseme verdikti şudur: ihtiyaç doğmadan abstraction yazma, ikinci uygulama gelince pattern’i çıkar, üç ay sonra hâlâ tek strategy varsa interface’i kaldır. Doğru ve ölçülü uygulama bug yoğunluğunu %32 azaltır ve onboarding süresini %41 kısaltır; aşırı kullanım ise overengineering tuzağıdır. Disiplinli tercih ve anti-pattern farkındalığı, sürdürülebilir mimarinin temelidir.