Ana içeriğe atla

.NET Framework 4.0 ile Genel Yenilikler – C# 4.0

Bu bölümde C# 4.0 ile birlikte gelen yeniliklere göz atacağız. Bu kapsamda bahsedeceğimiz konular aşağıdaki gibidir.
  • Dynamic Typing
  • Generic Variance
  • Named Arguments
  • Optional Parameters
  • COM InterOp Enhancements
Dynamic Typing
C# 4.0 ile birlikte dinamik tipinde nesnelere kullanılarak dinamik olarak programlamaya odaklanılmıştır. Dynamic anahtar kelimesi C# 4.0 ile birlikte gelen bir kelimedir. Bu anahtar kelime, derleyiciye bu değişkeninin tipinin değişebileceğini ve çalışma zamanına kadar bilinemeyeceğini söylemektedir. Yani Dynamic Language Runtime-DLR mekanizması ile nesnelerin tipleri derleme zamanında değil çalışma zamanında belirlenmektedir. Bir nesnenin metodlarına veya propertylerine nasıl erişiyorsak, dynamic keyword ile yaratılan nesnelerin de property ve metodlarına aynı şekilde erişebiliriz. Tipler dinamik olarak yaratıldığı için çağrılan metod veya property ismi doğru yazılmalıdır. Çünkü metodun veya property’nin geçerli olup olmadığı çalışma zamanında belli olmaktadır. Fakat tip dinamik olduğu için kodu yazarken intellisense yardımı kullanılamamaktadır.
image
Optional Parameters
C# 4.0’a kadar C#’da bir metodumuza yeni bir parametre eklemek istediğimizde ve metodlarımızın çağrıldığı yerlerin bundan etkilenmesini istemediğimiz zaman metodlarımızın yeni parametreyle bir overload’unu yazmak durumunda kalıyorduk. Artık c# da da metodlarımıza optional olarak parametre ekleyebiliyoruz. Ve bu optional parametrelere default bir değer veriyoruz. Böylece bu metod çağırıldında eklediğimiz optional parametre kullanılmadan çağrılırsa o parametre metodta belirtilen default değerini alıyor.
image
Named Arguments
Named Arguments özelliği ile metod çağırımda parametre isimlerini yazarak argümanları gönderebiliriz. Böylece parametrelerin artık metodlardaki sırasıyla çağırılma zorunluluğu kalkmış olur. Veya iki tane opsiyonel parametremiz olduğu durumda metod imzasındaki sırasına göre ilkine değer göndermek istemeyip, ikincisine göndereceksek parametre ismini yazarak ikinci opsiyonel parametreyi gönderebiliriz.
image
Generic Variance
Generic Variance kavramından bahsetmeden önce aşağıdaki kavramlara göz gezdirelim.

Covariance:
Covariance (ortak değişken) özelliği bize tanımlanmış olan bir generic parametreden daha alt tipteki sınıfları göndermemize olanak sağlar.
Contravariance: "Contravariance" özelliği ise tanımlanmış bir generic parametreden daha üst tipteki sınıfları göndermemize olanak sağlar.
Invariant: tiplerin kullanıldığı yerlerde, belirtilen tipin birebir aynısının ele alınması gerekmektedir.

C# 4.0’dan önce generic koleksiyonlar invariant idi. C# 4.0 ile birlikte generic koleksiyonların covariant ve contravariant olmasına izin verildi.
C# 4.0 ile beraber güvenli "Co-Contra Variance" özelliği ile "Generic Delegate"(temsilci) ve arayüzler tanımlayabilmek için in ve out anahtar kelimeleri kullanılabilir. out T Covariant tip kullanımını sağlamaktadır.
Örneğin aşağıda verilen ExClass sınıfı T tipinde covariant’tır. Yani bir Foo<string> yaratılırsa, string object’in bir alt sınıfı olduğu, aynı zamanda bunu ExClass<object> olarak da kullanılabilir.
image
C# 4.0 ile birlikte bu örneği Ienumerable interface inde görebiliriz.
image
Bu arayüz covariant olduğu için bir IEnumerable<string> koleksiyonu IEnumerable<object> koleksiyonuna atanabilir. Burada hatırlanması gereken, "Out" ile tanımlanmış bir parametre sadece dönüş tipi olarak kullanılabileceğidir.
image
Out anahtar kelimesi de contravariant tip kullanımını sağlamaktadır. Örnekte görüleceği gibi contravariant tipteki parametreler sadece input pozisyonlarında(arguments) kullanılabilirler.
image
 COM Interop İyileştirmeleri
VS 2010 ile birlikte COM ile birlikte çalışabilirlik iyileştirmelerine de gidildi. Artık COM nesnelerine erişirken ref parametrelerine ref anahtar kelimesinin girilmesi zorunlu değildir. Optional Parameters desteğinin gelmesi ile metodlara bütün parametrelerin gönderilmesi zorunluluğu da ortadan kaldırılmıştır. Tiplerin dinamik olarak tanımlanabilmesi de COM ile çalışırken işimizi kolaylaştırmaktadır.
Özlem KARAGEDİK

Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara