TASARIM ÖRÜNTÜLERİ
Abstract Factory Örüntüsü (Deseni)
Creational Patterns bir örneği olan Abstract Factory bize benzer işlevi gerçekleştiren farklı grup bileşenleri/sınıfları üretme sırasında karşımıza çıkacak karmaşayı nasıl önleyebileceğini anlatmaktadır.
Bilgi Notu: Diğer tüm Tasarım Örüntüleri yazıma bu linkten ulaşabilirsiniz.
Hangi Durumda
Uygulamalarda birbirine bağımlı bir grup sınıfı A durumu için oluşturup, B durumu için bir başka bir grup sınıfı oluşturmanız gerekir. Bu durumda mevcut çözüm iki durumu if/else veya switch yazmak şeklinde olacaktır.
class Factoryif(durumA)
new X_AClass, new Y_AClass, new Z_AClasselse if(durumB)
new X_BClass, new Y_BClass, new Z_BClass
Örneğin İşletim sistemine göre Swing bileşenlerinin farklı görüntülenmesi gerecektir. Windows, Linux, MacOS vb işletim sistemlerinde tüm UI bileşenlerinin farklı farklı rendering ihtiyaçları olacak. Bu durumda Look And Feel değiştirme ihtiyacımızın olduğu durumda
Bu bileşenleri üretme kodunun mantığını Factory içerisinde yeni if/else ekleyerek gerçekleştirebiliriz. Ama bu her bir durum için oluşturulacak bileşen sayısı çok fazla olduğu durumlarda bu sınıfın kodları oldukça karmaşık hale gelecektir. Yeni bir işletim sistemi geldiğinde bu ana sınıfta oldukça büyük değişiklikler yapmak gerecektir.
Bu karmaşıklığı önlemenin en iyi yöntemide Sınıf Grubu üretme mantıklarını belli sınıflarda toplamaktır.
Avantajları
Aşağıdaki örnekten üzerinden anlatırsak
WinFactory ve OSXFactory gibi 2 tane üretim sınıfı oluşturduğumuzda
- Kendi bileşenlerini üretmekten sorumlu hale geldi. Sorumluluk alanı daraldı ve daha kontrol edilebilir hale geldi.
- Bu tek bir sınıfın çok büyümesini engelledi. Sadece kendi sorumluluğundaki bileşenleri bilmesini sağlandı.
Değişiklik İhtiyaçlarını Nasıl Karşılayacak
- Yeni bir işletim sistemi eklendi: Diğer Factory sınıfları bu durumdan etkilenmeyecek , yeni bir tane daha eklenecek. GUIFactory sadece bir satırlık if/else eklenecek.
- Yeni UI Bileşeni eklenmek isteniyor. Bu durumda AbstractFactory (GUIFactory) bu bileşen oluşturma mantığı eklenmeli ve bundan türeyen Concrete sınıflar (WinFactory ve OSXFactory) bu geliştirmeye göre kendi yapılarını bunu eklemeliler ve bunun ile ilgili bileşenler oluşturulmalı.
Kullanım Alanları
Bunun gibi bir projede UI bileşenlerinin belli modlara göre tamamen farklı görünmesi veya davranması gerekebilir
Örneğin: Aynı bileşenler aşağıdaki modlara göre farklı davranması gerekebilir.
- UI Gündüz Modu / Gece Modu
- UI Player/ Trainer
- Editing Mode / Playing Mode / Replay Mode
Bu gibi durumlarda tüm UI bileşenlerinin bu modlara göre keskin çizgiler ile ayrılması gerekiyor ise aşağıdaki kod örneğinde olduğu gibi Abstract Factory örüntüsünü kullanırız.
Örneğin: Bir bileşen yazdınız Query mekanizmasının işletilmesini sağlıyor. ConsoleUI, WindowUI, YardımEkranı, Parser, Mapper vb.. ortak sınıfları bulunuyor. bu durumda. Bir bağlamda Query mekanizması için tüm bu nesnelerin oluşturulması , başka bir bağlamda aynı yapıların başka sınıfları oluşturulması gerektiği durumlarda bu Abstract Factory Tasarım örüntüsünden faydalanabiliriz.
Örneğimizi incelersek Interface oluşturulacak UIBileşenleri (Button, Label) ve bunları oluşturacak AbstractFactory sınıfı olan (GUIFactory) GUIFactory hangi bileşen arayüzlerini oluşturacağını biliyor sadece
Button createButton();
Label createLabel();GUIFactory’den türeyen bu gruplamayı sağlayacak ConcreteFactory sınıflar bulunuyor. Bunlar WinFactory ve OSXFactory bunlar gerçekleştirim bileşenleri oluşturmakten sorumlular.
Application ekrana Label ve Button render etmek istiyor ama hangi Win/OSX Factory ile çalışıp çalışmadığını bilmek zorunda değil. Bu sayede bu servisi kullanan kişi kendisini işletim sisteminin detaylarından kendisini soyutlamış oluyor.
Burda işletim sistemi detayına göre hangi AbstractFactory döneceğini bilen ApplicationRunner ama oda GUIFactory ne dönüyor , içerlerinde ne logicler var bilmek zorunda değil .
Bu tasarımda herkes kendi işinden sorumlu 😃
- Application bana Button, Label ver paint et diyor sadece
- ApplicationRunner → Hangi işletim sistemi olduğunu bilip ona göre doğru Concrete GUIFactory dönmekten.
- GUIFactory → Sadece üreteceği bileşenlere ait metodlara sahip metodlarda hangi Interface döneceğini biliyor
- WinFactory, OSXFactory → kendi Concrete UI bileşenleri nasıl üreteceklerini biliyorlar
- Button, Label → bileşen interface bileşen mekanizmalarının hangi özelliklerinin ve metodlarının olması gerektiğini tanımlıyorlar.
- WinButton,WinLabel → Windows işletim sisteminde düğme ve etiketin nasıl paint edileceğini biliyorlar
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
