‪Microsoft‬ .NET ‪Framework‬ çekirdek kodlarını ‪github‬’da paylaşmaya başladı

Şahsım adına yıllardır Microsoft’un bir çıkmazda olduğunu bunun da gerekçesinin son 4-5 yıldır dişe dokunur yeni bir paradigma ortaya çıkaramamalarına bilhassa da bu süreçte mobil dünyadaki gelişmeleri ıskalamış olmalarına bağlıyor bunu da her ortamda dillendiriyordum. Hatta bu gidişin Microsoft’un başına zamanında ‪#‎IBM‬’in başına gelen şeyi getireceğini söylüyordum. Sanırım son kertede yaşanan pratik beni haklı çıkardı.

Bu sözlerime bakıp da beni bir Microsoft düşmanı vs diye nitelendirmeyin zira 2002’den beridir .NET üzerine de eğitimler veren Microsoft’un üst üste 7 kez ‪#‎MVP‬ unvanı verdiği, ‪#‎INETA‬ (uluslararası .net birliğinde) ortadoğu afrika ve Türkiye başkanlıkları yapmış birisiyim. Halen de çalıştığım üniversitede ‪#‎Android‬ dersleri dışında inatla ‪#‎WindowsPhone‬, ‪‎ASP.NET‬ ‪#MVC‬ gibi dersler de veriyorum. Bu gelişmeyi de kendi adıma Microsoft’un “can havliyle” ‪#‎opensource‬ dünyasından medet ummasına bağlıyorum. Bu sayede Android, IOS, Linux, Macosx gibi sistemlerde uygulama geliştirebilmek ya da GlassFish, JBoss, Apache gibi web server’larda ASP.NET uygulamalarını çalıştırabilmek gibi ütopyaları gerçekleştirebilmek mümkün olacak. Şüphesiz bunu Java ölecek gibi yorumlayıp üzülenler de olmuş ama ben bu tedirginliği pek mantıklı bulmuyorum doğrusu.

Diğer yandan anlam veremediğim şey ise şu; Microsoft zaten yıllardır Framework’ün kaynak kodlarını açık tutuyordu hatta ‪#‎Mono‬, ‪#‎Rotor‬ gibi projeler bu şekilde ortaya çıkmıştı. Hatta Microsoft yıllardır  “dotnet” ismini bir marka gibi konumlamaktan vazgeçip ürün gibi konumlamayı seçmişti. Yani dotnet bir selpak değil kağıt mendildir vurgusunu yapıyordu. Diğer taraftan bu altyapının standartlarını ise CLI (Common Language Infrastructure) adı altında standardizasyona sokmuştu (ECMA – 335 standartları).

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf

Microsoft’un resmi söylemlerine göre Mono’nun ayrı bir kod tabanı olduğu yani onun sıfırdan yazıldığı rotor’un ise open source lisansının olmadığı ve bazı uyumsuzluklarının olduğu yönünde. Bu noktada özellikle NuGet ve sıra dışı programlama vurgusu yapıyor. Enteresan noktalardan birisi de Microsoft’un bu konuda XAMARINE isimli firmayla bir tür ortak çalışma yapıyor olması. Malumunuzdur bu firma monodroid, monotouch gibi android ve ios üzerine .net ile uygulama geliştirmenin yolunu açan cross platform araçları geliştirmişti.

Yani “sanki” bütünüyle yeni olmayan bir durumu Microsoft’un çok yeni birşey yapmış gibi bir PR malzemesi haline daha getirmeye çalıştığını düşünüyor, sizlerin de yorumlarını merak ediyorum. Bu arada kodlar aşağıdaki adrese “kısmen” upload edilmiş. https://github.com/dotnet/corefx

Reklamlar

C++ Saf Sanal Fonksiyonlar, Overriding ve Polimorfizm

Dikkat : Aşağıdaki yazı C++, Java, C# ile UML ve Dizayn Paternleri kitabımdan sınırlı bir alıntıdır. Dolayısıyla bu yazının izinsiz kopyalanması suç kapsamına girmektedir. 

Sanallık mekanizması türemiş sınıf yoluyla taban sınıfın davranışlarının değiştirilmesi için kullanılır. C++ programlama dilinde şayet taban sınıftaki bir fonksiyon virtual anahtar sözcüğü ile tanımlanmışsa fonksiyon sanal hale gelir. Bunun pratik anlamı fonksiyonun üyesi olduğu sınıftan türetme yapıldığında türeyen sınıfın söz konusu fonksiyonun davranışını değiştirebileceğidir.

#include "stdafx.h" 
#include <iostream> 
using namespace std;
class A 
{
public:     
    void Foo()    
    {        
        cout << "A::Foo" << endl;    
    } 
};
class B : public A 
{ 
public:     
    void Foo()     
    {         
        cout << "B::Foo" << endl;      
    } 
};
int main() 
{      
    A *obj = new B();      
    obj -> Foo();      
    return 0; 
}

Dikkat edilirse obj isimli gösterici (pointer) A taban sınıfı türünde olup, göstericiye B sınıfı türünde bir adres atanmıştır. Bu durum literatürde Liskov’un yerine geçme prensibi olarak isimlendirilir.

uml ve dizayn paternleri

C++ Java ve C# ile UML ve Dizayn Paternleri

Yukarıdaki örneğin çıktısı A::Foo şeklinde olacaktır zira çağrılan Foo fonksiyonu  sanal değildir başka bir deyişle A sınıfına ilişkin Foo çalışmıştır. Oysa Foo aşağıdaki sanal hale getirilirse;

 
#include "stdafx.h"
#include <iostream>

using namespace std;

class A
{
public:
   virtual void Foo()
   {
       cout << "A::Foo" << endl;
   }
};

class B : public A
{
public:
    void Foo() 
    {
        cout << "B::Foo" << endl; 
    }
};

int main()
{

     A *obj = new B();

     obj -> Foo();

     return 0;
}

Bu kez çıktı B::Foo şeklinde olacaktır. C++ 11 ile gelen override anahtar sözcüğü ise opsiyoneldir ve bu noktada kullanımının farklı bir etkisi  olmayacaktır.

class B : public A
{
public:
    void Foo()  override
    {
        cout << "B::Foo" << endl; 
    }
};

C++’ta saf sanal fonksiyonlar ise soyut yani abstract sınıflar içerisindeki implementasyon kodu bulunmayan fonksiyonlardır. Bir sınıfın soyut  olabilmesi için bir tane saf sanal fonksiyona sahip olması yeterlidir. Örneğin aşağıdaki A sınıfı soyut Foo() ise saf sanaldır :

class A
{
public:
      virtual void Foo() = 0; 
};

Buradaki sıfır ataması aslında bir atama değil sadece fonksiyonun saf sanal (pure virtual) olduğunu sintaks açısından gösteren bir dil kuralıdır.

O halde böyle bir fonksiyon ne amaçla yazılmıştır ya da ne zaman anlamlı şekilde kullanılabilir ? Bu soruların cevabı; çok biçimlilik yani  polimorfizmdir.

#include "stdafx.h"
#include <iostream>
using namespace std;
class A
{
public:
       virtual void Foo() = 0; 
};
class B : public A
{
public:
      void Foo() override
      {
              cout << "B::Foo" << endl;
      }
};
class C : public A
{
public:
      void Foo() override
      {
               cout << "C::Foo" << endl;
      }
};
///////////// GLOBAL ///////////////
void Test(A *a)
{
         a -> Foo();
}
int main()
{
         Test(new B());
         Test(new C());
         return 0;
}

Yukarıdaki örnekte A soyut sınıfından iki sınıf (B ve C) türetilmiş ve Foo() fonksiyonu bu sınıflarda farklı şekillerde override edilmiştir. Ayrıca   Test(A *a)    isimli global bir fonksiyon yazılmıştır.  main içerisinde Test(), B ve C türündeki nesneler parametre geçilerek çağırıldığında bu iki nesne için farklı davranış göstermiştir. Yani çok biçimli veya polimorfik davranmıştır.

Polimorfizmin marjinal faydası; ileriye uyumluluktur. Bu örnek üzerinden gidilirse sisteme yeni eklenecek olan bir sınıf örneğin D için Test() fonksiyonunun kodunda herhangi bir değişikliğe ihtiyaç yoktur.

class D : public A
{
public:
    void Foo() override
    {
        cout << "D::Foo" << endl;
    }
};
///////////// GLOBAL ///////////////
void Test(A *a)
{
      a -> Foo();
}
int main()
{
     Test(new B());
     Test(new C());
     Test(new D());
     return 0;
}

Dikkat : 

C++’ta saf sanal fonksiyonlara “genellikle” implementasyona yönelik kodlama yapılmaz. Ama bu bir kural değildir yani istenirse yapılabilir :

virtual void Foo() = 0
 {
    cout << "A::Foo" << endl;
 }

Yukarıdaki kod geçerlidir. Oysa C# ve Java’da saf sanal fonksiyonların karşılığı olan soyut abstract metotlara “asla” implementasyon yapılamaz. Bu dillerde aynı durum  interface içindeki üyeler için de geçerlidir.

Sonuç :

  • Polimorfizm nesne yönelimli programlamanın temel prensiplerinden birisi olup geleceğe uyumlu kod yazabilmeyi sağlar.
  • Sanallık, polimorfizm’in anahtarı olmasına rağmen doğru gerekçelerle kullanılmalıdır ve performans maliyeti olduğu akıldan çıkarılmamalıdır. Maliyetin sebebi; late binding ya da diğer adıyla dinamik binding (bağdaştırma) işleminin çalışma zamanında virtual table mekanizması yoluyla gerçekleşmesidir.

Referanslar : 

1. K ASLAN. C++ Ders Notları, C ve Sistem Programcıları Derneği 

2. A TAŞDELEN. UML ve Dizayn Paternleri (C++, Java ve C# ile), Pusula Yayıncılık

Overt Coupling & C++ Friend Class

C++ Friend Sınıf Mekanizması Overt Coupling’e Neden Olur

Bir sınıf başka bir sınıfa ilişkin üyeleri belli bir izin dahilinde kullanıyorsa aralarında overt coupling söz konusudur. Örneğin C++ programlama dilindeki friend anahtar sözcüğüyle belirlenen arkadaş sınıf mekanizması overt coupling’e neden olur. Hatırlanacağı üzere friend sınıf mekanizması, arkadaşlığın tanımlanmış olduğu sınıfa, arkadaşlığın tanımlandığı sınıfın private ve protected üyelerine özel bir erişim yetkisi vermek demektir.

Okumaya devam et

C++ Header File Circular Dependency Problem & Forward Declaration

Circular Dependency (Döngüsel Bağımlılık) bir antipatern’dir. Nesne veya modüllerin birbirlerini referanse etmesi yoluyla ortaya çıkan sıkı bağlılığın (tigthly coupling) neden olduğu olumsuz bir durumdur. Referans sayma yöntemiyle çalışan garbage collector’lerde (çöp toplayıcılarda) memory leak’lerin oluşması gibi sorunlara neden olabilir. Ayrıca bu tarz modüllerin birisinde yapılacak bir değişikliğin domino etkisi yaratması olasıdır.

C++ programlama dili özelinde include edilmesi gereken header (başlık) dosyaları bu duruma neden olabilir. Örneğin A sınıfının B sınıfı türünde bir pointer’a (göstericiye), B sınıfının da A sınıfı türünde bir pointer’a sahip olduğunu düşünelim.

Okumaya devam et

C#’ta Sanallık Mekanizması

Önceki yazımda C#’ta sanal olan metotların sanallığının yok edilemeyeceğini ispat etmiştim. Ancak bu yazıya gelen yorumlar üzerine şunu da ilave etmek isterim ki; bir konuda yeterince bilgi sahibi olmadan fikir beyan etmek gibi de iflah olmaz bir hastalığımız var. Üstelik de hem yeterince bilmiyoruz hem de yeterince okumuyor, denemiyor, araştırmıyor fakat fikir beyan etmekten kendimizi alamıyoruz. Sevgili dostlar tartışmakta olduğumuz şey teknik ve bilimsel bir konudur. Bilimsellik bir şeyin körlemesine aksini iddia etmenin ötesinde onu ampirik olarak yani deneysel olarak ispat etmeyi gerektirir. Aksi dogmatizm’dir. Lütfen siz de benim gibi durumu deneyle ispat ederek yorum yapın.

Şimdi, bu kez de Mustafa bey alınmasınlar ama aşağıdaki gibi bir yorum göndermişler :
…………….

Aykut Hocam, Burada “virtual” anahtar kelimesinden ziyade “sanallık” kavramına vurgu var. Amaç, mirasçı sınıfın miras aldığı sınıfa ait sanal bir fonksiyonu  ezmesini engellemek için sanallığını kaldırmak, başka bir ifadeyle sanal bir üye gibi davranmasını engellemek. .NET Framework altyapısında virtual ve sealed anahtar kelimelerinin birlikte kullanımıyla bu amaca ulaşılmış oluyor. Bu makale bize bunu gösterdi. Reflection ile baktığınızda ya da IL kodunu incelediğinizde elde ettiğiniz sonuç, paylaşılan bilginin yanlışlığını ispat edecek nitelikte değil. Burada anlamlı olan “virtual” ve “sealed” anahtar  kelimelerinin birlikte kullanımıyla elde edilen sonuçtur. Sonuç kısmındaki siteminizle ilgili de fikrimi paylaşmak isterim. Yabancı sitelerdeki makaleleri Türkçe’ye çevirip kendi bilgi birikimlerini katmadan paylaşım yapan insanların sayısı azalmaya başladı. Bilişim profesyonelleri, özgün çalışmaların ve bu  çalışmalara ait paylaşımların daha değerli olduğunu görmeye başladı. Osman Pirci’nin paylaşımı da bu nitelikte değerlendirilebilir.
(Mustafa Samet Üçgün)

…………….
Mustafa bey; yanlış bilginizi düzeltmek isterim “burada “virtual” anahtar kelimesinden ziyade “sanallık” kavramına vurgu var” demişsiniz ancak C#’ta sanallık fenomenini ortaya çıkaran bizzat virtual anahtar sözcüğüdür. Yani virtual kelimesini yok edemediğiniz sürece sanallığı ortadan kaldıramazsınız. Yani bu örnek  dediğiniz gibi olmayıp tam aksine “paylaşılan bilginin yanlışlığını ispat edecek nitelikte” maalesef. Şimdi ben size bunu ispat edeyim. (Yalnız küçük bir  bilgi notu; C#’ta sanallık ya virtual ile sağlanır ya da soyut sınıf içindeki soyut fonksiyonla, ki biz buna C++’ta saf sanal fonksiyon da deriz.)

Adım adım ilerleyelim :

1) Sanallık virtual ile olur, miras alınmayla değil. Örneğin aşağıda A::Foo sanal değildir fakat B ve C tarafından miras alınmaktadır :
class A
{
public void Foo()
{
Console.WriteLine(“A::Foo”);
}
}

class B : A
{
public void Foo()
{
Console.WriteLine(“B::Foo”);
}
}

class C : A
{
public void Foo()
{
Console.WriteLine(“C::Foo”);
}
}

Burada A::Foo virtual yani sanal olmadığı için override da edilemez ve aşağıdaki durumda polimorfik davranış oluşmaz sadece shadowing olur.

A obj1 = new B();
obj1.Foo(); // A::Foo yazar

A obj2 = new C();
obj2.Foo(); // A::Foo yazar

Zira her ikisinde de ekrana A::Foo yazılır.
2) A::Foo virtual ile sanal hale getirilirse ayrıca B ve C’de override edilirse polimorfizm sağlanır.
class A
{
public virtual void Foo()
{
Console.WriteLine(“A::Foo”);
}
}

class B : A
{
public override void Foo()
{
Console.WriteLine(“B::Foo”);
}
}

class C : A
{
public override void Foo()
{
Console.WriteLine(“C::Foo”);
}
}
A obj1 = new B();
obj1.Foo(); // B::Foo yazar

A obj2 = new C();
obj2.Foo(); // C::Foo yazar

3) Asıl konuya geldik. Foo metodu B’de override edilirken sealed ile somut hale getirilirse bu durum A::Foo’nun sanallığını etkilemez sadece B’den D gibi bir sınıf daha türetilmek istenirse B::Foo final hale geldiği için miras alınamaz. Tekrar ediyorum A::Foo halen sanaldır ve bunun ispatı önceki yazıdadır. Öte yandan A::Foo için polimorfik davranış da halen devam etmektedir.

class A
{
public virtual void Foo()
{
Console.WriteLine(“A::Foo”);
}
}

class B : A
{
public override sealed void Foo()
{
Console.WriteLine(“B::Foo”);
}
}

class D : B
{
/* public override void Foo()
{
B::Fo0 final olduğu için hatadır !
}
*/
}

class C : A
{
public override void Foo()
{
Console.WriteLine(“C::Foo”);
}
}

A obj1 = new B();
obj1.Foo(); // B::Foo yazar

A obj2 = new C();
obj2.Foo(); // C::Foo yazar

Buradaki tartışma tamamen teknik niteliktedir kişisel hiç bir boyutu yoktur.

UML Dizayn Patern Eğitimi İgdaş 2

Bu yıl İgdaş’ta 2.si gerçekleşen UML ve Dizayn Patern eğitimi bu hafta sonu tamamlandı. UML ile çeşitli modellemeler yaptığımız farklı diyagramları incelediğimiz eğitimin diğer kısmında ise dizayn prensipleri ve gof dizayn paternlerini ele aldık. Eğitimin gerçekleşmesinde yoğun emeği olan Fatih bey ve Natalya hanıma teşekkürler.

uml-design-patern-egitimi-igdas-2

uml-design-patern-egitimi-igdas-2