Image
Kasım 01 2015 02:28

Bridge Design Pattern

Yapılacak işlemlere ait tanımlar belli, bu işlem tanımlarını işleyecek  kalıplar belli ve fakat birbirlerinden ayrı olan bu yapılar arasında sen bunu kullan sen bunu kullan diye ilişkiler /köprüler kuran tasarım kalıbı.

Önce kurgumuzu yapalım sonra Uml diyagramından kontrol edelim en sonda bu kurgu ve diyragma göre biraz kod yazalım.

                Bir uygulama yazıyoruz, hem oracle hemde sql kullanacağız bu yüzden iki tane providerimiz olmalı SqlProvider ve OracleProvider.Sql ile ilgili işlemler yapacağımız zaman SqlProviderı, Oracle ile ilgili işlemler yapacağımız zaman ise OracleProvider kullanacağız.

Bu uygulamada elbette Logic işlemlerimiz olacak bu işlemler içinde BusinessLayer yazmamız gerekiyor. Örneğin ullanıcı işlemleri için(KullanıcıBusiness)  işlemler ekledik. KullanıcıSil, KullanıcıEkle gibi metodlar ekliyoruz.
Sipariş işlemleri için (SiparisBusiness)  işlemlerini yapacak bir  katman ekledik.

Bildiğiniz gibi KullanıcıSil metodunu çağırırken bir Database operasyonlarını yapacak bir Providere ihtiyacımız olacak. Elimizde ise SqlProvider ve OracleProvider var. Burda şuna dikkat etmek lazım. Bridge Pattern ile Strategy Pattern’in en çok karıştırıldığı yer burasıdır.

 Bridge ve strategy patternde dışardan alıyorsunuz iş yapan nesneyi, nedir mesela KullanıcıSil, KullanıcıEkle yapacaksınız ve databasede işlem yapacak bir providere ihtiyacımız var eğer bu provider değişebiliyorsa bu Strategy Pattern dir. Duruma göre developerin o anki şartlar altında bir iş yapacağı zaman işin nasıl yapılacağı üzerinde tasarrufu varsa bu Strateji patternin işidir.

İşin kim tarafından yapılacağı sözkonusu ise.. ki bizim örnekte yapmak istediğimiz KullanıcıSil- mek dolayısı ile bizi o kullanıcının silinmesi ilgilendiriyor. Kimin hangi nesnein hangi providerin kullanıcılacağı ilgilendirmiyor.

Özetle databasede bir iş yapılması gerekiyor, Burada Kim sorusunu soruyoruz, Nasılı bizi ilgilendirmiyor.

Dolayısı ile biz “xyz” için KullanıcıSil metodunu çağırırken, Strategy Pattern’de ki gibi kim yaparsa yapsın düşüncesi ile kafama göre sen bu Provideri seç diyemem. Uygulama startup aldığında işin kimin tarafından yapılacağını belirleyip ve uygulamanın lifesycle si içinde bu hep böyle devam etmesini isterim.  Uygulama ayağa kalkarken ilgili Businessin ben oracle ile çalışacğım ben sql ile çalığacağım seçiminin yapılması gerekiyor.

İşte hikayenin özüde aslında bu, siz uygulama ayağa kalkarken BusinessLayerden SqlProvidere köprü atıp bundan sonra bütün ulaşımlarımı senin üzerinden yapıyor olacağım çünkü başka Alternatifim yok diyorsunuz.

Bizim örneğimizde  KullanıcıBusiness SqlProvider e köprü atmış diye kurguladık , SiparisBusiness için OracleProvidere köprü atayabilirdik. Yada başka bir providere…

Blog image

 

Implementor = DBProvider

ConcreateImplementorA, ConcreateImplementorB = SqlProvider, OracleProvider

Abstraction = Bir implemenntore sahiptir Bizim örneğimizde SqlProvider olacak

RefinedAbstraction = Abstractiondaki arabirimi genişletilmiş hali. Bizim kullanıcı silme işlemini bazı validasyon, kontroller, onaylama sms vs işlemlerini bitirdikten sonra yapıyor olmamız gerekiyor. İşte aradaki bütün bu işlemler yapıldıktan sonra Base deki  Abstraction clasımızda KullanıcıSil metodunu çağırma işlemini yapan class

Bu kadar yazdıktan sonra yukarıda kurguladığımız örneği Bridge Pattern diyagramına gçre kodlayalım.

Database işlemlerini yapacağımız bir providerlara ihtiyacımız var bu provider bir bir base-den türeyecekler. Bu Abstractionun adı DbProvider olsun. Insert ve Delete metodları olsun.

 

    public abstract class DbProvider
    {
        public abstract void Insert();
        public abstract void Delete();
    }

Oracle ve Sql prviderlerimiz olacak elbetteki DBProviderden türeyecekler.

    public class SqlProvider : DbProvider
    {
        public override void Delete()
        {
        }

        public override void Insert()
        {
        }
    }

    public class OracleProvider : DbProvider
    {
        public override void Delete()
        {
        }

        public override void Insert()
        {
        }
 
    }

İyi güzel providerleri de tanımladık, şimdi bu imlementore sahip bir base oluşturalım

   public class BusinessBase
    {
        readonly DbProvider _provider;
        public BusinessBase()
        {
            _provider = new SqlProvider();
        }

        public void Delete()
        {
            _provider.Delete();
        }
    }

Dikkat! Delete işlemi yapılırken git db den sil diyemiyoruz. Düşünsenize içerde sipariş kayıtları olan bir kullanıcıyı pat diye silmeye çalışıyoruz.
Bunun olmaması laazım bu yüzden business te bazı operasyonlardan geçtikten sonra providerde silme çalışsın diyeceğiz.  

Böylece köprünün bir bacağını olluşturmuş olduk, şimdi diğer bacağını atacağımız Business layer tarafını oluşturalım.
Yazdığımız bu BusinessBaseyi kullanacak olan kullanıcıBusinessi oluşturalım.

public class KullaniciBusiness : BusinessBase
    {
        public void KullaniciSil()
        {
            Delete();
        }
    }

Artık logic olarak bir kullanıcının silinmesine izin verdiğimizde Base deki silme işlemini çağırabiliriz.

2015 : memet tayanç