Yazılım Dünyasında Tasarım Desenleri: C ve Go Örnekleriyle Kapsamlı Bir İnceleme

Giriş

• Bu Makalenin Amacı: Bu makale, tasarım desenlerini nihai çözüm olarak övmek amacıyla yazılmamıştır. Bunun yerine, özellikle C ve Go bağlamında tasarım desenlerinin zorluklarını ve sınırlamalarını açıklamayı hedeflemektedir. Bu dillerde neden birçok geleneksel desenin gereksiz hatta zararlı olabileceğini inceleyeceğiz.
• Tanım ve Bağlam: Tasarım desenleri, yazılım geliştirme süreçlerinde karşılaşılan ortak problemlere yönelik, tekrar kullanılabilir çözüm şablonlarıdır. Ancak, değerleri ve uygulanabilirlikleri farklı programlama dilleri ve paradigmalar arasında önemli ölçüde değişiklik gösterir.
• Tarihçesi ve Gang of Four (GoF): Tasarım desenleri, 1994 yılında Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides tarafından yazılan “Design Patterns: Elements of Reusable Object-Oriented Software” kitabıyla popüler hale gelmiştir. Bu dört yazar, “Gang of Four” olarak bilinir. Bu kitap Java gibi nesne yönelimli diller için çığır açıcı olsa da, desenleri her zaman diğer dillere iyi bir şekilde çevrilemez.
• Neden Tasarım Desenlerini Tartışıyoruz? Tasarım desenlerini anlamak önemlidir, ancak ne zaman kullanılmaması gerektiğini bilmek de aynı derecede önemlidir. C ve Go’da, nesne yönelimli dillerde tasarım desenlerinin çözdüğü birçok problem, dillerin kendi özellikleri kullanılarak daha zarif bir şekilde çözülebilir.

Go’da Tasarım Desenlerine Alternatif Yaklaşımlar

Go dili, klasik tasarım desenlerinden farklı bir yaklaşım sunar. Go’nun tasarım felsefesi şu prensiplere dayanır:

1. Composition over Inheritance:

   • Go’da inheritance yerine composition tercih edilir
   • Interface’ler implicit olarak implement edilir
   • Bu yaklaşım, birçok klasik tasarım desenine olan ihtiyacı ortadan kaldırır

2. Concurrency First:

   • Go’nun concurrency modeli (goroutines ve channels) birçok tasarım desenine alternatif sunar
   • Örneğin, Observer pattern yerine channels kullanılabilir
   • Singleton yerine package-level değişkenler ve sync.Once kullanılabilir

3. Simple is Better:

   • Go, karmaşık tasarım desenleri yerine basit ve anlaşılır çözümleri tercih eder
   • Birçok durumda, klasik tasarım desenleri Go’da “anti-pattern” olarak değerlendirilir

4. Idiomatic Go:

   • Go’da doğru yaklaşım, dilin kendi özelliklerini ve best practice’lerini kullanmaktır
   • Örneğin, Singleton pattern yerine package-level değişkenler ve sync.Once kullanmak
   • Observer pattern yerine channels kullanmak
   • Factory pattern yerine constructor functions kullanmak

Bu yaklaşım, Go’nun “less is more” felsefesine uygun olarak, kodun daha basit, anlaşılır ve maintainable olmasını sağlar.

Tasarım Desenleri Kategorileri

1. Yaratımsal (Creational) Desenler: Nesne oluşturma süreçlerini yönetir. Örnekler: Singleton, Factory Method, Builder.
2. Yapısal (Structural) Desenler: Nesnelerin yapısını ve ilişkilerini düzenler. Örnekler: Adapter, Decorator, Composite.
3. Davranışsal (Behavioral) Desenler: Nesneler arasındaki iletişimi ve sorumlulukları yönetir. Örnekler: Observer, Strategy, Command.

Popüler Tasarım Desenleri ve Örnekleri

Yaratımsal Desenler

• Singleton Pattern: Bir sınıfın yalnızca bir örneğinin olmasını sağlar ve bu örneğe global bir erişim noktası sunar.
• Factory Method Pattern: Nesne oluşturma işlemini alt sınıflara bırakır. Hangi sınıfın oluşturulacağına alt sınıflar karar verir.
• Builder Pattern: Karmaşık nesnelerin oluşturulmasını adım adım yönetir.

Yapısal Desenler

• Adapter Pattern: Bir arayüzü, beklenen başka bir arayüze dönüştürür. Böylece uyumsuz arayüzlere sahip sınıflar birlikte çalışabilir.
• Decorator Pattern: Nesnelere dinamik olarak yeni sorumluluklar ekler.
• Composite Pattern: Nesneleri ağaç yapısında düzenler.

Davranışsal Desenler

• Observer Pattern: Bir nesnede değişiklik olduğunda, bu değişiklikten haberdar olması gereken diğer nesnelere otomatik olarak bildirim gönderir.
• Strategy Pattern: Algoritmaları aileler halinde tanımlar ve her birini kapsüller.
• Command Pattern: İstekleri nesne olarak kapsüller.

Tasarım Desenlerinin Avantajları ve Dezavantajları

• Avantajlar: Kodun okunabilirliğini, sürdürülebilirliğini ve yeniden kullanılabilirliğini artırır.
• Dezavantajlar: Karmaşık yapılar oluşturabilir ve öğrenme eğrisi yüksek olabilir.

Modern Yazılım Geliştirmede Tasarım Desenleri

• Mikroservis Mimarisinde Desenler: Mikroservis mimarisinde, tasarım desenleri, servisler arasındaki iletişimi ve sorumlulukları yönetmek için kullanılır.
• Fonksiyonel Programlamada Desenler: Fonksiyonel programlamada, tasarım desenleri, fonksiyonlar arasındaki ilişkileri ve sorumlulukları yönetmek için kullanılır.

Eleştiriler ve Sınırlamalar

• Aşırı Kullanım ve Yanlış Uygulama: Tasarım desenleri aşırı kullanıldığında gereksiz karmaşıklığa yol açabilir.
• Öğrenme Eğrisi: Tasarım desenlerini anlamak ve uygulamak önemli deneyim ve bilgi gerektirir.
• Modern Alternatifler: Bazı modern programlama paradigmaları, geleneksel tasarım desenlerine alternatifler sunar.

Gerçek Dünya Uygulamaları

• Vaka Çalışmaları: Popüler yazılım projelerinde tasarım desenlerinin örnekleri.
• Performans Değerlendirmeleri: Tasarım desenlerinin performans ve bellek kullanımı üzerindeki etkisi.
• En İyi Uygulamalar: Tasarım desenlerinin ne zaman ve nasıl etkili bir şekilde kullanılacağına dair yönergeler.

1. Singleton Deseni

Amaç: Bir sınıfın yalnızca bir örneğinin olmasını sağlar ve bu örneğe global bir erişim noktası sunar.

C ile Singleton

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

#include <stdio.h>

typedef struct {
    int data;
} Singleton;

Singleton* getInstance() {
    static Singleton instance;
    return &instance;
}

int main() {
    Singleton* s1 = getInstance();
    s1->data = 42;
    Singleton* s2 = getInstance();
    printf("%d\n", s2->data); // 42
    return 0;
}

Go ile Singleton (Idiomatic Yaklaşım)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package main
import (
    "fmt"
    "sync"
)

type singleton struct {
    data int
}

var (
    instance *singleton
    once     sync.Once
)

func getInstance() *singleton {
    once.Do(func() {
        instance = &singleton{}
    })
    return instance
}

func main() {
    s1 := getInstance()
    s1.data = 42
    s2 := getInstance()
    fmt.Println(s2.data) // 42
}

2. Factory (Fabrika) Deseni

Amaç: Nesne oluşturma işlemini alt sınıflara bırakır. Hangi sınıfın oluşturulacağına alt sınıflar karar verir.

C ile Factory

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

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

typedef struct {
    void (*speak)();
} Animal;

void dogSpeak() { printf("Hav!\n"); }
void catSpeak() { printf("Miyav!\n"); }

Animal* createAnimal(const char* type) {
    Animal* a = malloc(sizeof(Animal));
    if (strcmp(type, "dog") == 0) a->speak = dogSpeak;
    else a->speak = catSpeak;
    return a;
}

int main() {
    Animal* dog = createAnimal("dog");
    dog->speak();
    Animal* cat = createAnimal("cat");
    cat->speak();
    free(dog); free(cat);
    return 0;
}

Go ile Factory (Idiomatic Yaklaşım)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package main
import "fmt"

type Animal interface {
    Speak()
}

type Dog struct{}
func (d Dog) Speak() { fmt.Println("Hav!") }

type Cat struct{}
func (c Cat) Speak() { fmt.Println("Miyav!") }

// Constructor function - Go'nun idiomatik yaklaşımı
func NewAnimal(kind string) Animal {
    switch kind {
    case "dog":
        return Dog{}
    case "cat":
        return Cat{}
    default:
        return nil
    }
}

func main() {
    dog := NewAnimal("dog")
    dog.Speak()
    cat := NewAnimal("cat")
    cat.Speak()
}

3. Observer (Gözlemci) Deseni

Amaç: Bir nesnede değişiklik olduğunda, bu değişiklikten haberdar olması gereken diğer nesnelere otomatik olarak bildirim gönderir.

C ile Observer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <stdio.h>
#define MAX_OBSERVERS 10

typedef void (*ObserverFunc)(int);

ObserverFunc observers[MAX_OBSERVERS];
int observer_count = 0;

void attach(ObserverFunc obs) {
    observers[observer_count++] = obs;
}

void notify(int data) {
    for (int i = 0; i < observer_count; ++i) {
        observers[i](data);
    }
}

void observer1(int data) { printf("Observer1: %d\n", data); }
void observer2(int data) { printf("Observer2: %d\n", data); }

int main() {
    attach(observer1);
    attach(observer2);
    notify(42);
    return 0;
}

Go ile Observer (Idiomatic Yaklaşım)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package main
import "fmt"

// Go'da Observer pattern yerine channels kullanımı
func main() {
    // Channel oluştur
    updates := make(chan int)
    
    // Observer 1
    go func() {
        for update := range updates {
            fmt.Printf("Observer1: %d\n", update)
        }
    }()
    
    // Observer 2
    go func() {
        for update := range updates {
            fmt.Printf("Observer2: %d\n", update)
        }
    }()
    
    // Değişiklik bildirimi
    updates <- 42
    close(updates)
}

4. Adapter (Uyarlayıcı) Deseni

Amaç: Bir arayüzü, beklenen başka bir arayüze dönüştürür. Böylece uyumsuz arayüzlere sahip sınıflar birlikte çalışabilir.

C ile Adapter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#include <stdio.h>

typedef struct {
    void (*request)();
} Target;

void specificRequest() { printf("Özel istek!\n"); }

void adapterRequest() { specificRequest(); }

int main() {
    Target t;
    t.request = adapterRequest;
    t.request();
    return 0;
}

Go ile Adapter (Idiomatic Yaklaşım)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package main
import "fmt"

// Target interface
type Target interface {
    Request()
}

// Adaptee
type Adaptee struct{}
func (a Adaptee) SpecificRequest() { fmt.Println("Özel istek!") }

// Adapter
type Adapter struct {
    adaptee Adaptee
}

// Interface implementation
func (a Adapter) Request() {
    a.adaptee.SpecificRequest()
}

func main() {
    adapter := Adapter{Adaptee{}}
    adapter.Request()
}

Sonuç

Tasarım desenleri, yazılım geliştirme süreçlerinde karşılaşılan ortak problemlere etkili ve tekrar kullanılabilir çözümler sunar. Ancak, her programlama dilinin kendi özellikleri ve best practice’leri vardır. Go gibi modern dillerde, klasik tasarım desenlerinin yerine dilin kendi özelliklerini kullanmak daha uygun olabilir. Bu makalede, hem klasik tasarım desenlerini hem de Go’nun idiomatik yaklaşımlarını inceledik.

Kaynaklar

• Design Patterns: Elements of Reusable Object-Oriented Software
• Go Patterns
• Refactoring Guru