Herkese merhaba,

Hiç bilmeyenler için değişkenleri, yazılımda herhangi bir veriyi sakladığımız birer kutu gibi düşünebiliriz.

Gerçek hayattan kutu örneğiyle devam edersek; bu kutuların (değişken) içerisinde birer veri saklandığını (değişkenin değeri), kutuların farklı ebatlarda olabileceğini (değişken boyutu), saklanan her verinin farklı tiplerde (değişkenin türü) olabileceğini ve kutuların üstüne de birer isim yazdığımızı (değişkenin adı) düşünebiliriz.

Değişken Tipleri

Şimdi değişkenleri genel olarak bir tabloda, tip, boyut, aralık ve CTS karşılıkları olarak inceleyelim.

Yukarıdaki tabloda CTS (Common Type System) karşılıkları kısmında CTS kavramını ilk kez görenler, detaylar için Bir .exe Uygulamasının Anatomisi (CLR, CIL, JIT, CTS Kavramları) başlıklı yazımdaki “CTS (Common Type System) Nedir?” kısmını okuyabilir.

Yukarıdaki tabloya bakarak gerçek hayattan örneklemeye devam edersek tip için kutunun tipini, boyut için kutunun ebatını, aralık için kutunun taşıyabileceği içeriğin hacminin en alt ve en üst limitlerini, CTS karşılıkları için de kutunun evrensel olarak kabul görmüş dünyanın neresine giderseniz gidin kutu dünyasında standartlaşmış bir adı olarak düşünebiliriz.

Akıllara hemen “C#’ta neden farklı farklı değişken tipleri ve bunların farklı boyutları, kapasiteleri var ki? Tek bir tane değişken türü olsa da bu kadar uğraşmasak olmaz mıydı?” gibi bir soru gelebilir. Elbette tek bir veri tipi olması biz yazılım geliştirenlerin işini bir hayli kolaylaştıracaktı ancak yazılım geliştirmede yalnızca kod yazan kişiler olarak kendi kolaylıklarımızdan sorumlu değiliz. Geliştirdiğimiz her yazılımın tükettiği kaynaklar mevcut. Tüketilen kaynakları optimum kullanmak da bizlerin sorumluluğu arasındadır. Elimizdeki kaynakları ne kadar iyi kullandığımız bizlerin ne kadar iyi birer yazılım geliştirici olduğunu gösteren bir faktördür. Önceden belirlenmiş değişken tiplerinin ve boyutlarının olmasının sebebi .NET Framework’ün, yazılım içerisinde kullanacağımız verinin tipini bilmek istemesinden kaynaklanmaktadır. .NET framework veri tipini bilmek istiyor çünkü elindeki memory kaynağını ona göre organize edecektir. Bu sebeple bu kadar farklı veri tipi ve önceden belirlenmiş standart boyutları ve aralıkları bulunmaktadır.

Gerçek hayattan örnek vermemiz gerekirse, evden eve taşıma yapan her şey dahil bir nakliye firmanızın olduğunu ve elinizde büyük küçük çeşitli kamyonetlerin, kamyonların, tırların yer aldığını düşünün. Bir müşterinin sizi aradığını ve eşyasını İstanbul’dan Hakkari’ye taşıtmak istediğini varsayalım. Firma olarak maliyeti belirlemek ve müşteriye de sunduğunuz hizmet için bir fiyat verebilmek için müşterinin eşyasının miktarını bilmeniz gerekir ki buna uygun kamyonet, kamyon veya tır seçip o eşyayı en uygun araca yükleyebilesiniz. Yalnızca bir koltuk ve bir televizyonu olan bir müşteri için koca bir tır’ı İstanbul’dan Hakkari’ye gönderir miydiniz? Yoksa daha uygun ve maliyetinizi azaltacak küçük bir kamyonet işinizi zaten çok güzel görmez miydi? Bu sayede siz kamyoneti yola çıkardığınızda çok daha fazla eşyası olan başka bir müşteri için tırınız hazırda beklerdi :)

İşte bu örnekten de anlaşılacağı üzere, .NET Framework de kod yazarken veriyi saklayacağı tipin kendisine bildirilmesini istiyor ki ona uygun hafızada yerini ayırabilsin. Kullanacağınız verinin tipine göre seçim yapmak oldukça isabetli olacaktır.

Value Type ve Reference Type Nedir?

C#’ta tipler “value type (değer tipi)” ve “reference type (referans tipi)” olarak ikiye ayrılır.

Value Type (Değer Tipi): C#’ta kullanılan value type’lar önceden boyutu kesin olarak belirlenmiş, içerisinde direkt olarak veri tutan tiplerdir. Yukarıdaki değişken tablosunda boyut sütununa bir bakalım. Boyutlarının kesin olarak byte karşılıkları yazan değişken tiplerinin hepsi (int, long, float, double, decimal, char, bool, byte, short) birer value type’dır.

Reference Type (Referans Tipi): İçerisinde direkt olarak veriyi değil, verinin tutulduğu hafıza adresini barındıran yani referansını tutan tiplerdir. Yine yukarıdaki değişken tablosuna baktığımızda string’in belirli bir boyutu olmadığını görürüz. Bu sebeple string’e value type diyemeyiz. string bir reference type’dır.

Kod içerisinde bir tipin value type olup olmadığını öğrenmenin oldukça basit bir yöntemi vardır. Örneğin int tipinin kodda value type olup olmadığını aşağıdaki paylaştığım küçük kod parçası sayesinde öğrenebiliriz.

bool kontrol = typeof(int).IsValueType;

IsValueType property’si sayesinde bir tipin value type olup olmadığını kolayca öğrenebiliriz.

Stack ve Heap Kavramları Nedir?

Stack ve Heap, memory’de (RAM/bellek) bulunan mantıksal yapılardır. Bu yapıların detaylarına geçmeden önce stack’in kısıtlı ama hızlı, heap’in ise stack’e görece daha geniş bir alana ama yine stack’e göre daha yavaş bir yapıya sahip olduğunu bilmek işimize yarayacaktır.

Stack

• Value Type’lar (Değer Tipleri) Stack’te tutulur.
• Stack’te veriler üst üste ve son giren ilk çıkar (LIFO — Last In First Out) mantığıyla tutulur ve sırası gelmeden aradaki bir değer ile işlem yapılmaz.
• Stack’te bir veriye erişmek, Heap’e göre daha hızlıdır.
• Oluşturulan veriler Stack’in kapsamında çıkınca otomatik olarak yok edilir.
• Program çalışmadan önce Stack’te yer ayrılır. Eğer yazılımı geliştiren kişi tarafından bu bölüm aşılırsa meşhur Stackoverflow hatası ile karşılaşılır.

Heap

• Reference Type’ların (Referans tiplerin) değeri Heap’te, değerin Heap’te saklandığı adresin bilgisi ise Stack’te tutulur. (Yani bir reference type saklanırken memory’nin hem Heap bölgesi hem de Stack bölgesi kullanılmaktadır. Dikkat edilmesi gereken referans tipin değerinin Heap’te saklanırken, o değerin adresinin Stack’te saklandığıdır.)
• Heap’te veriler karışık bir şekilde tutulur, Stack gibi belirli bir sırada tutulmaz.
• Heap bölgesindeki bir veriye erişmek, Stack’e oranla daha maliyetlidir (yavaştır).
• Heap bölgesindeki bir verinin silinmesi C# için Garbage Collector algoritmasına bağlıdır.
• Program çalıştırılmadan önce yer ayrılmaz, programın çalışma zamanında yer ayrılır.

Boxing ve Unboxing Kavramları Nedir?

Boxing

Boxing işlemi, value type (değer tipi) bir değişkeni, reference type (referans tipi) bir nesneye aktarmaya denir.

int sayi = 123; // value type bir degisken tanimlandi

object obje = sayi; // bu atamada sayi degiskenine dolaylı olarak (implicity) boxing islemi uygulandi

Unboxing

Reference type (referans tipi) değişkenin işaret ettiği değeri, value type (değer tipi) bir değişkene aktarmaya denir.

int sayi1 = 123; //value type degisken tanimlandi ve degeri atandi

object obje = sayi1; // Boxing islemi

int sayi2 = (int)obje; // Unboxing islemi

Not: Unboxing işlemi gerçekleştirilirken, boxing işleminde kullanılan veri tipinin aynısının kullanıldığına dikkat edilmelidir. Aksi hale veri tipleri uyuşmayacağından InvalidCastException hatası alınacaktır.

Boxing ve Unboxing Hakkında Ek Bilgiler

• Boxing işlemi, normal bir atama işleminden 20 kat daha uzun sürmektedir.
• Unboxing işlemi, normal bir atama işleminden 4 kat daha uzun sürmektedir.
• Bu sebeplerden dolayı gerekli olmayan aşırı boxing ve unboxing kullanımı uygulamanızı gözle görülür biçimde yavaşlatacaktır.

Veri Serisi’nin ilk makalesi olan Değişkenler’in böylece sonuna geldik. Herkese keyifli kodlamalar dilerim :)!

Bu yazı ilk olarak http://cozvelioglu.com/cta-degiskenler-valuetype-reference-type-stack-heap-kavramlari-boxing-unboxing-kavramlari-veri-serisi-degiskenler/ adresinde yayınlanmıştır.

C#’ta Değişkenler (ValueType-Reference Type, Stack-Heap Kavramları, Boxing-Unboxing Kavramları )… was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Herkese merhaba,

C# ile hangi platform için yazılım geliştirirsek geliştirelim işin özünde hepimiz ortak bir paydada buluşuyoruz; tek kelimeyle: ‘veri’. Bir masaüstü uygulaması da yazsak, ASP.NET ile bir web uygulaması da geliştirsek, ortak kaygımız hep verinin alınması/işlenmesi oluyor. Bir kullanıcının sisteme login olurken kullanıcı adı ve şifresini alıp kontrollerinin gerçekleştirilmesinden, bir hastane otomasyonu yazılımında ilgili hastayı bulmak ve bilgilerine erişmek gibi ve bunu çok daha farklı örneklerle arttırsak dahi işimiz özünde bir veriyi bulmak, o veriyi güncellemek, eklemek, silmek gibi işlemler oluyor. Bu sebeple C#’ta yazılım geliştirirken bir veriyi kod içerisinde tuttuğumuz değişkenlerden, efektif veri kullanımı için seçeceğimiz veri yapısına kadar hepsi bir bütün olarak performansa, sistemin kararlılığına etki eden birer kriter oluyor. İşte ‘Veri Serisi’ adını verdiğim seri ile aşağıda maddeler halinde yazdığım başlıkları birer arşiv oluşturması amacıyla yazmaya başlıyorum.

1. Değişkenler (Variables)

• Değişken tipleri
• Value Type/Reference Type Nedir?
• Stack/Heap Kavramları
• Boxing/Unboxing Kavramları

2. Diziler (Arrays)

• Array’lere genel bakış
• Tek boyutlu array’ler/Çok boyutlu array’ler

3. Generic Olmayan Koleksiyonlar (Non-Generic Collections) (Alt başlık olarak geçen her bir madde ayrı birer makale konusu olacaktır)

• ArrayList
• Stack
• Queue
• Hashtable
• SortedList

4. Generic Koleksiyonlar (Generic Collections) (Alt başlık olarak geçen her bir madde ayrı birer makale konusu olacaktır)

• List<T>,
• Stack<T>
• Queue<T>
• Dictionary<K,T>
• SortedDictionary<K,T>

Yukarıdaki makalesi tamamlanan başlığı link olarak zaman içerisinde ekleyeceğim :)

Çok fazla içerik kabul edilemeyecek bu yazıyı aslında bir serinin başlangıcını ve serideki içeriklere hızlı erişim amaçlı bir indeksleme olarak düşünebilirsiniz. Katkı sağlamak istediğiniz ek maddeler ve konular olursa yorumlarda belirtirseniz çok sevinirim.

Herkese keyifli kodlamalar :)!

Bu yazı ilk olarak http://cozvelioglu.com/c-ile-yazilim-gelistirmede-veri-serisi-veri-serisi-baslangic/ adresinde yayınlanmıştır.

C# ile Yazılım Geliştirmede Veri Serisi [Veri Serisi — Başlangıç] was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Herkese merhaba,

Uzunca bir süre yazmaya ara vermiştim, bu süreçte eski yazılarımla ilgili o kadar güzel feedbackler aldım ki geri döneceğim zaman aslında sadece kendime notlar alırım diye çıktığım bu yolun farklı bir sorumluluk yüklediğini de böylece fark etmiş oldum. Pandemi, karantina, evden çalışma derken hepimizin uzunca saatlerini evde bilgisayar başında geçirdiği şu günlerde kod yazarken en büyük destekçilerimden olan Spotify Desktop versiyonu ile müzik dinlerken bir ışık yandı zihnimde. .NET Framework’te çalışan bir exe programını ameliyat masasına yatırıp tüm süreci baştan sona kısaca incelemek. Bu sebeple bu yazımda zaman zaman benim de karıştırdığım/detaylarını hatırlamakta güçlük çektiğim CLR, CIL, JIT, CTS gibi kavramları masaya yatıracağız. Yolu desktop programlarıyla kesişen herkesin bilmesinde fayda olan bu kavramları inceleyeceğiz.

Sözü fazla uzatmadan en güzel öğrenme şeklinin diyagramlar/tablolar/görsellerle desteklendiğine olan sonsuz inancım sebebiyle bir .NET uygulamasının çalışması için bir araya gelen bileşenleri içeren şu görselle başlayalım.

Bu kavramları daha iyi idrak edebilmek adına iki kavramın üstünden hızlıca geçmemiz faydalı olacaktır. Diyagramda yer alan her bir bileşeni masaya yatırıp çok derinlerine dalmadan fakat suya da yazı yazmadan inceleyeceğiz :)

Compile Time ve Run Time Nedir?

Compile Time (Derleme Zamanı)

Compile işlemi; oldukça basit ve akılda kalıcı bir izahla “yüksek seviyeli bir dilin daha düşük seviyeli bir dile dönüştürülmesi işlemidir”. Yani biz yazılım geliştiriciler tarafından yazılmış kod, compile işleminden sonra makinelerin seviyesine yaklaşmaktadır. İşte bu işlemi gerçekleştiren mekanizmaya Compiler(Derleyici) derken, bu süreçte yaşanan tüm işlemleri zaman açısından anlatmak için de Compile Time (Derleme Zamanı) kavramını kullanmaktayız. Yukarıdaki compiler diyagramında Compilation Error kısmı ise, yüksek seviyeli bir dilin compile edilme işlemi sırasında oluşan hataları anlatmaktadır. Compile Time hatalarının en güzel tarafı .exe dosyası daha oluşturulmadan derleme işlemi sırasında hata alınmasıdır. ‘Syntax Error (Sözdizimi Hatası)’ hatasını Compilation Error’a örnek olarak verebiliriz.

Run Time (Çalışma Zamanı)

Programın çalıştırıldığı andan sonlandırılıncaya kadar geçen süreci anlatmak için kullanılan kavramdır. Compile Time’da olduğu gibi Run Time’da da hatalar almak pek mümkündür ki aslında kıyaslandığında en acı senaryo Run Time errorlardır. Bazen bir run time hatasını bulmak için çok fazla efor sarfetmek gerekebilir. Basitçe yine neleri Run Time Error’a örnek olarak verebiliriz diye düşündüğümüzde aşağıdaki örnek maddeler en azından bu kavramı daha iyi idrak etmeye yardımcı olacaktır;

• Bellek yetersiz hatası
• Programda bir dosya için işlem yapacağımızı düşünelim ve bu dosyanın yolunu kod içerisinden sabit bir şekilde verdiğimizi düşünelim. Kod burada compile işlemini başarıyla geçecektir ve program çalıştırıldığında eğer kodda belirttiğimiz dosya yolunda ilgili dosya bulunamazsa hata oluşacaktır. Bu hata örneği compilation error ve run time error arasındaki farkı güzel bir şekilde idrak etmeye yardımcı olacaktır.

Compile Time ve Run Time kavramlarına da neşter vurarak damarlarında gezindiğimize göre ana konumuza tekrar geri dönelim. Bir .exe uzantılı programın .NET Framework’te çalışması için yazdığımız kod öncelikle compile işlemiyle daha düşük seviyeli bir dile çevriliyor. Yukarıdaki görselde de görüleceği üzere VB.NET ile yazılmış bir kod .NET Framework içerisinde yer alan VB.NET compiler ile, C# ile yazılmış bir kod C# Compiler ile ve F#/C++ gibi dillerle yazılmış kodlar da yine .NET Framework içerisinde yer alan o dile özgü compilerlar ile compile edilmektedir. Bu kısımdan itibaren önemli olan şey tüm bu farklı dillerde yazılan kodlar compilation sonrası CIL (Common Intermediate Language) denilen bir ara dile çevrilmektedir.

O halde ana diyagramımızdan nerede olduğumuza geri dönüp bir bakacak olursak şu anda yazdığımız kodu compile ettik ve CIL (Common Intermediate Language) oluştu. Derleme işlemi sırasında bir hata oluşmadıysa artık Compile Time’ı sorunsuz bir şekilde aşmış bulunuyoruz. Şimdi CIL (Common Intermediate Language) nedir, biraz da bu kavramı inceleyelim.

CIL (Common Intermediate Language) Nedir?

CIL veya .NET Framework için MSIL olarak adlandırılır. Türkçe’ye Ortak Ara Dil olarak çevrilmektedir ve ara dil olarak nitelendirilmesinin sebebi; C# kadar yüksek seviyeli yani bir insanın rahatça anlayabileceği kadar kolay bir dil olmamasına karşın, makine dili kadar da insandan uzak bir dil değildir.

Compilation işlemi sonrası CIL’e dönüştürülen kodlarımız exe dosyası olarak kaydedilir. Bu aşamadan itibaren artık çalıştırılabilir bir executable file’ımız mevcuttur. Burada dikkat edersek .exe içerisinde direkt olarak makine kodları yer almamaktadır, yazdığımız koddan CIL’e dönüştürülmüş kodlar yer almaktadır. Bu sebeple exe dosyasının çalışması için makinede muhakkak .NET Framework’ün yer alması gerekmektedir. Çünkü çalıştırma işlemini .NET Framework içerisindeki CLR mekanizması gerçekleştirecektir.

Not: Bir exe dosyasını compile edildikten sonra direkt olarak başka birisine verdiğimizde aslında bir bakıma projenin kaynak kodlarını da vermiş oluyoruz. Decompiler’lar aracılığı ile eğer herhangi bir şifreleme algoritması veya güvenlik aracı ile exe’mizi şifrelemezsek kolayca kaynak koduna erişilebileceğini unutmayalım.

CIL içerisinde Metadata olarak adlandırılan bir yapı daha vardır. Metadata programda kullanılan veri tiplerini, oluşturduğumuz sınıfları, sınıfların methodlarını, özelliklerini ve diğer bilgilerini de içerir. Yani CIL’e biraz daha üstten genel bir bakış atarsak, CIL içerisinde değişken tanımları, değişkenlerin nasıl saklanacağı, methodların nasıl çalıştırılacağı, aritmetik ve lojik işlemler, bellek kullanımı gibi birçok işin nasıl yapılacağı açıklanır.

Sihir gibi değil mi? :) Bir “Hello World” uygulamasının CIL kodunu inceleyelim dilerseniz. Visual Studio ile basit bir Hello World console application projesi oluşturup, konsola “Hello World” yazdıran kodu yazalım.

Kodu derledikten sonra, CIL kodunu görüntüleyebilmek için IL DASM tool’unu kullanabiliriz. Bu toola’a Developer Command Prompt’a ildasm yazarak kolay bir şekilde ulaşabiliyoruz. IL DASM ile exe dosyasını açtığımızda ilk olarak aşağıdaki görüntü bizi karşılamaktadır.

Burada programın manifesto bilgisine, methodlarına ve classlarının özelliklerine erişebiliyoruz. Gelin şimdi bir de Main methodunun CIL kodunun nasıl olduğunu görüntüleyelim.

İşte sihirli kısım. CIL kodunu anlamak aslında çok da zor değil. Örneğin; ldstr “Hello World” satırında ‘Hello World’ stringinin load edileceği bilgisi yer alıyor. Hemen bir altındaki call çağrısıyla hangi methodun çağrılacağı belirtilmiş. Görüldüğü gibi, CIL ne makine dili kadar insandan uzak ne de C# kadar insana yakın.

Artık kodumuz derlendi, exe dosyası oluşturuldu ve çalıştırılmaya hazır. Run Time’daki operasyonlara geçerek, exe dosyasının .NET Framework’te nasıl çalıştırıldığını inceleyelim.

CLR (Common Language Runtime) Nedir?

CLR (Common Language Runtime) .NET Framework’te programların çalışmasını kontrol eden ve işletim sistemi ile program arasında yer alan bir arabirimdir. CIL kodlarını çalıştıran ana mekanizmadır. CIL kodları daha önce de incelediğimiz gibi makine dili değil bir ara dildir. Bu sebeple programın çalıştırılabilmesi için bu ara dili alıp makine diline çevirecek ve makinede işletecek bir mekanizmaya ihtiyaç duymaktaydık. Bu ihtiyacı CLR karşılamaktadır.

CLR, içerisinde yer alan JIT (Just in Time) derleyicisi ile, CIL kodunu alır makine koduna çevirir ve programın çalışmasını sağlar. Akıllara hemen ‘İyi de neden böyle bir şeye ihtiyaç duyuyoruz ki, direkt olarak neden yazdığımız kodlar makine diline çevrilmiyor da ara bir dile dönüştürülerek CLR’a ihtiyaç duyuyoruz?’ gibi bir soru gelebilir. CLR’ın bize sağladığı avantaj programlarımızı platform bağımsız çalıştırabilmemizi sağlamasından ileri geliyor. .NET Framework yüklü herhangi bir makinede CIL kodunu CLR işleteceği için kaynak kullanımları, performans ile ilgili maksimum optimizasyonu da yine JIT derleyicisi ile beraber sağlamış oluyor.

Hazır JIT kavramı geçmişken, JIT derleyicisi nedir hemen inceleyelim.

JIT (Just in Time) Compiler Nedir?

C#’ta CIL’e compile ettiğimiz program çalıştırılırken CLR aracılığı ile JIT derleyiciler devreye girer. Bu derleyiciler CIL kodunu işleyerek programın çalıştırıldığı sistemin ve işlemcinin anlayabileceği makine kodunu oluştururlar. Burada bir miktar kafa karışıklığı yaşanmış olabilir. “Bir defa kod yazıyoruz ve iki kere mi derleme işlemi uygulanıyor?” gibi bir soru akıllara gelebilir. En başta yazdığımız bir kod iki kere derleniyor evet. Önce bizim yazdığımız C# kodu C# derleyicisi ile CIL’e dönüştürülüyor ve bu oluşan CIL, CLR mekanizması içerisindeki JIT derleyicileri ile makine koduna çevriliyor. Just in Time denilmesinin sebebi, Türkçe’ye ‘O an’ veya ‘Tam o anda’ şeklinde çevirerek biraz daha türlerini incelediğimizde daha net ortaya çıkacaktır.

3 çeşit JIT compiler bulunmaktadır. Bunlar

1. Normal-JIT
2. Econo-JIT
3. Pre-JIT

1. Normal-JIT

Normal-JIT derleyiciler; programın tamamını tek seferde derlemez. Program çalışırken parça parça derleme işlemi gerçekleştirilir. Her method çalıştırılmadan önce derlenir ve derlenen methodun makine dili kodları önbellekte tutulur. Böylece program içerisinde derlenmiş bir methodun tekrar çalıştırılması gerektiğinde yeniden derleme işlemi gerçekleştirilmez ve bu method önbellekten çekilir.

2. Econo-JIT

Econo-JIT derleyicilerde de programın tamamı tek seferde derlenmez. Yine Normal-JIT gibi program çalışırken parça parça derleme işlemi gerçekleştirilir. Her method yine çalıştırılmadan önce derlenir ancak Normal-JIT’ten farklı olarak derlenen methodun makine dili kodları önbellekte tutulmaz. Her method her çağrılışında yeniden derlenir.

3. Pre-JIT

Tüm program en baştan tek seferde makine koduna çevrilip sonra çalıştırılır. Programın daha hızlı çalışmasını sağlasa da diğer JIT derleyici türlerine göre daha fazla hafıza gerektirmektedir.

CLR içerisinde yer alan başka bir yapı ise CTS (Common Type System) yapısıdır. Bu yapıyı da inceleyerek bir .NET programının çalışma anatomisini tamamlamış olalım.

CTS (Common Type System) Nedir?

Bütün veri tiplerinin tanımlı olduğu bir sistem olarak düşünebiliriz. CTS sayesinde .NET Framework’te farklı dillerde yazılmış programların veri tipleri arasındaki uyum sağlanmış olur.

Örneğin VB.NET ile yazılmış bir Integer değişkeni, C#’ta int olarak yazılsa da CTS karşılıkları System.Int32'dir ve RAM’de kapladıkları alan aynıdır. Bu sayede tipler arasındaki uyum sağlanmış olur, değişen tek şey dillerdeki syntax olmaktadır.

Özet

• Yazılan kod, o dile özgü derleyici ile CIL (Common Intermediate Language)’e çevrilir.
• CIL içerisinde Metadata yapısını da barındırır.
• CLR mekanizması aracılığı ile CIL kodları JIT derleyicileri ile derlenerek program çalıştırılır.

Bu yazı ilk olarak http://cozvelioglu.com/bir-exe-uygulamasinin-anatomisi-clr-cil-jit-cts-kavramlari/ adresinde yayınlanmıştır.

Bir .exe Uygulamasının Anatomisi (CLR, CIL, JIT, CTS Kavramları) was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bu yazımda C#’ta string birleştirme işlemi yaparken oluşabilecek performans problemlerini, .ToString() ile Convert.ToString() methodları arasında ne gibi bir fark olduğunu ve iki string’i karşılaştırırken kullandığımız .Equals() methodu hakkında ufak bir detayı inceleyeceğiz.

“String birleştirme işlemleri neden maliyetli?” sorusunun cevabı aslında stringlerin .NET Framework’teki tanımlanmalarından ileri gelmektedir. String tipi .NET Framework’te immutable (değişmez) olarak tanımlanmıştır. İlk olarak immutable kavramı bilmeyenler ve yeniden hatırlamak isteyenler için nedir, ne değildir inceleyip; yavaş yavaş string işlemlerinin performanslarına doğru yol alalım isterim.

İmmutable (Değişmez) Nedir?

Immutable nesneler bir kez oluşturulduktan sonra içeriği değiştirilemeyen nesnelere verilen bir tanımlamadır. String tipi de immutable tanımlandığı için, stringler üzerinde yapılan birleştirme işleminde her seferinde memory’de yeni bir string oluşturulacak ve geliştirdiğiniz programın performans sorunuyla karşılaşması muhtemel bir hal alacaktır.

Örneğin, yukarıdaki görselde str isimli bir string oluşturulurken başlangıç değeri olarak “Hello” atanmıştır. Sonrasında str ile “world” birleştirme işlemine tabi tutulup yine str değişkenine atansa dahi memory’de “Hello world” isimli yeni bir String objesi oluşturulmuş ve str artık “Hello world”ü referans göstermektedir. str tanımlanırken verilen “Hello” değeri, artık referans gösterilmeyen bir String objesi olarak memory’de hala yer tutmaya devam etmektedir.

String Birleştirme İşlemleri (StringBuilder Kullanımı)

s = "Hello" + "World" + "I am" "an" + "engineer";

Yukarıdaki gibi bir birleştirme işlemi her + operatörünün kullanımıyla memory’de yeni bir string oluşturacağından maliyetli bir işlem olacaktır. Özellikle bir döngü içerisinde bu birleştirme işlemi devam ettiği sürece performansta o oranda bir kayıp yaşanacak ve memory’i gereksiz yere işgal etmiş oluruz. Bunun yerine string’ler ile birleştirme yapacağımız zaman StringBuilder sınıfından yararlanmak performans açısından kaydadeğer bir ilerleme sağlar.

Yukarıdaki birleştirme işlemini StringBuilder ile aşağıdaki şekilde yapabiliriz.

StringBuilder sb = new StringBuilder("Hello");
sb.Append("World");
sb.Append("I am");
sb.Append("an");
sb.Append("engineer");
string s = sb.ToString();

Son satırda StringBuilder objesini ToString() ile string’e çevirerek memory’de yalnızca bir defa string oluşturmuş oluruz. Bir döngü içerisinde stringlerle ilgili birleştirme işlemi yapılacaksa StringBuilder kullanımı oldukça önem kazanıyor, unutulmaması adına bir kez daha belirtmiş olayım.

String Bölme İşlemleri (Split Kullanımı ile İlgili Ufak Bir İpucu)

Elimizde belli bir karaktere göre ayırmamız gereken bir string olduğunda sıkça kullandığımız bir methoddur Split() methodu. Genellikle aşağıdaki şekilde kullanılır;

string str = "Ceyhun-Cozvelioglu";
 string[] temp1 = str.Split('-');

Split işlemini aşağıdaki şekilde uyguladığımızda biraz daha performanslı bir sonuç elde ederiz;

string str = "Ceyhun-Cozvelioglu";
 string[] temp = str.Split(new char[] { '-' });

ÖNEMLİ: Bu yöntem anlamlı bir performans kazancı sağlamamaktadır. Hatta string içerisindeki ayırıcı karakter sayısı arttıkça birbirine yakın sonuçlar elde edilmektedir. Yine de yazıya konu etmeden geçmek istemediğim için bir köşede bulunması amacıyla ele almış bulundum. Performans bazen çok kritik bir önem teşkil etse de büyük ve kalabalık ekiplerin üzerinde çalıştığı projelerde kodun okunabilir olması yerine göre çok daha fazla önem arz ediyor. Bu durumlarda anlamlı bir performans kazancı olmadığı sürece böyle bir yöntemin kullanılması kod okunabilirliğini olumsuz etkileyebileceğinden seçim yaparken bu faktörlerin de göz ardı edilmemesi gerekiyor.

String Equals ile İlgili Ufak Bir Detay

İki string tipindeki veriyi karşılaştırmak istediğimizde, imdadımıza yetişen bir methoddur Equals methodu. Aşağıdaki gibi bir kullanımda true return edecek ve if bloğunun içerisine girerek akıştaki kodumuzu işletecektir.

string str = "Ceyhun";

if(str.Equals("Ceyhun"))
    ...

Peki ya veritabanından veya servisten çekeceğimiz bir string değeri bir başka değerle kıyaslayacağımız zaman null gelmesi durumunda Equals methodumuz nasıl bir davranış gösterir?

try {  
    string str = null;  
    if (str.Equals("Ceyhun")) {  
        Console.WriteLine("if");  
    } else {  
        Console.WriteLine("else");  
    }  
} catch (Exception ex) {  
    Console.WriteLine(ex.Message);  
}  
Console.ReadLine();

str değişkenimiz null olduğu için exception fırlatılacak ve programımız crash olacaktır. Bu sebeple karşılaştırma için kullanacağımız string değişkenini null kontrolünden sonra kullanmamız daha güvenli olacaktır.

Peki aşağıdaki gibi bir durumda nasıl bir çıktıyla karşılaşırız?

try {  
    string str = null;  
    if ("Ceyhun".Equals(str)) {  
        Console.WriteLine("if");  
    } else {  
        Console.WriteLine("else");  
    }  
} catch (Exception ex) {  
    Console.WriteLine(ex.Message);  
}  
Console.ReadLine();

Equals metodunu kullanacağımız string null değilse eğer içerisine argüman olarak gönderdiğimiz string değer null olsa bile karşılaştırma işlemi sorunsuz bir şekilde yapılacaktır.

Özetle, string bir referans type olduğu için null değer alabilir. Bu sebeple String sınıfına ait bir methodu kullanmadan önce, string için bir null kontrolü yapmak ve null değilse işleme devam etmek programın stabilitesi açısından faydalı olacaktır.

Yukarıdaki duruma bir örnek de .ToString() methodu ile Convert.ToString() methodu arasındaki farkı verebiliriz.

.ToString() ile Convert.ToString() Arasındaki Fark

İki method da string’e dönüştürme işlemi için kullanılır ancak aralarında ufak bir fark mevcuttur. Eğer dönüşüm yapılacak obje değeri null ise .ToString() ile yapılan dönüştürme işleminde “NULL Reference Exception” fırlatılırken, Convert.ToString() ile yapılan dönüşümde exception fırlatılmaz.

//Null reference exception fırlatılacaktır. 
object obj = null;  
string  str = obj.ToString();  
  
//str stringinin değeri null olacaktır. Exception fırlatılmaz.
object obj = null;  
string str = Convert.ToString(obj);

Özet Olarak

• Stringler .NET Framework içerisinde immutable olarak tanımlanmıştır.
• Stringler ile yapılan birleştirme işlemlerinde StringBuilder kullanımı performans açısından önemlidir.
• Stringlerin NULL kontrolü yapıldıktan sonra işlemlere tabi tutulması güzel bir kazanım olacaktır.
• Bir objeyi string’e dönüştürmek için Convert.ToString() methodunu kullanmak best practice’tir.

Bu yazımda string’ler hakkında bazı ufak ancak gözden kaçtığı taktirde can sıkabilecek detayları inceledik. String’leri benzine benzetiyorum zaman zaman, herkesin kullanmak durumunda olduğu ancak maliyeti yüksek bir yapı, neyse ki yazılımda maliyeti düşürmenin yolları mevcut :)

Herkese iyi günler, keyifli kodlamalar dilerim :)!

String İşlemleri ile İlgili Bazı Detaylar was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bu yazımda teknik sohbetlerde ve sorularda yer alan fakat zaman zaman kolayca karıştırılabilen, unutulmaya yüz tutmuş temel bazı kavramları işledim. Derli toplu bir şekilde bir köşede durmasının faydalı olacağını düşünüyorum. Sözü fazla uzatmadan kavramlara geçelim :)

Method İmzası (Method Signature) Nedir?

Method imzası; methodun ismini ve aldığı parametrelerin tipleriyle birlikte sayısını belirten bir kavramdır. Unutulmaması gereken durum, method imzasına dönüş tipinin dahil olmadığıdır.

Örnek:

int Carp(int sayi1, int sayi2);

int Carp(int sayi1, int sayi2, int sayi3);

Yukarıdaki ilk Carp methodunun imzası Carp(int,int) şeklindeyken ikinci Carp methodunun imzası Carp(int,int,int) şeklindedir.

Ufak bir not: Method imzası kavramı özellikle Method Overload konusunda karşımıza çıkmaktadır.

Parametre ve Argüman Nedir? Farkları Nelerdir?

Parametre, bir method tanımlanırken methodda input olarak kullanılacak değişkenleri belirttiğimiz kavramdır. Örnek:

int Topla(int x, int y)  //int x ve int y Topla methodunun parametreleridir
{
     return (x + y);
}

Argüman ise method çağrılırken methoda gönderdiğimiz değişkenlerdir.

Örnek:

int sonuc = Topla(5 , 14);  //5 ve 14 değişkenleri Topla methoduna input olarak gönderilen argümanlardır

Derleyici (Compiler) ve IDE (Integrated Development Environment) Nedir?

Yazılımlar genellikle yüksek seviye bir programlama dili (Örneğin C#, Java vs. gibi) ile yazılır. Herhangi bir programlama dili ile yazılmış kodu makine koduna çeviren araca Derleyici denilmektedir. Derleyicilere örnek olarak GCC, G++ verilebilir.

IDE ise, içerisinde derleyiciyi de barındıran bunun yanında kod yazmayı kolaylaştıran syntax highlighter, otomatik tamamlama, debug araçları gibi yazılım geliştirmeyi kolaylaştıcı pek çok aracı ihtiva eden tümleşik bir geliştirme aracıdır. IDE’ye örnek olarak Visual Studio, Eclipse, Netbeans verilebilir.

Oldukça basit, temel birkaç kavramı hızlıca ele aldığım bir yazının daha sonuna geldik. Sizin de eklemek istediğiniz kavramlar varsa yorumlarda lütfen buluşalım. Herkese iyi günler, keyifli kodlamalar :)!

Bu yazı ilk olarak http://cozvelioglu.com/basit-olmasina-ragmen-kolayca-unutulabilen-bazi-teknik-kavramlar/ adresinde kendi blogumda yayınlanmıştır.

Basit Olmasına Rağmen Kolayca Unutulabilen Bazı Teknik Kavramlar was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Versiyon kontrol sistemleri kalabalık ekiplerin, büyük projelerin hatta tek başına yazılım geliştiren yazılımcıların bile olmazsa olmaz bir araç çantası. Versiyonlar arasındaki farkları üstünden ne kadar zaman geçerse geçsin, kodlardaki değişen kısımlara bakmadan bir bakışta anlayabilmenin yolu ise iyi yazılmış commit/check-in mesajlarından geçiyor. Kalabalık ekiplerin çalıştığı büyük projelerde commit veya Visual Studio ile TFS’i entegre olarak kullanan ekipler için diğer adıyla check-in mesajları oldukça büyük önem arz ediyor. Geliştirme yapacağınız ekranın geçmişine göz atarken yalnızca mesaj içeriğinden bir şeyleri anlamak inanılmaz zaman kazandırıyor ve verimi artırıyor. Bunun dışında standartlara bağlı kalarak ilerlenen her şeyde olduğu gibi daha derli toplu bir proje ilerleyişini de beraberinde getiriyor.

Oldukça ufak ve az sayıdaki bazı kurallara uyarak, çok daha temiz, anlaşılabilir commit/check-in mesajları yazmak mümkün. Sözü fazla uzatmadan, yazılım camiasında kabul görmüş genel geçer kurallara geçelim.

Konu satırı 50 karakter ile özet bir bilgi içermeli

Konu satırı commit/check-in’inizin dergi kapağı görevini gören kısımdır. Okunabilirlik açısından 50 karakter ile sınırlandırmak kabul görmüş bir konu.

Not: Özetleme konusunda sıkıntı yaşıyorsanız muhtemelen tek seferde çok fazla değişiklik yaptığınız anlamını taşıyor. Bu da versiyon kontrolü için bazı problemli durumlar oluşturması oldukça muhtemel. Bu konuya daha sonra değinmek adına, şimdilik bu kısım için şunu söyleyebiliriz “Yaptığınız değişiklikleri kısa bir özet ile açıklayamıyorsanız, muhtemelen commitiniz/check-ininiz gereğinden fazla yük ile yüklenmiş durumda”

Konu satırı büyük harfle başlamalı

Oldukça basit bir kural daha. Yazacağınız mesajın ilk harfi büyük harfle başlamalı.

Konu satırı nokta ile bitmemeli

Türkçe hocalarımız görse eminim içleri kan ağlardı ama üzgünüm, bu konuda fikir birliğine varılmış bir kural olarak karşımıza çıkıyor. Mesajınızın sonuna alışması biraz zor ve tuhaf gelse dahi nokta koymamalısınız.

Yazacağınız mesajda emir ifadeleri veya daha genel bir ifadeyle formal bir dil kullanın

Bu kural için örnekleri incelememiz yeterince açıklayıcı olacaktır.

Git’in kullandığı örnek birkaç commit mesajını inceleyelim

• Remove contrib/examples/* (Doğru)
• Add sample commands for git-shell (Doğru)
• Merge branch ‘jc/bs-t-is-not-a-tab-for-sed’ (Doğru)

Bu şekilde yazmak, eğer böyle yazmıyorsanız ilk başlarda biraz tuhaf gelecektir.

Pek çok yazılım geliştirici yaptıklarını geçmiş zaman kipiyle açıklamayı tercih eder. Bu nedenle commit/check-in mesajları genellikle aşağıdakine benzer bir yapıda oluyor

• Xyz bug fixed (Yanlış)
• Login form created (Yanlış)

Bunun haricinde bazı mesajlar da açıklama yapıyor-muş gibi göründüğü halde aslında üstünden zaman geçtikten sonra neyi düzelttiği/geliştirdiği hakkında en ufak bilgi vermeyen mesajlar olarak görünür

• Some bugs fixed (Yanlış)
• Add new class (Yanlış)
• Added new object for (Yanlış)

Commit mesajlarının yapısı için oldukça basit bir formül var. Düzgün bir şekilde oluşturulmuş bir mesaj aşağıdaki cümlede altı çizili olan yeri tamamlayabilmelidir.

• If applied, this commit will your subject line here

Örneğin;

• If applied, this commit will remove deprecated methods
• If applied, this commit will release version 1.0.0

Bu yapı için geçmiş zaman ifadesi içeren mesajların uymadığını görmek çok kolay. “Eğer uygulanırsa bu commit 1.0.0 versiyonunu yayınlar” gibi yazdığımız commit/check-in mesajlarıyla aslında bir taahhütte bulunuyoruz. Bu yüzden formal bir dil kullanmamız çok daha anlamlı ve kabul görmüş bir kural olarak karşımıza çıkıyor.

İyi bir commit/check-in mesajının nasıl olacağına dair basit birkaç kuralı ele aldığımız bir yazının daha sonuna geldik. Umarım faydalı olmuştur. Herkese keyifli kodlamalar dilerim :)!

KAYNAKLAR

1. https://chris.beams.io/posts/git-commit/#limit-50
2. https://www.freshconsulting.com/atomic-commits/

Bu yazı ilk olarak http://cozvelioglu.com/iyi-bir-commit-check-in-mesaji-nasil-olmali/ blogumda yayınlanmıştır.

İyi Bir Commit/Check-In Mesajı Nasıl Olmalı? was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yazılıma yeni başlayan hemen herkesin zaman zaman karıştırdığı, hangisini ne zaman kullanacağına karar veremediği Abstract Class ve Interface ikilisini ele almak istedim. İlk bakışta yazdığımız koda oldukça benzer yetenekler kazandırdıkları görünse de aralarındaki farkların üzerinde durarak hangi senaryolarda hangisine karar vermemiz gerektiğini iyice açığa çıkartacağız 🙂

Abstract sınıflara geçmeden önce C# ve tüm Object Oriented dillerin bize sunduğu bir özellik olan abstraction(soyutlama) kavramını ele alalım. Böylece Abstract sınıflara ve Interface’lere neden ihtiyaç duyduğumuzu daha net bir şekilde anlayabiliriz.

Abstraction (Soyutlama) Nedir?

Abstraction, OOP (Object Oriented Programming-Nesne Tabanlı Programlama) içerisindeki önemli kavramlardan birisidir. C#’taki soyutlama; diğer Object Oriented dillerde olduğu gibi iç detayları gizleyerek sadece işlevleri göstermeye denir. Bu durumu gerçek hayatın içerisinden bir senaryo ile örneklendirelim.

Senaryo: Bir gün canınız sıkıldı ve çocukluğunuzda kalmış tatlı bir aktivite olan lunaparka gidip çarpışan arabaya binmek istediniz. Biletinizi aldınız ve seçtiğiniz arabaya oturup size gelen görevliye bileti teslim ettiniz. Görevli alana baktı ve araçları hareket ettirecek olan elektriği vermek için yeterli sayıda kişinin olduğuna karar verip bir düğmeye bastı. Görevlinin düğmeye basmasıyla çarpışan arabaların hareket etmesi için gerekli olan elektrik akımı verildi ve arabanız çalışır hale geldi. Direksiyonu, gaz pedalını ve freni kullanarak dilediğiniz şekilde aracı kullanmaya başladınız.

Şimdi gelin bu gerçek hayatın birebir içinden olan senaryodaki soyutlamaları (abstractions) inceleyelim. Böylece yazılım alanında da aslında aynı mantığın kullanıldığını ve soyutlamanın hayatımızı nasıl kolaylaştırdığını daha iyi anlamış olacağız.

Senaryoda Yer Alan Soyutlamalar(Abstractions): İlk soyutlama örneğimiz biletinizi teslim ettiğiniz görevlinin eğlenceyi başlatmak için bastığı küçük kırmızı düğme 🙂 Görevli o kırmızı düğmeye bastığında bizler sadece eğlencenin başlayacağını biliyoruz, görevli de on dakikalık bir seansa daha start vereceğini biliyor yalnızca. Düğmeye basıldığı anda elektrik devresindeki anahtarın kapanıp akımın başlayacağını ne biz ne de görevli aklının ucundan dahi geçirmiyor. İşte bu tam bir soyutlama örneği. Yalnızca input(düğmeye basmak) ve output(eğlencenin başlaması) değerleriyle ilgileniyoruz. Arka tarafta dönen teknik hadiseleri hiç düşünmeden bize sunulmuş bir düğmeyi kullanarak işimizi görüyoruz.

Eğer hala bir şeyler oturmadıysa kafanızda bir de çarpışan arabamızdaki soyutlamaya bakalım. Siz arabayı kullanırken direksiyonu gitmek istediğiniz yöne çeviriyor, gaz pedalına basarak ilerliyorsunuz. Gaz pedalına bastığınızdaki motorda oluşan tetiklenmeleri, direksiyonu çevirdiğinizde lastiklerin dönmesini sağlayan mekanizmayı hiç düşünmeden yalnızca iki pedal bir direksiyonla aslında arka planında onlarca aksiyon yatan bir işlevi gerçekleştirmiş oluyorsunuz. Input (gaz/fren pedalları, direksiyon) ve output (arabanın gitmesi) değerlerini bilmek size yetiyor.

Object Oriented programlamada sınıfların soyutlanmasını ise Abstract Class ve Interface ikilisi sağlamaktadır. Abstraction kavramı kafamızda biraz olsun şekillendiğine göre şimdi Abstract Class’ları inceleyebiliriz.

Abstract Class

Abstract sınıflar sınıf hiyerarşisinde genellikle base class (temel sınıf) tanımlamak için kullanılan ve soyutlama yeteneği kazandıran sınıflardır. Bir sınıfı abstract yapmak için abstract keywordünü kullanırız. Abstract sınıflar en az bir tane abstract metod bulundurması bir best practice’tir.

abstract class Yazdir

{

     public abstract void KonsolaYazdir();

}

Yukarıda Yazdir isimli basitçe bir abstract sınıfı tanımladık ve kendisinden türeyecek metodların override edeceği KonsolaYazdir() abstract metodunu oluşturduk.

Genel olarak abstract sınıfların özelliklerini bir araya toplarsak;

• Abstract sınıfları genel olarak inheritance (kalıtım) uygularken kullanırız.
• new anahtar sözcüğü ile nesneleri oluşturulamaz.
• İçerisinde değişken ve metod bulundurabilir.
• Abstract sınıflardan türetilen sınıfların abstract metodları implement etmesi zorunludur. Diğer metodları override etmeden de kullanabilir.
• Constructors (yapıcı metodlar) ve destructors (yıkıcı metodlar) bulundurabilirler.
• Static tanımlanamazlar. ( Tanımlanmaya çalışılırsa compiler “an abstract class cannot be sealed or static” hatası verir)
• Bir sınıf yalnızca bir abstract sınıfı inheritance yoluyla implement edebilir. Çoklu kalıtım (multiple inheritance) desteklenmez.
• Abstract olmayan metodları da bulundurabilir.
• Kendisinden inherit alacak sınıflar ile arasında “is-a” ilişkisi vardır. (Burası ilk başlarda çok önemsenmeyen ancak hangi senaryoda Abstract hangi senaryoda Interface kullanacağımızı netleştirmede bize oldukça yardımcı olan bir detaydır, hemen aşağıda açıklamasını bulabilirsiniz)

Is-a İlişkisi Nedir?

Senaryomuzdan bir örnekle bunun daha iyi anlaşılabileceğini düşünüyorum. (Şimdiye kadar Türkçe kelimeler üzerinden gittiğim için örneğimde de is-a ilişkisi hariç cümlemi Türkçe kuruyorum)

Çarpışan araba is-a araba.

Yani en nihayetinde çarpışan araba da bir arabadır ve arabanın sahip olduğu özellikleri bünyesinde barındırır.

Şimdi Araba için abstract bir sınıf oluşturup çarpışan arabayı da bu sınıftan inherit alarak oluşturalım.

abstract class Araba

{

    //Arabalarin ortak ozelliklerini burada tanimliyoruz

    public string Marka { get; set; }

    public int MaksimumHiz { get; set; }

    public string Tur { get; set; }

//Her araba icin yolculuga baslandi bilgisini farkli bir sekilde

//ekrana yazdirmak icin override  dilecek abstract metodumuzu yaziyoruz

    public abstract void YolculugaBasla();
}

class CarpisanAraba : Araba

{

    //Abstract metodumuzu carpisan arabaya ozel bir sekilde override      ediyoruz.

    public override void YolculugaBasla()

    {

        Console.WriteLine("Carpisan araba ile yolculuga baslandi");

    }
}

Araba isminde bir abstract sınıf tanımlayarak CarpisanAraba sınıfını bu abstract base sınıftan türettik. Böylece Araba sınıfında yer alan tüm özellikleri tekrardan yazmak zorunda kalmadan kolayca sahip olurken, YolculugaBasla() metodunu sınıfımıza özel override ettik. Abstract sınıfları inherit alan sınıfların abstract metodları override etmesinin zorunlu olduğunu belirtmiştik. Bu sebeple Visual Studio’da CarpisanAraba sınıfını Araba sınıfından inherit ettiğinizde, YolculugaBasla() metodunu override etmezseniz hata alırsınız.

Abstract sınıfları genel itibariyle mercek altına aldığımıza göre şimdi bir de Interface’leri inceleyelim. Sonrasında ikisi arasındaki farkları tablo halinde gördüğümüzde hangi senaryoda hangi soyutlama mekanizmasını kullanacağımızı çok daha iyi kestirebilir bir hale geleceğiz.

Interface

Interface, içerisinde sadece kendisinden türeyecek olan sınıfların içini dolduracağı metod tanımlarının bulunduğu ve soyutlama yapmamıza olanak sağlayan bir yapıdır. Interface’leri tanımlarken interface keywordünü kullanırız. Tanımladığımız yapının interface olduğunu belirtmek için isminin önüne I harfini getirmek bir best-practice olacaktır. Böylece kodlama yaparken inherit aldığımız yapının bir class mı yoksa interface mi olduğunu kolaylıkla ayırt edebiliriz. Bu kadar teorik bilgiden sonra basitçe bir interface tanımlayalım.

interface ILog

{

    void LogEkle(string kayit);

}

Bu interface’ten türeyen tüm sınıflar LogEkle(string kayit) metodunu implement etmek zorundadır. Interface hakkında internette bir arama yaptığınızda genellikle kendisini inherit alan sınıflar için bir kontrat olduğundan bahsedilir. Kontrat kelimesiyle anlatılmak istenen tam olarak budur. Türeyen sınıflar, interface’in içerisinde yer alan tüm metodları implement edeceğine dair bir söz vermekte, sözleşme yapmaktadır. Aksi halde derleyici hata verecek, kodunuz çalışmayacaktır.

Genel olarak Interface’lerin özelliklerinden bahsetmemiz gerekirse;

• new keywordü ile nesneleri oluşturulamaz.
• Bir sınıfın ne yapması gerektiğini belirtir, nasıl yapması gerektiğini değil.
• Default olarak tüm Interface üyeleri abstract ve public olarak tanımlanır. Sizin özellikle belirtmeniz gerekmez.
• Bir sınıf birden fazla interface’i inherit edebilir, çoklu kalıtım (multiple-inheritance) desteklenir.
• İçerisinde yalnızca metodların imzaları yer alır, içi dolu metod bulunduramazlar.
• Kendisinden inherit alacak sınıflar ile arasında “can-do” ilişkisi vardır.

Can-do İlişkisi Nedir?

Çarpışan araba senaryosundan bir örnekle açıklamak gerekirse,

Çarpışan araba can-do hızlanmak. 

Açıklamaya gerek var mı bilemedim açıkçası ama abstract sınıflarda açıklamışken burada boş bırakmak içime sinmezdi. Çarpışan araba hızlanabilir diyoruz. Çarpışan arabanın bir davranışından bahsediyoruz.

Interfaceleri tam olarak can-do ilişkileri içeren yapılarda kullanmamız isabetli olacaktır. Senaryomuzdaki çarpışan araba hızlanabilir. Bu çarpışan arabanın yapabileceği bir kabiliyetigöstermektedir. Can-do ilişkisi davranışları, kabiliyetleri belirtir. Bu kabiliyetin interface içerisinde tanımlanması çok daha doğru olacaktır.

Abstract Class ve Interface Arasındaki Farklar

Abstract sınıflar ve Interface’ler arasındaki farkları işlediğimiz bu yazıyla birlikte bir yazının daha sonuna geldik. Dilerim aydınlatıcı olmuştur, anlayamadığınız veya gözümden kaçan herhangi bir şey varsa yorumlarda belirtmeniz beni memnun edecektir. Bir sonraki yazıda görüşmek dileğiyle; keyifli kodlamalar, mutlu günler :)!

KAYNAKLAR

1. https://www.geeksforgeeks.org/difference-between-abstract-class-and-interface-in-c-sharp/
2. https://www.agile-code.com/blog/difference-between-interfaces-and-abstract-classes-in-microsoft-net/

Abstract Class ve Interface Arasındaki Farklar Nelerdir? was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

– Sait Faik Abasıyanık/Haritada Bir Nokta

Sait Faik’in dediği gibi oluyormuş aslında her şey.. Bir gün tak ediyormuş insanın canına yazmamak/yazamamak. Benim hikayemse aslında yazmak isteyen herkes ile benzer, benim içinse farklıydı. Bu yüzden, öncelikle neden ve nasıl yazmaya karar verdiğimi yazarak başlamak istedim.

Uzun zamandır aklımda olan bir şeydi yazmak, sadece bir türlü ilk kıvılcımı çakamıyor, her gün saatlerce bilgisayar karşısında vakit geçirmeme rağmen sanki yazı yazacağım zaman bambaşka bir şeyle uğraşacakmışım gibi bir düşünceye kapılıyordum sanırım. Bu hissi açıklayabilmek de oldukça güç aslında. ‘Bir gün yazmaya başlayacağım‘ ümidiyle bugünü yarına, yarını diğer yarınlara devrederek kendimi kandırıyordum. Birkaç kez Medium’da kendimce paylaşımlarda bulunmuş fakat devamını bir türlü getirememiştim. Bir şeyler yapmak istiyordum, nedense üstümdeki ölü toprağını atamıyordum. Sonunda bir gün bu harekete geçememe nedenlerimi kendimce sorguladım ve benim gibi yazmak isteyip de bir türlü başlayamayanlara en azından kendilerini sorgulayabilmesi açısından veri seti olabilecek aşağıdaki sebepleri buldum (Sebepleri tek tek nasıl ele aldığımı da yazının ilerleyen kısımlarında bulacaksınız)

1. Motivasyonum eksikti. Motivasyon her iş için kilit rol oynuyor. Özellikle tamamen kuralları sizin belirlediğiniz üretim alanlarında zorunluluğunuz da yoksa konfor alanınızı terk etmek başlarda gerçekten çok zor gelebiliyor.
2. Bana sağlayabileceği katkılar hakkında pek düşünmemiştim. Her şeyi bir kenara bırakırsak sadece yazı yazmanın bana katacağı çok şey vardı aslında.
3. Planlama yapmamıştım. Belgesellere, filmlere, dizilere konu olan o meşhur İlham Perisi‘ni bekliyordum yazmak için. Oturup hiç bu işi plana dökmemiş; kendimce zorunluluklar, kısıtlar belirlememiştim.
4. Kendim çalıyor, kendim oynuyordum. Yazdığım yazıları paylaşmaktan nedense çekiniyor, mükemmelliyetçi davrandığım için kendi yazdıklarımı iki gün sonra beğenmiyor ‘Ben bile beğenmediysem diğer insanlar neden beğensin ki?’ diye düşünüyordum. Daha önce radyo programları yapmış, müzikle uğraşan birisi olarak sahne alıp şarkılar söylemiştim. Hiçbirisinde bir yazıyı yayına alırken çekindiğim kadar çekindiğimi hatırlamıyorum. Sanırım ilk defa böyle bir konuda hata yapmaktan çok korkuyor, insanların meraklı gözlerinden mümkün olduğunca kaçmak istiyordum.
5. Uzunca bir süre Medium mu yoksa Self-hosted blog mu karar veremedim. Bu kararsızlık tam iki ayımı aldı. Sanki binlerce yazı yazmış biriktirmiş de platform seçme lüksüne sahipmişim gibi arkasına sığındığım bahanelerden birisi de bu olmuştu. (İkisinde de paylaşmak sanki yasakmış gibi 🙂)

Arkasına sığındığım bahaneleri, o zamanlar gayet haklı bulduğum ama şimdi hepsini birer “Vakit hırsızı” olarak gördüğüm sebeplerin paylaşmaya değer gördüğüm beş tanesini sıraladım. Bu sadece yazı yazmak ile ilgili değil, hayatın her alanında bir şeyi çok isteyip de bir türlü başlayamadığımız ne varsa; arkasına sığındığımız sebeplerin hepsi birer hırsız. Ömrümüzden, vaktimizden çalan geri dönüşü olmayan şekilde bizi tüketen şeyler.

BU BAHANELERİ YENMEK ADINA NELER YAPTIM?

Bir şeyler okurken maddeler halinde yazılmış yazıların hafızamda daha uzun süre kaldığını farkettim. Hem okurken kolay oluyordu, hem de hatırlarken sanki bir harita gibi gözümün önüne geliyordu. Bu yüzden ben de bu tarz soru-cevap başlıkları altında eğer maddelerle açıklamaya uygun bir içerikten bahsedeceksem, maddeler halinde anlatmayı tercih ediyorum. Herkesi motive eden faktörler değişebilir elbette ancak ben yukarıda bahsettiğim bahaneleri yenmek adına kendimce denediğim ve başarılı olduğumu farkettiğim şeyleri sıralamaya başlıyorum;

1. Bol bol blog yazıları okudum. Bir işe başlayacaksam öncelikle; o iş hakkında benden önce birileri neler yapmış, nasıl yapmış bunlara bakmayı tercih ediyorum. Bu beni motive eden bir şey. Blog yazılarını okudukça içimde ‘Ben de bir an önce başlamalıyım artık‘ hissi oluşuyordu. Bana ilham veren belki de yüzlerce yazı okumuştum. Hem yeni şeyler öğreniyor hem de bir taraftan motivasyonuma katkı sağlıyordum.
2. Yazma konusundaki hata yapma korkumu yendim. Çok klişe olacak belki ama sevdiğim ve yerine tam oturacak bir sözü paylaşayım ‘Başlamak için mükemmel olmak zorunda değilsin, fakat mükemmel olmak için başlamak zorundasın!‘. Hata yapma korkusuyla baş etme yönteminin en güzel özetini bu cümlede buluyordum. Elbette hatalar yapacak, basit veya kötü sayılabilecek içerikler üretecektim. Eyleme geçmeden sürekli söylemlerle hareket ettiğim sürece asla kafamdaki o mükemmel yazılarımı yazamayacağımı farkettim. Bizi biz yapan ve tecrübe dediğimiz şeylerin toplamı aslında çoğunlukla hatalarımız ve onlardan aldığımız dersler değil miydi? Öyleyse hata yapmaktan korkmak; hiç bisiklete binmeden, masmavi denizlerde alabildiğine yüzmeden hayatı terk etmek gibi bir şeydi. Emniyetli fakat adına ne kadar yaşam denebilirse…
3. Planlama yaptım. Kendime göre kıstaslar ve asgari limitler belirledim. Örneğin; her hafta bir konu belirleyip onun hakkında minimum bir yazı yazacağım. Yeni öğrendiğim bir şeyi unutmamak adına en kısa sürede yazıya dökeceğim. Hemen yayınlamasam bile taslak olarak elimin altında bekleteceğim. O konuya dair düşüncelerim olgunlaştığında yazıyı tekrar gözden geçirip gerekli düzenlemeleri yaparak yayına alacağım. İşin planlama aşamasının bile motive kaynağı olduğunu fark ettim.
4. Yazmanın bana katacağı şeylere daha fazla odaklandım. Önceleri sadece yazma isteği vardı içimde. Neden, nasıl, ne sıklıkla gibi soruları sormaktan özenle kaçınıyor gibiydim. Bu soruları sordukça ‘Teknik yazılar yazmanın bana ne gibi faydaları olabilir ki?‘ sorusuna geldi sıra. Benim için en önemlisi; öğrendiğim, paylaşmaya ve yazmaya değer gördüğüm şeyleri kendi sözcüklerimle açıkladığım ve unuttuğumda kolayca geri dönüp bakabileceğim harika bir arşive sahip olacaktım.

NE TÜR YAZILAR YAZACAĞIM?

Bilgisayar Mühendisi olarak yazılarımın büyük bir bölümünü teknik detaylara, yazılım ile alakalı şeylere ayırmayı planladım. Elbette hatıra olarak kalmasını istediğim, paylaşmaya değer gördüğüm farklı kategorilerde yazılar da yazmayı düşünüyorum ve bu yönde de aklımda bolca fikir var. Bu blogu oluştururken yazılarımda Bilgisayar Mühendisliği disiplini altında yer alan birçok konuya ufaktan dahi olsa temas edebilmek benim en büyük gayem. Örneğin profesyonel hayatta .NET Teknolojileriyle çalışmama rağmen blogda veri yapılarından algoritmalara, veritabanlarından design patternlara geniş bir yelpazede düzenli bir ilerleyiş planlıyorum.

SONUÇ OLARAK

Hayatımın farklı dönemlerinde zamanlama olarak düzensiz bir şekilde yazılar yazsam da ilk defa bu kadar kararlı kollarımı sıvadım, kahvemi hazırlayıp oturdum klavye başına. Dilerim yazdıklarım bir kişiye dahi olsa faydası dokunacak şeyler olur. Diğer yazılarda görüşmek dileğiyle :)!

Neden/Nasıl Yazmaya Başladım? was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Herkese merhaba,

Bir süredir Medium’da bir yazı dizisine başlamak aklımdaydı ancak ne yapacağım konusunda çok da bir fikrim yoktu. Yazmak her şeyden önce bana iyi gelen bir şey olduğu için bir şeyler karalamayı uzun süredir oldukça istiyordum. Nihayetinde düşündüm ki Bilgisayar Mühendisliği’nin en temel alanlarından birisi olan Veri Yapıları’na dair (benim de üniversite döneminde büyük bir keyif aldığım ancak ilk başlarda bir o kadar da bana karmaşık gelen bir konu olmuştu) kendimce notlar oluşturmak ve bunları paylaşmak istedim.

Hem kendimce bir tekrar yapmış olacağım, hem de kendime ve bir şekilde bu yazılara ulaşan insanlara belki ufak da olsa bir katkı sağlayacağım motivasyonuyla “Veri Yapıları” serimi başlatmış bulunuyorum.

Unutmadan Gelebilecek Eleştirilere Karşı Ufak Bir Not: Akademisyen veya bilirkişi değilim, en büyük amacım kendime bir arşiv oluşturmak, dijital dünyada keyif aldığım bir alana dair izler bırakabilmek.

LINKED LIST (BAĞLI LİSTE) NEDİR?

Linked List içindeki elemanların doğrusal olarak RAM’de tutulduğu özel bir veri saklama yapısıdır. Linked List node altyapısı ile çalışır. Hafızada verilerin doğrusal olarak (Linked List yapısında, dizide olduğu gibi veri sıralı bir şekilde tutulmaz burası karıştırılmamalı) tutulması yönüyle dizilere benzese de aralarında önemli performans ve işlevsellik farkları mevcuttur.

LINKED LIST vs ARRAY (DİZİ) ARASINDAKI FARKLAR

1. Dizilerde ulaşmak istediğimiz elemana indisini girerek ulaşırız. Linked List’lerde ise ulaşmak istediğimiz elemanlara point eden pointerlar vasıtasıyla ulaşırız.
2. Dizilerde eleman ekleme, silme gibi işlemler Linked List’lere göre performans açısından daha maliyetlidir. Örneğin; 1000 elemanlı bir dizimiz tanımlı olsun. Bu dizinin 500.cü elemanını silmek istediğimizde, bu elemandan sonra gelen her eleman bir sıra geri kaydırılacak bu da performans kaybına yol açacaktır. Linked List’te ise bu işlem sadece basit pointer operasyonlarıyla gerçekleştirilir ve kaydırma işlemlerine gerek kalmaz. Bu sayede performanstan kazanç sağlanmaktadır.
3. Linked List dinamiktir. Dizi tanımlaması yapılırken en başında veri boyutunu belirtmemiz gerekirken, Linked List’lerde ihtiyaç duyduğumuzda boyutu artırabilir, silme işlemlerimizden sonra Linked List boyutumuzu küçültebiliriz.

Bu kıyaslamada Linked List’in önemli avantajlarından bahsettik elbette hiçbir şey her şeyiyle mükemmel olmuyor. Bazı noktalarda ise Linked List’in dezavantajları bulunuyor. Array ve Linked List’lerin avantajlı ve dezavantajlı olduğu hususları göz önünde bulundurarak tasarımımızı buna göre seçmemiz çok daha yerinde bir hamle olacaktır.

LINKED LIST’LERİN DEZAVANTAJLARI

1. Linked List’lerde random bir veriye ulaşım dizilere göre maliyetlidir. Dizilerde dilediğimiz elemana indisini girerek ulaşabiliyorken, Linked List’lerde ise pointerlar aracılığı ile liste üzerinde gezinmemiz gerekir. Bu da performans kaybına yol açar. (Yani bir dizide 750. elemana ulaşmak istediğimizde indisi girerek direkt ulaşabilirken, Linked List’lerde bu elemana ulaşmak için listenin en başından 750. elemana kadar gezinmemiz gerekir.)
2. Linked List’ler, sadece veriyi değil veri ile birlikte bir sonraki düğüme işaret eden pointerları da tuttuğumuz için dizilere göre hafızada daha fazla yer kaplar.

Linked List yapısının teoriğine ufak bir giriş yaptık, bir sonraki yazıda bir Linked List yapısı oluşturup içerisine elemanlarımızı gireceğiz.

Atladığım veya yanlış yazdığım bir husus olduysa yorumlarda bunu belirtmeniz beni çok mutlu edecektir.

Kaynaklar:

1. https://www.studytonight.com/data-structures/linked-list-vs-array
2. C ve Java ile Veri Yapılarına Giriş, 2. Baskı - Olcay Taner Yıldız
3. http://www.necessaryandsufficient.net/2008/05/differences-between-arrays-and-linked-lists/
4. https://www.youtube.com/watch?v=lC-yYCOnN8Q , mycodeschool

Üniversite eğitimini sayısal bir bölümde okuyan birçok insanın adını bir şekilde bir yerlerde duyduğu bir ismi mercek altına alacağım bu yazımda. İngiliz matematikçi, kriptolog ve bilgisayar bilimcisi kabul edilen Alan Turing.

6 yaşında okula başlayan ve matematik üzerine doğal bir eğilimi olan Alan Turing kısa sürede öğretmenleri tarafından keşfedilmiş, henüz 16 yaşındayken derslerinde türev/integral gibi konuları öğrenmeden bile ileri düzeyde matematik problemlerini çözer hale gelmiştir. Hatta bilime öylesine meraklı bir çocukluğu olmuştur ki; trenlerin ülkede işlemediği bir gün Southhampton’dan okula 60 milden fazla süren yolu tek başına bisikletle gitmiş ve yarıyolda geceyi bir otelde geçirmiştir.

Gelelim şimdi Alan Turing’in üniversite sıralarında çok da bahsedilmeyen, üzerinde durulmadan geçilen ama dolaylı da olsa tüm dünya kaderini etkileyen başarısına.

II. Dünya Savaşı zamanlarına gidiyoruz. Almanlar şifreli haberleşme yapabilmek için Enigma adında bir makine üretmiş ve bu makine sayesinde kendi aralarında gizli bir iletişim kurabilmişlerdir.

1938 yılında II. Dünya Savaşı’nın başlamasına 1 yıl kala İngiliz İstihbaratı tarafından Almanya’nın askeri şifrelerini çözmesi için görev teklif edilmiş, Alan Turing de bu görevi kabul etmiştir. II. Dünya savaşı başlamadan önce oluşturulan 5 kişilik ekiple birlikte bir parkta oluşturulan binada Almanların kullandığı şifreleri çözmüştür. Ne var ki Alan Turing ve ekibi tarafından çözülen bu şifreleme sistemi savaş zamanında birkaç defa daha zor bir şekilde değiştirilse de Alan Turing kısa bir sürede bu sistemleri de çözmüş savaşın gidişatının değişmesinde büyük rol oynayarak Almanya’yı başarısızlığa uğratmıştır. Tarihçiler, Alan Turing’in çalışmalarının Avrupa’daki savaşı iki yıl kısalttığını ve buna bağlı olarak sayısız yaşam kurtardığını belirtiyorlar.

Buraya yazsam okuyanların bitirmeden terkedeceğini bildiğim sayısız başarısı mevcut bir dahi Alan Turing. Şimdi gelelim onun cezasına. 1952 yılında Turing Machester polisi tarafından tutuklandı ve genç bir erkekle yakalandığı gerekçesiyle mahkemeye çıkartıldı. Toplumsal ahlakı bozmaya yönelik davranışları düzenleyen yasa kapsamında yargılanacaktı. O zamanlar homoseksüellik bir suçtu ve Turing’in ya hormon tedavisi olması gerekiyordu ya da hapis yatması.

Turing hormon tedavisini seçti çünkü bilimden uzak kalmak istemiyordu. Ancak bu suçlama ve ceza bir çok şeyden onu mahrum etmeye yetmişti. Güvenlik belgeleri elinden alındığından, şifre çözme merkezi GCHQ’a yürüttüğü danışmanlığına son verildi. Ayrıca, bildiği devlet sırlarını açıklaması olasılığına karşı gözetim altında tutuldu.

Bir gün evinin hizmetçisi olan Bayan Clayton bir akşamüstü Turing’in odasına girdiğinde onun yatağın üstündeki cansız bedeniyle karşılaştı. Turing’in ölüm nedeni aslında açıkça bilinmese de bilinen kısmı siyanür enjekte edilmiş bir elma yediği. Başarılı birçok bilim insanı gibi Alan Turing de henüz 42 yaşında, çok erken bir yaşta ölmüştür.

Ne diyelim, intihar olduğuna inanmış gibi yapıp normal hayatlarımıza geri dönelim..