Size daha iyi hizmet sunabilmek için çerezleri kullanıyoruz.
Web sitemizde gezinme deneyiminizi geliştirmek, size kişiselleştirilmiş içerik ve hedefli reklamlar göstermek, web sitesi trafiğimizi analiz etmek ve ziyaretçilerimizin nereden geldiğini anlamak için çerezleri ve diğer izleme teknolojilerini kullanıyoruz.
⚠️
KVKK ve Çerez Politikası Bilgilendirmesi
6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ve Aydınlatma Yükümlülüğü kapsamında; web sitemizin temel fonksiyonlarının çalışabilmesi, veri güvenliğinin sağlanması ve performans analizi yapılabilmesi için zorunlu çerezlerin kullanımı gerekmektedir. Çerez kullanımını reddetmeniz halinde, teknik imkansızlıklar ve veri senkronizasyonu kesintileri nedeniyle web sitemizdeki hizmetlerden yararlanmanız mümkün olmamaktadır. Sitemizdeki içeriklere erişebilmek için çerez kullanımını onaylamanız gerekmektedir.
Behavioral Patterns: Command ve Strategy Desenleri ile İş Mantığını Kapsüllemek
Yazılım mimarisinde sürdürülebilirlik ve esneklik, iş mantığının (business logic) nasıl organize edildiğiyle doğrudan ilintilidir. Karmaşık sistemlerde karar mekanizmaları ile icra mekanizmalarını birbirinden ayırmak, kodun zamanla “spagetti” yapıya dönüşmesini engeller. Bu bağlamda, Gang of Four (GoF) tarafından tanımlanan Command ve Strategy desenleri, davranışsal kalıplar (behavioral patterns) arasında iş mantığını kapsüllemek (encapsulation) için en güçlü araçlardır.
Şekil 1: Behavioral Patterns: Command ve Strategy Desenleri ile İş Mantığını Kapsüllemek.
1. Davranışsal Desenlerin Mimari Rolü
Nesne yönelimli programlamada (OOP), nesneler arası iletişim ve sorumluluk dağılımı kritik öneme sahiptir. Davranışsal desenler, nesnelerin birbirleriyle nasıl etkileşime girdiğini ve sorumlulukların nasıl paylaştırıldığını standardize eder. İş mantığını kapsüllemek, bir algoritmanın veya bir isteğin, onu çağıran yapıdan bağımsız hale getirilmesidir.
2. Command Deseni: İsteklerin Nesneleştirilmesi
Command deseni, bir isteği (request) kendi başına bir nesne haline getirir. Bu dönüşüm; parametrelerin saklanmasını, işlemlerin kuyruğa alınmasını (queuing), günlüklenmesini (logging) ve geri alınabilmesini (undo/redo) sağlar.
Not: Command deseni, GUI butonlarından transaction yönetimine kadar geniş bir yelpazede kullanılır. Özellikle mikroservis mimarilerinde “Saga Pattern” uygulamalarında komutların takibi için temel teşkil eder.
3. Strategy Deseni: Algoritmaların Dinamik Değişimi
Strategy deseni, belirli bir işi yapan algoritma ailesini tanımlar, her birini kapsüller ve bunları birbirinin yerine kullanılabilir hale getirir. Bu desen, istemcinin (client) çalışma zamanında (runtime) hangi stratejiyi kullanacağını seçmesine olanak tanır.
3.1. Ne Zaman Kullanılmalı?
Bir sınıfın içinde çok sayıda if-else veya switch-case bloğu algoritma seçimi yapıyorsa.
Aynı işin farklı varyasyonları (örneğin farklı ödeme yöntemleri, farklı sıkıştırma formatları) mevcutsa.
Her iki desen de kapsülleme ilkesini kullansa da, kullanım amaçları yapısal olarak farklılık gösterir:
Özellik
Command Deseni
Strategy Deseni
Temel Amaç
Bir isteği/eylemi nesneye dönüştürmek.
Bir algoritmanın nasıl yapılacağını değiştirmek.
Odak Noktası
“Ne” yapılacağı (What).
“Nasıl” yapılacağı (How).
Zamanlama
İşlemlerin kuyruğa alınması veya geciktirilmesi mümkündür.
Genellikle o anki işlem için en uygun yöntem seçilir.
İlişki
Invoker ve Receiver arasında de-coupling sağlar.
Context ve Algoritma arasında polimorfik bağ kurur.
5. İleri Seviye Teknikler ve Kütüphane Entegrasyonları
5.1. MediatR ve Command Deseni (.NET)
Modern .NET uygulamalarında Command deseni genellikle MediatR kütüphanesi ile uygulanır. Bu yapı, In-Process Messaging sağlayarak Controller sınıflarının iş mantığından tamamen arınmasını sağlar (CQRS - Command Query Responsibility Segregation).
Lambda ifadelerinin gelişiyle, basit stratejiler için ayrı sınıflar oluşturmak yerine fonksiyonel arayüzler kullanılmaktadır. Bu, kod kalabalığını azaltır (Boilerplate code reduction).
6. İş Mantığını Kapsüllemenin Avantajları
Open/Closed Principle (OCP): Sisteme yeni bir komut veya strateji eklerken mevcut kodu değiştirmeye gerek kalmaz. Sadece yeni bir sınıf eklemek yeterlidir.
Single Responsibility Principle (SRP): Her sınıf sadece kendi işini yapar. Invoker tetiklemeyi, Command yönlendirmeyi, Receiver ise icrayı üstlenir.
Test Edilebilirlik: İş mantığı küçük parçalara bölündüğü için Unit Test yazımı kolaylaşır. Mock nesnelerle bağımlılıklar kolayca simüle edilebilir.
7. Uygulama Notları ve Best Practices
State Management: Command nesneleri, işlemi geri almak için gereken durum bilgisini (state) kendi içlerinde saklamalıdır. Ancak bellek sızıntılarını önlemek için bu geçmişin (history) boyutu sınırlandırılmalıdır.
Generic Interfaces: Strategy deseninde arayüzlerin jenerik yapıda tasarlanması, farklı veri tipleriyle çalışan algoritmaların tek bir kalıptan türetilmesini sağlar.
Dependency Injection: Her iki desen de DI (Bağımlılık Enjeksiyonu) konteynerleri ile mükemmel uyum sağlar. Çalışma zamanında strateji değişikliği için Factory desenleri ile kombine edilebilirler.
Sonuç
Command ve Strategy desenleri, yazılımın evrimleşme sürecinde karşılaşılan katılık (rigidity) ve kırılganlık (fragility) sorunlarına karşı en etkili çözümlerdir. Command, eylemleri birer veri paketine dönüştürerek sistem içinde serbestçe dolaşmalarını sağlarken; Strategy, algoritmik değişkenliği kontrol altına alarak kodun if-else yığınları arasında boğulmasını önler. Bu iki desenin doğru kombinasyonu, teknik borcu (technical debt) minimize eden, yüksek kaliteli ve sürdürülebilir bir mimarinin kapılarını açar.