Abstract Factory Pattern

[en] Read in English

2023-05-26

Bir zamanlar, bir krallık vardı ve bu krallığın adı “Soyut Fabrika”. Her ne kadar soyut gibi görünse de, bu krallıkta her şeyin bir amacı, bir düzeni ve belirli bir tasarımı vardı. Burada her şeyin nasıl yapıldığına dair belirli kurallar vardı ve bu kurallar, nesnelerin oluşturulmasını düzenleyen tasarım örüntülerine dayanıyordu.

Soyut Fabrika krallığında, Kral AbstractFactory, farklı tipteki ürünlerin fabrikalarını yönetir. Kral, bir fabrikanın çeşitli ürünleri aynı anda üretebilmesi gerektiğini düşünürdü. Kral, bu fabrikaların her birine, aynı aileden olan ürünleri yaratma görevini verir. Örneğin, bir fabrika Button ve TextField oluşturabilirken, başka bir fabrika Slider ve Dropdown oluşturur.

C# dilinde bu konsept şu şekilde uygulanır:

public abstract class AbstractFactory
{
    public abstract IButton CreateButton();
    public abstract ITextField CreateTextField();
}

public class FactoryA : AbstractFactory
{
    public override IButton CreateButton()
    {
        return new ButtonA();
    }

    public override ITextField CreateTextField()
    {
        return new TextFieldA();
    }
}

public class FactoryB : AbstractFactory
{
    public override IButton CreateButton()
    {
        return new ButtonB();
    }

    public override ITextField CreateTextField()
    {
        return new TextFieldB();
    }
}

Java dilinde aynı konsept:

public interface AbstractFactory {
    Button createButton();
    TextField createTextField();
}

public class FactoryA implements AbstractFactory {
    public Button createButton() {
        return new ButtonA();
    }
    public TextField createTextField() {
        return new TextFieldA();
    }
}

public class FactoryB implements AbstractFactory {
    public Button createButton() {
        return new ButtonB();
    }
    public TextField createTextField() {
        return new TextFieldB();
    }
}

Python’da bu örneği görelim:

from abc import ABC, abstractmethod

class AbstractFactory(ABC):
    @abstractmethod
    def create_button(self):
        pass

    @abstractmethod
    def create_text_field(self):
        pass

class FactoryA(AbstractFactory):
    def create_button(self):
        return ButtonA()

    def create_text_field(self):
        return TextFieldA()

class FactoryB(AbstractFactory):
    def create_button(self):
        return ButtonB()

    def create_text_field(self):
        return TextFieldB()

Go dilinde de bu örneği uygulayabiliriz:

type AbstractFactory interface {
	CreateButton() Button
	CreateTextField() TextField
}

type FactoryA struct{}

func (f FactoryA) CreateButton() Button {
	return ButtonA{}
}

func (f FactoryA) CreateTextField() TextField {
	return TextFieldA{}
}

type FactoryB struct{}

func (f FactoryB) CreateButton() Button {
	return ButtonB{}
}

func (f FactoryB) CreateTextField() TextField {
	return TextFieldB{}
}

Rust dilinde ise bu durum şu şekildedir:

pub trait AbstractFactory {
    fn create_button(&self) -> Box<dyn Button>;
    fn create_text_field(&self) -> Box<dyn TextField>;
}

pub struct FactoryA;
pub struct FactoryB;

impl AbstractFactory for FactoryA {
    fn create_button(&self) -> Box<dyn Button> {
        Box::new(ButtonA)
    }

    fn create_text_field(&self) -> Box<dyn TextField> {
        Box::new(TextFieldA)
    }
}

impl AbstractFactory for FactoryB {
    fn create_button(&self) -> Box<dyn Button> {
        Box::new(ButtonB)
    }

    fn create_text_field(&self) -> Box<dyn TextField> {
        Box::new(TextFieldB)
    }
}

Soyut Fabrika krallığının hikayesi böyle. Ürünlerin farklı çeşitlerinin tek bir fabrika tarafından nasıl üretilebileceğini anladık. Her fabrika, belirli bir ürün ailesi oluşturur ve bu da bize ürünler arasında tutarlılık sağlar. Bu, özellikle ürünler arasında belirli bir ilişki olduğunda veya belirli bir fabrikanın sadece belirli bir türde ürünler oluşturması gerektiğinde çok kullanışlıdır. Bu şekilde, bir fabrika yalnızca bir tür düğme oluşturabilirken, başka bir fabrika farklı bir tür düğme oluşturabilir.

Bu hikaye, soyut fabrika tasarım kalıbının ne olduğunu ve nasıl kullanılabileceğini gösteriyor. Her dilde, bu kalıbı uygulamanın belirli yolları vardır, ancak temel konsept her zaman aynıdır: bir fabrika, belirli bir aileye ait bir dizi ürün oluşturur ve bu ürünler arasında belirli bir ilişki vardır. Bu, kodun daha düzenli ve anlaşılır olmasını sağlar, ve daha da önemlisi, kodun daha kolay bakım ve genişletilebilir olmasını sağlar.



Bu gibi daha fazla gönderi...

Bileşenlerin Dansı: Composite Tasarım Kalıbı

2023-06-22 | #composite-pattern #design-patterns #structural-patterns

Bir zamanlar, bir ormanda bir ağaç vardı. Bu ağaç, yaprakları ve dalları olan karmaşık bir yapıydı. Her dalın üzerinde daha küçük dallar ve yapraklar bulunabilirdi. Ağaç, dallarını ve yapraklarını bir arada tutan bir bütün olarak çalışıyordu. Bu ağaç, Composite tasarım kalıbının bir örneğidir. Ağaç (Composite), dallar (yine Composite) ve yapraklar (Leaf) olmak üzere iki tür bileşen içerir. Hem dallar hem de yapraklar, ağaç tarafından tanınan aynı arayüzü (Component) uygular. Bu sayede ağaç, dallarını ve yapraklarını aynı şekilde işleyebilir.

Devamı 


Köprüler Kurarak Esneklik Kazanın: Bridge Tasarım Kalıbı İle Çözümlemeler ve Dört Farklı Dilde Uygulamalar

2023-06-22 | #bridge-pattern #design-patterns #structural-patterns

Bir zamanlar, iki krallık varmış. Bu krallıklar birbirlerine çok yakın olmasına rağmen, aralarında geniş ve derin bir nehir bulunuyormuş. Bu nehir, krallıkların birbirleriyle etkileşim kurmasını zorlaştırıyormuş. Bu durumu çözmek için, her iki krallık da bir köprü inşa etmeye karar vermiş. Bu köprü, iki krallık arasında iletişimi sağlayan bir arayüz olmuş. Ancak, köprünün her iki tarafında farklı yapılar ve özellikler bulunuyormuş. Bir taraf taştan, diğer taraf ise ahşaptan yapılmış. Bu durum, köprünün her iki tarafının birbirinden bağımsız olarak değiştirilebilmesini sağlamış.

Devamı 


Dekoratör Tasarım Deseni: Yazılımın Süsleyicileri

2023-06-15 | #decorator-pattern #design-patterns #structural-patterns

Bir zamanlar, bir “Component” adında bir nesne varmış. Bu nesne, belirli bir işlevi yerine getirmek için kullanılırmış. Ancak, bazen bu işlevi genişletmek veya değiştirmek gerekiyormuş. İşte bu noktada “Decorator"lar devreye giriyormuş. Decorator’lar, Component’i “süsleyen” veya genişleten nesnelerdir. Bir Decorator, bir Component’in üzerine gelir ve onun işlevini genişletir veya değiştirir. Bu, Component’in kendisini değiştirmeden, onun işlevselliğini genişletmek için kullanılır. Örneğin, bir “TextComponent” düşünün. Bu component, bir metni ekrana yazdırır. Ancak, bazen metni kalın veya italik yapmak isteyebiliriz.

Devamı 