C# Tasarım Kalıpları: Singleton, Factory ve Strategy Rehberi

Giriş: Tasarım Kalıpları Neden Önemli?

Oyun geliştirme, özellikle Unity ile büyük ve karmaşık projeler üzerinde çalışırken, kodunuzun düzenli, esnek ve sürdürülebilir olması hayati önem taşır. İşte tam bu noktada C# tasarım kalıpları devreye girer. Tasarım kalıpları, yazılım geliştirmede sık karşılaşılan problemlere kanıtlanmış, yeniden kullanılabilir çözümler sunan şablonlardır. Bu kalıpları anlamak ve doğru şekilde uygulamak, hem kod kalitenizi artırır hem de ekip içinde daha kolay anlaşılır bir yapı oluşturmanızı sağlar.

Bu makalede, oyun geliştirme dünyasında sıklıkla kullanılan ve büyük faydalar sağlayan üç temel tasarım kalıbını inceleyeceğiz: Singleton, Factory ve Strategy. Her bir kalıbın ne anlama geldiğini, ne zaman kullanılması gerektiğini ve Unity/C# ortamında nasıl uygulanacağını örnek kodlarla açıklayacağız. Ayrıca, pratik ipuçları, yaygın hatalar ve performans notları ile bilginizi pekiştireceğiz.

Singleton Tasarım Kalıbı

Singleton Nedir?

Singleton, bir sınıfın yalnızca bir örneğinin (instance) olmasını sağlayan ve bu örneğe global bir erişim noktası sunan bir yaratımsal (creational) tasarım kalıbıdır. Genellikle oyun yöneticileri, ses yöneticileri veya veri yöneticileri gibi tekil bir kontrol noktası gerektiren sistemlerde kullanılır.

Ne Zaman Kullanılır?

• Global olarak erişilmesi gereken tek bir kaynak veya servis olduğunda (örn: Oyun Ayarları, Ses Yöneticisi, Veritabanı Bağlantısı).
• Sadece bir örneği olmalı ve bu örneğin ömrü boyunca korunması gerektiğinde (örn: `DontDestroyOnLoad` ile sahne geçişlerinde kalacak bir oyun yöneticisi).

Singleton Uygulaması (Unity İçin)

Unity’de bir Singleton uygulaması genellikle `MonoBehaviour` sınıfından türetilir ve statik bir özellik aracılığıyla örneğine erişim sağlarız. Aşağıdaki örnek, temel bir Singleton yapısını göstermektedir:

using UnityEngine;

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    // Oyun durumunu veya ayarlarını tutan değişkenler
    public int currentScore = 0;
    public bool isPaused = false;

    private void Awake()
    {
        if (Instance != null && Instance != this)
        {
            // Zaten bir örnek varsa, bu yeni nesneyi yok et
            Destroy(gameObject);
        } 
        else 
        {
            // İlk örnek bizsek, kendimizi Instance olarak ayarla
            Instance = this;
            // Sahne değişimlerinde yok olmaması için
            DontDestroyOnLoad(gameObject);
        }
    }

    public void AddScore(int amount)
    {
        currentScore += amount;
        Debug.Log("Current Score: " + currentScore);
    }

    public void TogglePause()
    {
        isPaused = !isPaused;
        Time.timeScale = isPaused ? 0f : 1f;
        Debug.Log("Game Paused: " + isPaused);
    }
}

Bu yapı sayesinde, herhangi bir yerden `GameManager.Instance.AddScore(10);` veya `GameManager.Instance.TogglePause();` gibi komutlarla oyun yöneticisine kolayca erişebiliriz.

Avantajları ve Dezavantajları

• Avantajları: Global erişim noktası sağlar, kaynak kontrolünü kolaylaştırır, tekil nesne yönetimini garanti eder.
• Dezavantajları: Global durum bağımlılığına yol açabilir, test edilebilirliği zorlaştırabilir, çoklu iş parçacıklı (multi-threading) ortamlarda dikkatli kullanılmalıdır, kapsüllemeyi (encapsulation) zayıflatabilir.

Factory Tasarım Kalıbı

Factory Nedir?

Factory (Fabrika) tasarım kalıbı, nesnelerin yaratılma mantığını istemci koddan soyutlayan bir yaratımsal kalıptır. İstemci (client) kodu, doğrudan `new` anahtar kelimesini kullanarak nesne yaratmak yerine, bir fabrika metodunu veya sınıfını kullanarak nesne ister. Fabrika, hangi tür nesnenin yaratılacağına karar verir ve onu döndürür. Bu, esneklik ve genişletilebilirlik sağlar.

Ne Zaman Kullanılır?

• Sisteminizin belirli bir soyutlamadan (interface veya abstract class) türeyen birden fazla somut (concrete) sınıfı olduğunda ve bu sınıfların yaratılma mantığını merkezileştirmek istediğinizde.
• İstemci kodun, yaratılan nesnenin tam sınıf adını bilmesine gerek kalmadan nesne oluşturulması gerektiğinde.
• Yeni nesne türleri eklediğinizde, mevcut istemci kodunu değiştirmek zorunda kalmadan genişletilebilirlik sağlamak istediğinizde.

Factory Uygulaması

Bir düşman üretme senaryosu üzerinden Factory kalıbını inceleyelim. Farklı düşman türleri (Goblin, Orc) oluşturmak istediğimizde bir fabrika kullanabiliriz.

using UnityEngine;

// 1. Düşman arayüzü (Interface)
public interface IEnemy
{
    void Attack();
    void TakeDamage(int amount);
}

// 2. Somut Düşman Sınıfları (Concrete Enemy Classes)
public class Goblin : IEnemy
{
    public void Attack()
    {
        Debug.Log("Goblin attacks with a rusty dagger!");
    }

    public void TakeDamage(int amount)
    {
        Debug.Log("Goblin took " + amount + " damage.");
    }
}

public class Orc : IEnemy
{
    public void Attack()
    {
        Debug.Log("Orc smashes with a club!");
    }

    public void TakeDamage(int amount)
    {
        Debug.Log("Orc took " + amount + " damage.");
    }
}

// 3. Fabrika Sınıfı (Factory Class)
public enum EnemyType { Goblin, Orc }

public class EnemyFactory
{
    public IEnemy CreateEnemy(EnemyType type)
    {
        switch (type)
        {
            case EnemyType.Goblin:
                return new Goblin();
            case EnemyType.Orc:
                return new Orc();
            default:
                throw new System.ArgumentException("Invalid enemy type.");
        }
    }
}

// Kullanım örneği
public class Spawner : MonoBehaviour
{
    void Start()
    {
        EnemyFactory factory = new EnemyFactory();

        IEnemy goblin = factory.CreateEnemy(EnemyType.Goblin);
        goblin.Attack();

        IEnemy orc = factory.CreateEnemy(EnemyType.Orc);
        orc.Attack();
    }
}

Bu örnekte, `Spawner` sınıfı düşmanların nasıl yaratıldığını bilmek zorunda değildir; sadece `EnemyFactory`’den belirli bir türde düşman ister. Yeni bir düşman türü eklediğimizde, sadece `EnemyFactory` sınıfını ve `EnemyType` enum’unu güncellememiz yeterli olur, `Spawner` kodunu değiştirmemize gerek kalmaz.

Avantajları ve Dezavantajları

• Avantajları: Nesne yaratma mantığını merkezileştirir, istemci kodunu somut sınıflardan bağımsız hale getirir, yeni nesne türleri eklemeyi kolaylaştırır (genişletilebilirlik).
• Dezavantajları: Çok fazla sınıf oluşumuna neden olabilir, basit durumlarda gereksiz karmaşıklık yaratabilir.

Strategy Tasarım Kalıbı

Strategy Nedir?

Strategy (Strateji) tasarım kalıbı, bir algoritma ailesini tanımlayan, her algoritmayı ayrı bir sınıf içine kapsülleyen ve onları birbirinin yerine kullanılabilir hale getiren bir davranışsal (behavioral) kalıptır. Bu sayede bir algoritmanın istemciden bağımsız olarak değişmesini sağlar. Bir nesnenin davranışını çalışma zamanında dinamik olarak değiştirmek için kullanılır.

Ne Zaman Kullanılır?

• Bir nesnenin farklı davranışlara sahip olabileceği ve bu davranışların çalışma zamanında değiştirilmesi gerektiği durumlarda (örn: düşman yapay zekası, oyuncu saldırı türleri).
• Aynı algoritmanın farklı varyantları olduğunda ve bu varyantları ayrı ayrı yönetmek istediğinizde.
• Koşullu ifadelerle (`if-else if` veya `switch`) dolu uzun kod bloklarından kaçınmak istediğinizde.

Strategy Uygulaması

Bir oyuncunun veya düşmanın farklı saldırı davranışlarına sahip olabileceği bir senaryoyu ele alalım.

using UnityEngine;

// 1. Strateji arayüzü (Strategy Interface)
public interface IAttackBehavior
{
    void Attack();
}

// 2. Somut Stratejiler (Concrete Strategies)
public class MeleeAttack : IAttackBehavior
{
    public void Attack()
    {
        Debug.Log("Yakın dövüş saldırısı yapıldı!");
        // Yakın dövüş mantığı
    }
}

public class RangedAttack : IAttackBehavior
{
    public void Attack()
    {
        Debug.Log("Menzilli saldırı yapıldı!");
        // Menzilli saldırı mantığı (ok atma, büyü yapma vb.)
    }
}

public class MagicAttack : IAttackBehavior
{
    public void Attack()
    {
        Debug.Log("Büyü saldırısı yapıldı!");
        // Büyü saldırısı mantığı
    }
}

// 3. Bağlam Sınıfı (Context Class)
public class CombatUnit : MonoBehaviour
{
    private IAttackBehavior _attackBehavior;

    public void SetAttackBehavior(IAttackBehavior behavior)
    {
        _attackBehavior = behavior;
    }

    public void PerformAttack()
    {
        if (_attackBehavior != null)
        {
            _attackBehavior.Attack();
        } else {
            Debug.LogWarning("Saldırı davranışı ayarlanmadı!");
        }
    }
}

// Kullanım örneği
public class PlayerController : MonoBehaviour
{
    public CombatUnit playerCombatUnit;

    void Start()
    {
        // Başlangıçta yakın dövüş saldırısı
        playerCombatUnit.SetAttackBehavior(new MeleeAttack());
        playerCombatUnit.PerformAttack();

        // Çalışma zamanında saldırı tipini değiştir
        if (Input.GetKeyDown(KeyCode.Alpha1))
        {
            playerCombatUnit.SetAttackBehavior(new RangedAttack());
            playerCombatUnit.PerformAttack();
        }

        if (Input.GetKeyDown(KeyCode.Alpha2))
        {
            playerCombatUnit.SetAttackBehavior(new MagicAttack());
            playerCombatUnit.PerformAttack();
        }
    }
    
    // Örnek amaçlı, Update içinde SetAttackBehavior çağırmak yerine
    // genellikle bir olay veya durum değişimine bağlı olur.
    void Update() {
        if (Input.GetKeyDown(KeyCode.R)) {
            playerCombatUnit.SetAttackBehavior(new RangedAttack());
            playerCombatUnit.PerformAttack();
        }
    }
}

Bu örnekte, `CombatUnit` sınıfı hangi saldırı stratejisinin kullanıldığını bilmek zorunda değildir; sadece kendisine atanan stratejiyi yürütür. Bu, yeni saldırı türleri eklemeyi veya mevcut olanları değiştirmeyi çok daha kolay hale getirir.

Avantajları ve Dezavantajları

• Avantajları: Davranışları bağımsız olarak değiştirmeyi ve genişletmeyi sağlar, `if-else` karmaşasını azaltır, kodun okunabilirliğini ve sürdürülebilirliğini artırır.
• Dezavantajları: Küçük projelerde gereksiz yere sınıf sayısını artırabilir, arayüz ve strateji sınıfları arasında ekstra iletişim maliyeti getirebilir (genellikle ihmal edilebilir).

Pratik İpuçları

1. Unity’de Singleton ve `DontDestroyOnLoad`

Unity’de Singleton kullanırken, sahne geçişlerinde örneğinizin yok olmasını engellemek için `Awake()` metodunda `DontDestroyOnLoad(gameObject);` kullanmayı unutmayın. Ancak, bu durumun global bağımlılıkları artırabileceğini ve test etmeyi zorlaştırabileceğini aklınızda bulundurun. Modern Unity geliştirme yaklaşımlarında, bazen Singleton yerine bağımlılık enjeksiyonu (dependency injection) veya Scriptable Objects gibi alternatifler tercih edilebilir.

2. Factory ile Nesne Havuzlama (Object Pooling) Entegrasyonu

Oyunlarda sıkça yaratılıp yok edilen nesneler (mermiler, düşmanlar, efektler) performans sorunlarına yol açabilir. Factory kalıbını bir nesne havuzu (Object Pool) ile birleştirmek, bu sorunu çözmek için harika bir yoldur. Fabrikanız, `new` ile yeni bir nesne oluşturmak yerine, önce havuzdan kullanılabilir bir nesne isteyebilir. Eğer havuzda yoksa yeni bir tane oluşturur. Bu, özellikle C# tasarım kalıpları içinde performans odaklı projelerde çok değerlidir.

3. Strategy ile Dinamik Davranış Değişimi

Strategy kalıbı, oyun içi olaylara veya oyuncu seçimlerine göre nesnelerin davranışlarını anında değiştirmek için mükemmeldir. Örneğin, bir düşmanın canı azaldığında ‘kaçma’ stratejisine geçmesi, oyuncunun farklı yetenek ağaçlarından seçtiği becerilere göre farklı saldırı stratejileri uygulaması gibi senaryolarda Strategy kalıbı, kodunuzu çok daha esnek ve yönetilebilir hale getirir.

Yaygın Hatalar ve Çözümleri

Singleton’ın Aşırı Kullanımı: Her şeye Singleton yapmak, kodunuzu global durumla doldurur ve bağımlılıkları artırır. Sadece gerçekten tek bir örneğe ihtiyacınız olduğunda kullanın. Bunun yerine, bağımlılık enjeksiyonu veya basit bir statik sınıfın yeterli olup olmadığını düşünün.

Factory’nin Aşırı Karmaşıklaştırılması: Fabrikanızın çok fazla sorumluluğu üstlenmesine izin vermeyin. Sadece nesne yaratma sorumluluğunu koruyun. Eğer fabrikanız çok büyüyorsa, farklı nesne grupları için ayrı fabrikalar (`Abstract Factory` kalıbı) oluşturmayı düşünebilirsiniz.

Strategy’nin Gereksiz Yere Uygulanması: Davranışlar arasında gerçekten bir çeşitlilik veya çalışma zamanı değişimi ihtiyacı yoksa, Strategy kalıbı fazla karmaşıklık getirebilir. Basit `if-else` yapıları veya doğrudan metod çağrıları yeterli olabilir. Kalıpları sadece ihtiyaç duyduğunuzda kullanın.

Performans ve Optimizasyon Notları

Singleton’da Geç Başlatma (Lazy Initialization): Singleton örneğinizin hemen `Awake()` içinde değil, ilk erişildiğinde oluşturulmasını sağlayarak başlangıç yükünü azaltabilirsiniz. Bu, özellikle Singleton’ın her zaman kullanılmayacağı durumlarda faydalıdır. Ancak, Unity’deki `MonoBehaviour` tabanlı Singleton’lar genellikle `Awake()` içinde başlatılır ve bu da genellikle kabul edilebilir bir yaklaşımdır.

Factory Metodunda Nesne Yaratma Maliyeti: `new` anahtar kelimesiyle sürekli yeni nesneler oluşturmak, özellikle mobil platformlarda veya düşük sistemlerde performans düşüşüne neden olabilir. Yukarıda bahsedildiği gibi, Factory kalıbını nesne havuzlama ile birleştirmek, bu maliyeti büyük ölçüde azaltır. Bu optimizasyon, C# tasarım kalıpları arasında en sık uygulananlardan biridir.

Strategy İçin Hafif Arayüzler: Strategy kalıbında kullanılan arayüzlerin (interface) mümkün olduğunca hafif ve odaklı olmasını sağlayın. Çok fazla metoda sahip karmaşık arayüzler, her somut strateji sınıfının gereksiz metodları uygulamasına neden olabilir, bu da kod kalitesini düşürür.

Sonuç

C# tasarım kalıpları, yazılım mühendisliğinde karşılaşılan yaygın sorunlara zarif ve etkili çözümler sunar. Singleton, Factory ve Strategy kalıpları, Unity projelerinizde daha modüler, esnek ve sürdürülebilir bir kod yapısı oluşturmanıza yardımcı olacak güçlü araçlardır. Bu kalıpları öğrenmek ve doğru yerlerde uygulamak, sadece mevcut projelerinizde değil, gelecekteki tüm yazılım geliştirme serüveninizde size büyük avantajlar sağlayacaktır. Unutmayın, kalıpları körü körüne uygulamak yerine, projenizin özel ihtiyaçlarına göre en uygun çözümü seçmek her zaman en iyisidir.