abstract factory pattern ^*

• object oriented dillerde kullanılan bir şablon. abstract bir factory object yazılır ve diğer bütün factory object'ler bunu abstract class'i extend ederler.
  
  böylece program dahilinde kullanilan bütün fabrikalar birbirleriyle ortak method'lar kullanırlar.
• abilerimiz bu pattern için c++'da $öyle bir örnek vermi$:
  ------------
  
  #include <memory>
  using std::auto_ptr;
  
  class control { };
  
  class pushcontrol : public control { };
  
  class factory {
  public:
  // returns factory subclass based on classkey. each
  // subclass has its own getcontrol() implementation.
  // this will be implemented after the subclasses have
  // been declared.
  static auto_ptr<factory> getfactory(int classkey);
  virtual auto_ptr<control> getcontrol() const = 0;
  };
  
  class controlfactory : public factory {
  public:
  virtual auto_ptr<control> getcontrol() const {
  return auto_ptr<control>(new pushcontrol());
  }
  };
  
  auto_ptr<factory> factory::getfactory(int classkey) {
  // insert conditional logic here. sample:
  switch(classkey) {
  default:
  return auto_ptr<factory>(new controlfactory());
  }
  }
• yaratımsal (creational) bir tasarım deseni (design pattern).
  
  bir sınıf ailesinin (product1, product2, product3) oluşturulması için ortak bir arayüz (abstractfactory) belirlersiniz. daha sonra, bu sınıf ailesinin farklı alt sınıflardaki örneklerinin (product1a, product1b, product1c, product2a, product2b, product2c) yaratılmasını da abstractfactory arayüzünü geliştiren birer sınıf (factorya, factoryb, factoryc) üzerinden gerçekleştirirsiniz.
  
  bu farklı üretici sınıflar, aslında sadece kendileriyle ilişkili ürünleri üretirler ama hepsi 'abstractfactory'den türediği için, bu sınıfları kullanan istemci sınıflar tek bir arayüzü ve dolayısıyla tek bir kodu kullanarak her tür ürün ailesiyle çalışabilirler.
  
  örneğin bir veritabanı sistemini ele alalım: ortak sınıflar veritabanı(database) ve tablo(table), her veritabanı türü için (microsoft, oracle, mysql) ortaktır. dolayısıyla bunların davranışlarını birer üst sınıfta belirtebiliriz:
  
  abstract class database {}
  abstract class table {}
  
  daha sonra bu soyut(abstract) sınıfların yaratılmasını gerçekleştiren bir soyut fabrika (abstractfactory) sınıfı yazalım:
  
  abstract class dbmsmanager
  {
  public abstract database createdatabase();
  public abstract table createtable();
  }
  
  yapıyı soyut olarak tanımladıktan sonra, soyut ürünlerin her birinin farklı aileleri için farklı sınıfları tanımlayalım:
  
  class mysql_database : database {}
  class oracle_database : database {}
  class microsoft_database : database {}
  
  class mysql_table : table {}
  class oracle_table : table {}
  class microsoft_table : table {}
  
  ve her bir ürün ailesi için soyut fabrikadan kalıtlanan birer ayrık fabrika sınıfı yazalım:
  
  class mysql_dbmsmanager : dbmsmanager {}
  class oracle_dbmasmanager : dbmasmanager {}
  class microsoft_dbmsmanager : dbmsmanager {}
  
  örneğin mysql_dbmsmanager'ın createdatabase fonksiyonu, bir mysql_database nesnesi oluşturur ancak bu nesne database soyut sınıfından türediği için createdatabase fonksiyonunun sonucunda döndürülebilir. böylece mysql, oracle, microsoft veritabanlarının hepsini yönetmek için tanımladığımız tek bir arayüzden hepsini yönetebilecek ortak bir kod yazabiliriz:
  
  dbmsmanager mng = new mysql_dbmsmanager();
  database mydb = mng.createdatabase();
  
  sonuçta dönen veritabanı türünün hangi firmaya ait olduğu önemli değildir. böylece kodunuzun tekrar kullanılabilirliği ve genişletilebilirliği bir hayli yükselmiş olur.
• bir ornek de windowstaki classic ve xp tema olayidir. siz ornegin abstract olan windowfactory metotlarini cagirirken kullanicinin tercihine gore instantiate edilmis classicwindowfactory veya modernwindowfactory classlarinin metotlaridir cagrilan.
  temaymis, skinmis bu tur nosyonlarin oldugu yerde bu patterni kullanmak sakaysa cok ciddi, ciddiyse ciddi degildir.
• paralel nesne hiyerarşisi ya da çok karmaşık inheritance ilişkileriniz yoksa bunun yerine factory method kullanmanız daha mantıklı olabilir. bu durumda basit bir fabrika sınıfı oluşturup içine bir adet string parametre alan static bir metod yazarsanız nesne yaratım işlemini az da olsa ortamdan soyutlamış olursunuz.
• design patterns in abap objects adlı kitapta sap abap uygulaması öğrenilebilecek şablon.
• en severek kullandığım design pattern'lerden biri.
  
  20 kadar değişik grafik (pie, bar chart vesayre) üreten bir sistemin tüm çıktılarını bir powerpoint dosyasına slide'lar olarak almam gerekiyordu. abstract factory pattern kullanarak tüm chart'lar için tek bir interface'i implement eden factory method yarattığımda problem oldukça zarif bir şekilde çözüldü. bütün grafikler aynı arayüzü kullansın, döngüye al, hepsi için generateslide() fonksiyonunu çağır. gelen slide'ı powerpoint dosyasına ekle. bitti gitti.
  
  bir işlevin girdisi olarak bir factory'i inject ettiğimiz için dependency injection ile karıştırılır ancak abstract factory di'ın aksine bir tasarım desenidir (bkz: design pattern) ve tasarım içerisinde sadece gereken noktalarda kullanılır. tüm yazılımı abstract factory çalışacak şekilde tasarlama gerekliliği oldukça düşük bir ihtimaldir. dependency injection ise bir mimari desen olan inversion of control'ün implementasyonudur (bkz: architectural pattern) ve etkin kullanımı için tüm mimarinin di'ye yönelik yapılması gerekir. sonuç olarak abstract factory eğer isteniyorsa di mimarisi üzerine oturan opsiyonel bir araçtır.