Bayram Üçüncü

2008 yılından bu yana kahrımı çeken emektar laptopuma veda zamanı geldi çattı. Çünkü onu emekli edip yeni dizüstü bilgisayarımı satın aldım. Emektar makinam Datron marka olup TW7A modelinde ve zamanının 2.4Ghz  hızında en iyi işlemcilerine sahipti. Markasının Datron olması sebebiyle ben ona “Patron” diyordum.

Yeni makinam ise ASUS N56VZ. Son bir kaç haftadır bilgisayar araştırıyordum. Onu mu alsam bunu mu alsam derken en iyisi ben bu ASUS’u alayım diye karar kıldım. Asus için yakıştırmam ise “AL SUS” oldu. Gerçekten bu yakıştırmayı hakeden bir ürün. Şiddetle tavsiye ederim. Ürünü bir mağazanın “portakal rengi” indirim günlerinde inanılmaz bir fiyata yakaldım ve hemen satın aldım.

Emektar ve Yeni İşçi

Programlama dünyasında nesneler arası aktarım yapılması amacıyla geliştirilmiş olan Automapper kütüphanesi üzerinde yaptığım performans sonuçlarını yazmak istedim.

C# kodu ile geliştirdiğim örnek uygulama üzerinde sırsıyla 10, 100, 1000, 10000 ve 100000 kayıt üzerinde üç farklı şekilde Mapping işlemi yapmayı denedim.

Örnek senaryoda Product adında bir sınıf düşünün. Bu sınıfın 10 farklı property üyesi olsun. Ben bu 10 üyeli Product tipini taşımak istemediğimden ProductSummary adında 2 üyesi olan bir sınıf oluşturuyorum.

public class Product
{
   public int id { get; set; }
   public string Name { get; set; }
   public string Color { get; set; }
   public string Model { get; set; }
   public string Size { get; set; }
   ...
   ..
   .
}

public class ProductSummary
{
   public int id { get; set; }
   public string Name { get; set; }
}

Doğal olarak Product nesnesini bir şekilde ProductSummary nesnesine aktarmalıyım. Bu işlemi Automapper kütüphanesi ile ve manuel olarak denediğimde ve süreleri milisaniye cinsinden ölçtüğümde ilginç rakamlarla karşılaştım.

List<Product> products = new List<Product>();

Kayıt sayısı sırayla 10, 100, 1000, 10000 ve 100000 olarak değiştiriliyor ve her seferinde Mapping işlemi deneniyor.

Mapping-1 (Yöntem-1 Foreach döngüsüyle tek tek Mapping işlemi)

foreach (var product in products)
{
    ProductSummary summary = Mapper.Map<Product, ProductSummary>(product);
}

10             kayıt için süre    121 milisecond
100          kayıt için süre    127 milisecond
1000       kayıt için süre    155 milisecond
10000     kayıt için süre    498 milisecond
100000  kayıt için süre    5298 milisecond

Mapping-2 (Yöntem-2 Kolleksiyonu direk mapping işlemine sokmak)

ProductSummary summary = Mapper.Map<IEnumerable<Product>,
                                    IEnumerable<ProductSummary>>(products);

10           kayıt için süre    133 milisecond
100         kayıt için süre    126 milisecond
1000      kayıt için süre    221 milisecond
10000    kayıt için süre    152 milisecond
100000  kayıt için süre    339 milisecond

Mapping-3 (Yöntem-3 Automapper kullanmadan manuel olarak nesneleri oluşturmak)

foreach (var product in products)
{
    ProductSummary summary = new ProductSummary();
    summary.id = product.Id;
    summary.Name = product.Name;
}

10           kayıt için süre    1 milisecond
100         kayıt için süre    1 milisecond
1000      kayıt için süre    2 milisecond
10000    kayıt için süre    4 milisecond
100000  kayıt için süre    42 milisecond

Mapping-4 (Yöntem-4 LINQ Extension metodlar yarımıyla mapping işleminin gerçekleştirilmesi)

var data = products.Select(summary=>
                 new ProductSummary{
                    Id= summary.Id,
                    Name = summary.Name
});

10           kayıt için süre    1 milisecond
100         kayıt için süre    1 milisecond
1000      kayıt için süre    1 milisecond
10000    kayıt için süre    1 milisecond
100000  kayıt için süre    1 milisecond

Mapping Raporları

Bu sonuçlara göre Automapper kütüphanesi Mapping işlemlerinde biraz yavaş kaldığı aşikardır. En hızlı yöntemin LINQ Extension metodları yardımıyla Mapping işleminin olduğu ortaya çıkmaktadır. 100.000 kaydın mapping işlemine tabi tutulması 1 milisaniye sürmektedir. Aynı işlem Automapper kütüphanesi ile 5000 milisaniyeden fazla sürmektedir. Yani zaman probleminin olmadığı uygulamalarda Automapper kullanılabilir. Ancak işlemleri uzun sürede bitirmesi amacıyla yazılmış bir uygulama şu ana kadar hiç görmedim.

Bir sonraki yazıda görüşmek dileğiyle.

Asp.Net MVC mimarisinde yer alan model binding konusunu daha önceki yazılarda ele almıştık. Bu yazıda ise model binding işlemini JSON nesneleri ile uygylamaya çalışacağız. Web projelerinde ihtiyaç duyduğumuz  javascript tabanlı sorguları gerçekleştirmek için JSON nesnelerini .NET nesnelerine dönüştürmemiz gerekebilir. Request data olarak JSON nesnelerini POST edebilmeliyiz.

Örnek Uygulama

Örnek uygulama olarak bir ürün arama işlemini JSON formatındaki verileri bir Action metoda POST edeceğiz.

Öncelikli olarak Request ile gelen JSON fromatındaki veriyi deserialize ederek .Net nesnelerine dönüştürecek olan ModelBinder sınıfımızı oluşturmalıyız.

public class JsonModelBinder : IModelBinder
{
     public object BindModel(ControllerContext controllerContext,
                             ModelBindingContext bindingContext)
     {
          if (controllerContext == null)
             throw new ArgumentNullException("controllerContext");

          if (bindingContext == null)
             throw new ArgumentNullException("bindingContext");

          var serializer = new DataContractJsonSerializer(bindingContext.ModelType);
          var deSerialized = serializer.ReadObject(
                             controllerContext.HttpContext.Request.InputStream);

          return deSerialized;
    }

}

DataContractJsonSerializer sınıfının ReadObject metodu Request üzerinden ile gelen veriyi (InputStream), ModelBindingContext sınıfının ModelType parametresine göre uygun .Net tipine dönüştürür.

Şimdi de ModelBindingContext sınıfına gönderilecek olan tipi hazırlamalıyız.

[DataContract]
[ModelBinder(typeof(JsonModelBinder))]
public class JsonProductSearchRequest
{
     [DataMember]
     public string Name { get; set; }
     [DataMember]
     public string Color { get; set; }
}

System.Runtime.Serialization isim alanına dahil olan DataContract ve DataMember attribute tipleri sınıfları ve sınıf üyelerini serileştirilebilir hale getirmek için kullanılırlar. (Yeri gelmişken söylemekte fayda var; Bir tipi serileştirmek JSON, XML veya Binary şekillerde olabilmektedir. Biz örneğimizde JSON serileştirme üzerinde duracağız). JSonProductSearchRequest sınıfımızı, model binding sırasında ihtiyaç duyulan attribute olan ModelBinder ile imzalıyoruz, parametre olarak ise daha önceden hazırladığımız JsonModelBinder tipini gönderiyoruz.

Artık Controller tarafında ihtiyaç duyulan Action Metodları hazırlayabiliriz.

public class ProductController : Controller
{
   [HttpPost]
   public JsonResult JsonSearch(JsonProductSearchRequest request)
   {
       return null;
   }
}

JsonSearch Action metodu, daha önceden hazırladığımız JsonProductSearchRequest tipinde bir parametre almaktadır.

Şimdi hazırladığımız bu metoda fiddler yardımıyla bir istek (request) göndererek durumu incelemeye çalışalım.

Fiddler Json POST

Fiddler aracında Composer sekmesinden Request Tipini POST olarak seçiyoruz. Sunucudaki uygulama linkimizi girerek Request Body kısmına uygun JSON verisini giriyoruz. Execute butonuyla çalıştırdığımızda kodumuza geçip “break point” ile takip edersek:

Json Model Binder

Gönderdiğimiz verinin POST edildiğini rahatlıkla görebiliriz.

Bu şekilde etkili sonuç veren bir çözüme ModelBinding nimetlerinden faydalanarak ulaşmayı başardık. JSON tabanlı arama işlemlerini rahatlıkla bu şekilde gerçekleştirebiliriz. Ben bu örnekte View sayfalarıyla uğraşmamak adına fiddler aracından faydalanmayı uygun gördüm.

Bir sonraki yazıda görüşmek üzere.

Asp.net MVC mimarisini benim için değerli kılan özelliklerinden başında genişletilmeye uygun olarak tasarlanmış olması gelmektedir.

Bu yazımızda Asp.Net MVC yaşam alanına giren bir isteği(request) ilk karşılayan Controller mekanizmasının özelleştirilmesi üzerinde duracağız. MVC mimarisinde Controller tipleri belli kurallar dahilinde tanımlanmıştır. Bu kuralların dışına çıkmak istediğimizde kendi isteğimize göre özel kurallar oluşturarak sisteme dahil etmemiz gerekmektedir. Default olarak tanımlanmış Controller kurallarından biri de Controller sınıflarının kurucu metodları (constructor) parametresiz olmasıdır.

Controller

Bu yazımızda parametresiz constructor metodunu ihlal ettiğimizde karşılaşacağımız sorunlar ve çözümleri üzerinde duracağız.

Parametresiz Constructor Hatası

Parametresiz constructor kuralını ihlal ettiğimizde hemen bir hata ile karşılaşırız. Burada yapmak istediğimiz IoC (Inversion of Control) mantığında Controller sınıfına dışarıdan bir nesne(securityService) enjekte etmektir. Bu işlem için piyasadaki Ioc kütüphanelerini kullanabiliriz. Piyasada şu anda kullanılan kütüphaneler widsor, structuremap, ninject,… şeklinde sıralanabilir. Şu anda konumuz olmasa da IoC kütüphanelerinin yaptığı işten hemen kısaca bahsedelim. IoC kütüphaneleri interface gibi soyut tiplere karşılık olarak belirlediğimiz somut sınıflara ait nesneleri ihtiyaç duyduğumuzda oluşturarak bize sunarlar. Bu sayede “new” anahtar sözcüğü ile Controller içinde nesne oluşturarak somut tiplere bağımlı kalmamış oluruz.

Bu kısa notun ardından kendi tasarladığımız ControllerFactory sınıfımızı oluşturmaya başlayalım.

public class IocControllerFactory : DefaultControllerFactory
{
    protected override IController GetControllerInstance(

    RequestContext requestContext, Type controllerType)
    {
         return (IController)ObjectFactory.GetInstance(controllerType);
    }
}

DefaultControllerFactory sınıfının GetControllerInstance metodunu ezerek Controller nesnesi oluşturma işlemini StructureMap IoC container kütüphanesine yükledik. StructureMap kütüphanesi, önceden tanımladığımız interface ve sınıf eşleştirmesini yaparak constructor parametresi olarak kullanılan interface tipine karşılık bir somut nesne sunmaktadır.

public static class ContainerBootstrapper
{
     public static void BootstrapStructureMap()
     {
         ObjectFactory.Initialize(x =>
                  x.For<ISecurityService>().Use<SecurityService>());
     }
}

ContainerBootstrapper static sınıfında tanımladığımız BootstrapStructureMap metodu içerisinde interface tipine karşılık bir somut sınıf belirlenmektedir. ISecurityService interface tipi için SecurityService somut tipini kullan demiş olduk.

Hazırladığımız düzeneği çalıştırabilememiz için son olarak Global.asax içerisinde son hamlelerimizi yapmamız gerekiyor.

protected void Application_Start()
{
    .....
    ....

    ContainerBootstrapper.BootstrapStructureMap();

    ControllerBuilder.Current.SetControllerFactory(new IocControllerFactory());

}

Öncelikle ContainerBootstrapper.BootstrapStructureMap(); metodu ile eşleştirme işlemini gerçeklştiriyoruz. Ardından ControllerBuilder sınıfı yardımyla kendi özel conrtoller factory tipimiz olan IocControllerFactory tipini sisteme tanıtıyoruz. Artık DefaultControllerFactory sistemden çıktı ve yeni oluşturduğumuz factory tipi sistemimize dahil oldu.

Parametreli COntroller Constructor

Programı çalıştırdığımızda IsecurityService tipine karşılık olarak bir SecurityService nesnesi oluşturulmuştur.

StructureMap IoC container kütüphanesi hakkında detaylı bilgiyi buradan bulabilirsiniz.

Adapter tasarım deseni, kodun bağımlılığını azaltmak amacıyla uygulanan kalıplardan biridir. Özellikle kurumsal bazlı projelerde modüler yapıda geliştirme yapıldığı düşünüldüğünde uyumluluğun sağlanması, gerekli şartlardan saedce biridir. Proje üzerinde çalışan geliştiriciler farklı modülleri hazırlayıp ortak bir noktada yazılıma monte edebilmelidir.

Adapter Tasarım Deseni

Yukarıdaki şemada “Client” tarafındaki kod biriminin soyut olan (interface veya abstract) “Target” kod birimini tanıması ve “Target” tipinden türetilen diğer tipleri tanımaması modülerliğin ve test edilebilirliğin sağlanabilmesi için gerekli esnekliği bize sunmaktadır. “Adapter” tarafındaki kod birimleri, “Target” tipinden türetilmektedir. Bu noktadaki implementasyonları N sayıda geliştirici yapabilmelidir.

Adapter Tasarım Örnek

Bu şemada “Client” kod olarak bir rapor servisi (ReportService) sunulmaktadır. ReportService Servis tipimiz sadece soyut olan “IReportProducer” tipini tanır. IReportService tipinin uygulandığı WordReportAdapter tipini tanımaz. WordReportAdapter tipi sadece Microsoft.Office kütüphanesini kullanarak Word dökümanı üretir.

İki farklı geliştirici olduğunu düşünecek olursak birine Word dökümanı üreten adaptörü, diğerine de PDF dökümanı üreten adaptörü yazdırabiliriz. Geliştiricilerimiz de ReportService tipiyle ilgilenmezler. Sadece IreportProducer tipini tanırlar ve bu tipi implemente ederek PDF ve Word raporu üreten sınıfları geliştirirler.

Örnek uygulama

Örnek uygulama olarak yukardaki şemanın C# kodu ile yazılmasını ele alabiliriz.

public interface IReportProducer
{
    void CreateReport(Report report);
}
public class ReportService
{
      private readonly IReportProducer reportProducer;
      public ReportService(IReportProducer reportProducer)

          this.reportProducer = reportProducer;
      }
     public void CreateReport()
      {
          reportProducer.CreateReport(new Report());
      }
}
public class WordReportAdapter : IReportProducer
{
      public void CreateReport(Report report)
      {
          // TR: Office DLL nesneleri yardımıyla raporu oluştur.
          // EN: Get Office DLL objects and create Report
      }
}

Bu tasarım sayesinde ReportService sınıfı test edilebilir hale getirilmiş oldu. Mock nesneler oluşturulup tast işlemini gerçekleştirmek basitleşti.

Eğer Word döküman raporunu üreten kodu ReportService sınıfı içerisinde yapsaydık;

• Test edilebilirlikten uzaklaşacaktık.
• Birden fazla developer ile bir işi geliştiremeyecektik.
• Rapor servis tipi somut nesnelere bağımlı olacaktı.
• Yeni bir rapor üretici geliştirilmek istediğimizde servis sınıfını bozmak zorunda kalacaktık.

Adapter tasarım kalıbının uygulanması gayet basittir. Tek amacı ise birbirini tanımayan tipleri interface gibi soyut tipler kullanarak birbiri ile çalışabilir hale getimektir.

Kaynak Kod: https://skydrive.live.com/redir?resid=2884CE0681105B31!147

Scrum yaklaşımı üç ana kavram üzerinde inceleyebiliriz. Bunlar: product backlog, sprint backlog ve burn-down chart şeklindedir. Bu elemanlar Scrum yaklaşımı ile geliştirme yaparken takımlara yardımcı olan, yön veren ve projedeki şeffaflığı sağlayan elemanlardır.

Product Backlog (İstekler listesi)

Bir projede takımın tamamlaması gereken işler listesidir. Bu liste müşterinin ürününde ihtiyaç duyduğu ve yapılmasını istediği işlerin listesidir. Scrum yaklaşımının kilit bileşeni olan kullanıcı hikayeleri (user story) bu listenin temelini oluşturmaktadır.

Product Backlog listesi Product Owner tarafından yönetilir. Product Owner kullanıcı hikayelerini (user story) listeye eklemek ve çıkarmakla sorumludur. İstekler listesi müşteri ve Product Owner tarafından öncelik sırasına göre sabit bir şekilde oluşturulur. Bu sabit öncelik sırası Scrum kavramını kilit noktasıdır. Çünkü müşteri için en değerli hikayeler listede en üst sırada yer alacaktır. Kullanıcı hikayeleri eklendikçe listedeki diğer hikayelerle karşılaştırılıp müşteriye göre uygun öncelikli bir yere koyulacaktır. Sprint süresince product backlog listesine kullanıcı hikayeleri eklenmeye devam edebilir. Ancak Sprint tamamlanana kadar eklenen istekler Yürütülmekte olan Sprint turuna sokulmaz ve takıma sunulmaz.

User Stories (Kullanıcı hikayeleri)

Daha önce de belirtildiği gibi Product Backlog listesi öncelik sırsına konulmuş kullanıcı hikayeleri listesidir. Bir kullanıcı hikayesi müşteriye göre değer ifade edecek şekilde kartlara yazılır. Kullanıcı hikayesi geliştiriciye iş önceliği ve önem değerini anlatmak için yazılır. Kullanıcı hikayeleri bir pano üzerine dikey sırada olacak şekilde asılır. Kullanıcı hikayeleri INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler. Aşağıdaki listenin baş harflerini birleştirdiğimizde INVEST kelimesi oluşur.

• Indipendent(Bağımsızlık): Kullanıcı hikayesi kendi başına bir içeriğe sahip olmalıdır. Diğer kullanıcı hikayelerine bağlı olmamalıdır.
• Negotiable(Tartışılabilir): Kullanıcı hikayeleri, bir sprint döngüsüne girene kadar her an değiştirilebilir.
• Valuable(Değer): bir kullanıcı hikayesi son kullanıcı için bir değer ifade etmelidir.
• Estimable(Tahmin yürütülebilir): Bir kullanıcı hikayesinin süresi tahmin edilebilmelidir.
• Sized appropriately(Makul boyut): Kullanıcı hikayeleri plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çokkompleks yapıda olmamalıdır.
• Testable(Test edilebilirlik): Kullanıcı hikayeleri test edilebilirliği mümkün kılmalıdır.

Sprint Backlog(Sprint Listesi)

Bir Sprint turunda takımın yapacak olduğu işlerin listesidir. Product Backlog listesinin bir alt kümesi olarak düşünülebilir. Product Backlog içerisinde ürüne ait tüm kullanıcı hikayeleri yer alırken Sprint Backlog içerisinde Sprint içerisine alınmış hikayeler ve görevler yer alır. Bir Sprint döngüsü için seçilen bir kullanıcı hikayesi görevlere bölünerek takımda bulunan üyelere dağıtılır.

Görevler ise kullanıcı hikayelerini oluşturan iş birimleri olarak düşünülebilir. Her bir iş birimi bir takım üyesine atanır. Örneğin bir kullanıcı giriş ekranının tasarlanması veya bir ürün kataloğunun hazırlanması birer görev olarak düşünülüp takım üyelerine dağıtılabilir. Bu görevler kartlar üzerine yazılarak bir görev panosuna iliştirilir. Ancak günümüzde gelişmiş yazılımlarla görev panoları yerine bilgisayar ortamında da kayıtlar tutulabilmektedir.

Script Backlog

Sprint listesi aynı zamanda iş bitim grafiği(burn-down chart) için de gerekli bilgileri hazırlamaktadır. Her Sprint turunda Sprint panosu boşaltılır. Kalan işler olursa product backlog listesine geri iade edilir.

Born-down chart (İş sonu grafiği)

Sprint turu sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkmaktadır. Bu grafik takım üyelerine veya yöneticilerine fikir vermektedir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Grafiğin İngilizce adı olan burn-down, sözlük anlamı olarak yanıp bitmek şeklinde ifade edilmektedir. Bunu bir mumun yanarken zamana göre boyunu izlediğimizde bu şekilde bir grafik ortaya çıkar. Scrum yaklaşımında da yapılacak olan işler bittikçe zamana göre azalacak ve belirlenen süre sonunda sıfırlanacaktır.

Burn-down chart

Çevik yazılım geliştirme ilkelerinin uygulandığı iteratif bir geliştirme yaklaşımıdır. Scrum yaklaşımı “Sprint” diye adlandırılan zaman dilimlerinden oluşmaktadır. İki veya dört haftalık bu zaman dilimleri sonunda teslimata hazır çalışan programların ortaya koyulması amaçlanmaktadır.

Çalışmalar ürün yöneticisi(product owner) tarafından yapılacaklar işler listesindeki(product backlog) önem sırasına göre dizilir. Sprint’ler oluşmadan önce yapılacaklar listesinden bir iş seçilir ve takım ile iş teslim taahhüdü yapılır.

Her şeyin sorunsuz olması ve teslimin zamanında yapılabilmesi için ScrumMaster diye adlandırılan bir lider, takımın önündeki engelleri kaldırmakla sorumludur. Her gün ayakta yapılan yarım saatlik toplantılarda takım ile teslime engel olabilecek sorunlar ve son durumlar hakkında konuşmalar yapılır.

Aşağıdaki resimde Scrum sürecini anlatan grafiksel bir temsil bulunmaktadır.

Scrum Süreci

Her bir Sprint süresi 2-4 haftadır. Takımlar proje yöneticisi(ScrumMaster) ile her Sprint başlangıcında toplantı yaparak geliştirilecek özellikleri belirlenir. Bu süreçteki özellikler daha önceden oluşturulmuş ve sürekli güncellenen yapılacak işler listesinden(Product Backlog) önem sırasına göre seçilir. Seçilen özellikler Sprint Backlog deinlen yeni bir listeye yazılır. Artık Sprint döngüsü başlamıştır ve sadece ellerindeki Sprint listesiyle ilgilenirler. Bir sonraki Sprint döngüsü başlayana kadar Product Backlog listesine bakmazlar.

Her gün ayakta yapılan ve en fazla 15 dakika süren toplantılar(Dailit Stand-Up) ile sorunlar ve ilerleme durumları ele alınır. Sprintler sonunda teslimata hazır çalışan bir program ortaya çıkar.

Scrum yönteminin sağladığı en büyük faydalardan biri şeffaf ve raporlanabilir bir geliştirme sürecine sahip olabilmektir. Raporlar sayesinde geçen zaman ve kalan zaman grafiklerine bakılarak durum gözlemi yapılabilmektedir.

Kaynak: ProAgile .Net Development with Scrum

Specification tasarım kalıbı, bir nesne içerisindeki mantıksal (boolean) yapıdaki iş kurallarının, dışarıdan almasını sağlamak amacıyla oluşturulmuştur. İş kuralları, birbirini takip eden zincirli bir yapıda olup daha karmaşık bir iş kuralını da ortaya çıkarabilir.

Kod Örneği

Desenin anlaşılabilmesi açısından bir kod örneği ile devam etmek istiyorum. Kod örneğimizi bir iş nesnesi üzerindeki mantıksal kuralları ele alarak geliştirmeye çalışacağız. Örneğimizde bir ürünü temsil eden tip üzerinden ilerleyeceğiz.

Ürün tipinde, stok durumunun yeterli olup olmadığını belirleyen bir mantıksal iş kuralını dışarıdan temin edecek şekilde modelleyerek ilerleyelim.

Altyapımızı oluştururken öncelikle şartname niteliğinde bir interface hazırlamalıyız.

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T candidate);
}

Şartnamemizde, bu şartnameyi uygulayan sınıfların tipinden bir generic “T” parametresi verilmiştir. Bu sayede şartname tipi dışarıdan alınabilir şekilde genelleştirilmiştir.

ISpecification<T> tipine T parametresi yerine vereceğimiz ve iş nesnesi olarak kullanacağımız ürün tipini, adını Product olacak şekilde belirliyoruz.

public partial class Product
{
    public decimal Stock {get; set; }
}

Artık bu tipimize bir iş kuralı belirlememiz gerekmektedir. İş kuralımızı kısaca stok miktarının kritik olduğu durumu gözetecek şeklide belirleyebiliriz. Stok miktarı 50′nin altına düşerse şartımız çalışacaktır.

public class IsCriticalStock : ISpecification<Product>
{
     public bool IsSatisfiedBy(Product product)
     {
         return candidate.Stock < 50;
     }
}

Şartnameyi kabul eden bir tip olarak IsCriticalStok isimli sınıf oluşturduk. Artık iş kuralını bünyesinde barındıran bu sınıfımızı Product tipine tanıtabiliriz. Product tipimizi yeniden tasarlayacak olursak;

public partial class Product
{
       private readonly IsCriticalStock isCriticalStock;

       public Product()
       {
           isCriticalStock= new IsCriticalStock();
       }

       public decimal Stock {get; set; }

       public bool IsStockEnough()
       {
            return isCriticalStock.IsSatisfiedBy(this);
       }
}

Bu şekilde iş kuralımızı Product tipine geçirmiş oluruz. Kodun okunabilirliğini arttırmak için Product sınıfını parçalı şeklide “Partial” tanımlayabiliriz.

public partial class Product
{
      private readonly IsCriticalStock isCriticalStock;

      public Product()
      {
          isCriticalStock= new IsCriticalStock();
      }

      public decimal Stock {get; set; }
}

public partial class Product
{
      public bool IsStockEnough()
      {
        return isCriticalStock.IsSatisfiedBy(this);
      }
}

Bu örnek aracılığıyla Specification tasarım kalıbını en basit haliyle incelmiş olduk.

Visual studio ürün ailesine dahil edilen 2012 sürümünü çoğumuz kurup çalışmaya başlamışızdır. Bu versiyonda dikkatimi en çok cezbeden nokta Update süreleriydi. Daha Visual Studio ürününü yükler yüklemez bir Update uyarısı verdi. Yeni ürünün yeni güncellemesini yüklemek istedim. Aman Allah’ım! Tam üç saat. Tabi bu internet hızı ile alakalı bir durum mu yoksa bilgisayar donanımı ile alakalı mı diye bir düşünce sardı beni hemen. Derken güncelleme işlemi hayırlısıyla sona erdi.

Visual Studio Update

Aradan bir iki ay geçti, Visual Studio’yu başlattığımda bu sefer de Update1 diye bir uyarı belirdi Windows’un sağ alt köşesinde. Eyvah! dedim içinden. Gene kabus başladı. Tam 2 saatte Update1 için zaman harcadım.

Bu kadar uzun süren Update yapacaklarına yeni versiyon çıkarsalar daha isabetli olurdu bence. Çünkü Visual Studio ürününü sıfırdan yükleme süresi zaten yarım saat. Bu yarım saat üzerine 5 saatlik güncelleme yükü çok can sıkıcı oluyor. Bu kadar can sıkıcı olmasaydı bu yazıyı ele almazdım inanın.

Ürünün önceki sürümlerinde böyle bir durumla karşılaşmamıştık. Umarım buna bir önlem alırlar ve Update 2 çıkmadan ürün yenilenir. Yeni bir güncellemeye ayıracak vaktim yok.

Bir sonraki yazıda görüşmek üzere.

Kitap tanıtım bölümü kategorisine eklediğim bu yazı “The Art of Unit Testing” adlı kitap üzerine olacaktır. Roy Osherove tarafından yazılmış olan bu kitap Manning yayıncılık tarafından piyasaya sürülmüştür. Kitabı amazon.com üzerinden temin ettim. Kargo maliyetinden kaçınmadığımdan kitap 4 günde elime ulaştı. Resimde de görüldüğü üzere artık elimde.

Amazon Kargo Paketi

Hemen paketi açıp merakımı gidermek istedim. İçeriği, dış kapağı, faturası… her şeyini merak ediyordum.

Kitap

Kitabı bir hafta gibi bir sürede okudum. Bende oluşturduğu izlenim, Unit Test konusunda bilgisi olan geliştiricilerin okuması gereken bir kitap olduğu şeklindeydi. Test Driven Development konusunda hiç bilgisi olmayan bir geliştiriciye çok faydalı olacağını söyleyemem. Çünkü sıfırdan Tets Driven tekniğini anlatan bir içeriğe sahip değil. Ancak unit testleri yazarken dikkat edilmesi gereken kuralları güzel bir şekilde anlatıyor. Diğer yandan unit test yazarken gerekli olan ve kullanılması framework’lerden bahsetmektedir. Unit test yazma sanatını anlatan bir çeriğe sahip. Kitaptaki örnek uygulamalar .Net platformunda C# programlama dilinde yazılmıştır. Sade ve anlaşılır bir dille kalema alınmıştır.

Test Driven Development ile geliştirme yapanların baş ucunda bulunması gereken kitaplardan biri diyebilirim.

Kitabın amazon.com linkine buradan ulaşabilirsiniz.