C++, Java ve C# ile UML ve Dizayn Paternleri Kitabı Aykut Taşdelen


c++ java ve c# ile uml ve dizayn paternleri kitap
Kitapla ilgili detaylı bilgi için kitabın resmi web sitesini ziyaret edebilirsiniz

Reklamlar

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.

OOP’de Anti Pattern (Karşıt Kalıp) Olgusu

Fizik biliminde madde, 1920’lere kadar sadece pozitif yüklü parçacıklardan meydana gelen bir olgu biçiminde tanımlanıyordu. Bu yıllarda kuantum mekaniği ve izafiyet teorisinin çıkarımları fizikte bir devrime neden olmuştu. Ancak kuantum mekaniği, düşük hızlı parçacıklar için izafiyet teorisi ile paralellik arz etmekte ancak yüksek hızlı parçacıklar için yanlış ve çelişik sonuçlar ortaya çıkmaktaydı. 1928‘de Paul Dirac kendi ismiyle anılan bir çözüm ortaya koydu. Ancak Dirac denklemi parçacıkların sadece pozitif yüklü değil, negatif yüke de sahip olabilmesini öngörüyordu. Bu noktada madde tanımı yetersiz kalacağı için ortaya anti (karşıt) madde tanımı çıkmıştı. Bu öngörüye göre; evrendeki her maddenin bir karşıtı olabileceği fikri doğdu ve fizikçiler evrende, çeşitli biçimlerde anti madde avına çıkmaya hatta bunu laboratuar ortamına taşımaya başladılar. (bkz http://tr.wikipedia.org/wiki/Antimadde)

İlk kez 1995 yılında Andrew Koenig tarafından kullanılan Anti-Patern kavramı, anti madde kavramı gibi biraz soyuttur. Aslında anti-patern’ler de birer patern’dir… Üzerine yazılan bir kitapla iyice popüler hale gelen bu kavram; yazılımsal bir problemi bilinen ve doğru çözüm diye kabul edilmiş bir paterni kullanmadan ve özgün bir yöntemle çözmek anlamında kullanılmaktadır. Şüphesiz anti-patern kavramının bu diplomatik tanımının dışında pratikte kötü çözüm, kötü fikir gibi algılanan bir yönü de vardır. Bu pejoratif algının sebebi; çoğu zaman ilk bakışta mükemmel gibi görünen bir çözümün sonradan çokça baş ağrıtacak olma olasılığıdır. Dolayısıyla ilk bakışta doğruymuş gibi gelen birtakım anti-patern çözümlerden mümkün olduğunca kaçınılması gerekir.

Kötü çözümlerin anti pattern’ler adı altında dokümante edilmiş olmasının bir faydası da; programcıların bilinen bu kötü yöntemleri tanıması ve bunlardan uzak durmasını sağlamaktır. Bu anlamda anti pattern’ler olumsuz deneyim ve birikimlerin somutlaşmış halidir.

İpucu : Anti-patern’lere ilişkin bir liste “http://www.c2.com/cgi/wiki?AntiPatternsCatalog” sayfasından takip edilebilir.

Anti patern’lere örnek vermek gerekirse; spagetti kod yazımı ya da kodları “kopyala yapıştır” yöntemiyle yazmak gibi alışkanlıklar anti patern olarak sayılabilir. Bunlar her programcı tarafından yanlış olduğu bilinen kötü yöntemlerdir. Kısa vadede hız kazandırıyor gibi görünseler de en azından orta vadede kaçınılmaz sorunlara neden olabilirler. Aşağıda bilinen bazı birkaç ilginç antipatern örneği listelenmiştir :

Circular Dependency (Döngüsel Bağımlılık): Nesne veya modüllerin birbirlerini referanse etmesi yoluyla ortaya çıkan sıkı bağlılığın (tigth 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. Aşağıda bu antipaterne basit bir örnek verilmiştir.

[C++]

#include <cstdlib>
#include <iostream>

using namespace std;

class B;

class A  {
public:
B *b;
};

class B  {
public:
A *a;
};

int main(int argc, char *argv[])
{
A o1;
B o2;

o1.b = &o2;
o2.a = &o1;

system(“PAUSE”);

return EXIT_SUCCESS;
}

[C#, Java]

class A
{
public B b;
}

class B
{
public A a;
}

class Program {

public static void main()
{
A o1 = new A();
B o2 = new B();

o1.b = o2;
o2.a = o1;
}
}

God Object (Tanrısal Nesne) : Gereğinden çok şey bilen ve yapabilen nesnelere denilir. Yani çok fazla veri saklayan ve çok fazla sayıda metoda sahip olup da uygulamanın neredeyse ana fonksiyonlarını tek başına yerine getirebilen bir nesne kurgulamak bu anti paterne işaret eder.

Cargo Cult Programlama : Niye kullanıldığını bilmeden, arka planında yatan prensipleri anlamadan bir takım patern’leri sırf kullanmış olmak için kullanıp kod yazmaya verilen isimdir.

Error Hiding (Hata Gizleme) : Çalışma zamanında oluşan hataları exception handling mekanizmasıyla yakalamak ancak hata mesajlarını log’lamayarak gizlemek, adeta hatanın üstünü örtmek anlamına gelir. Bu özellikle uygulamaya destek veren kişileri zora sokacak bir antipaterndir.

Golden Hammer (Altın Çekiç) : Bir yöntemin mükemmel çözüm olduğuna inanıp her sorunu aynı yöntemle çözmeye çalışmak. Elinde çekiç olan birine tüm sorunlar çivi gibi görünür.

Boat Anchor (Tekne çıpası) : Daha sonra kullanılır düşüncesiyle yazılmış ama kullanılmayan bir kod parçasının uygulamadaki varlığını ifade eder. Böyle kodlar bazen test amacıyla da yazılmakta ve silinmesi unutulabilmektedir.

NOT : Bu yazı Aykut TAŞDELEN’in C++ Java ve C# ile UML ve Dizayn Paternleri kitabından alıntıdır izinsiz kullanılıp alıntı yapılamaz ! Konunun devamı söz konusu kitapta yer almaktadır.

C# ve Java’da Main Neden C++’taki gibi Global Fonksiyon Değildir ?

Nesne yönelimli programlamanın temel prensibi veya hedefi; problem alanındaki varlıkları nesnelere dönüştürürerek modellemek ve o şekilde ifade etmektir. Bu anlamda programın kendisi bile modellenebilecek bir varlıktır. İşletim sistemi tarafından çağrılan Main fonksiyonu bilindiği gibi uygulamanın tüm yaşam döngüsünü geçirdiği ana fonksiyondur. Dolayısıyla bu işlevi yerine getiren fonksiyonun yani Main’in uygulamayı temsil eden, modelleyen sınıfın içinde bulunması doğaldır. C# ve Java’da Main’in global olamamasına ilişkin tercihin nedeni bu şekilde açıklanabilir.

Okumaya devam et

Dizayn Patern Nedir ? What is design pattern ?

Son günlerde bu sorunun arama motorlarında sıkça aratıldığını görüyorum. Bu konu hakkında geniş bilgi için C++, Java ve C# ile UML ve Dizayn Paternleri isimli kitabımdan faydalanabilirsiniz. Aşağıdaki yazı söz konusu kitaptan kısa bir alıntı olup izinsiz ve referans vermeden kullanılamaz.

c++ java ve c# ile uml ve dizayn paternleri kitap

c++ java ve c# ile uml ve dizayn paternleri kitap

Okumaya devam et