Bir programlama dilini öğrenmeye başladığımızda genellikle ilk yapılan örnek HelloWorld, hello_world_, helloWorld, hello-world benzeri isimlendirmelerle hazırlanan merhaba uygulamaları olur. Pek çok başlangıç rehberi veya kılavuzu ortam üzerinden ekrana birşey yazdırmakla yetinir. İlk kez programlama deneyimi yaşayanlar için ideal bir senaryo gibi dursa da en azından birkaç yıllık programlama deneyimi olan veya farklı programlama dili/dilleri ile bir şeyler geliştirmiş bireyler için bu tip başlangıçlar tad vermeyebilir. Bu profile uyanlar için bazen karşılaştırmalı senaryolar ortaya koymak ya da birden fazla dil özelliği ile materyalini beraberce gösterebileceğimiz örnek senaryolar üzerinden hareket etmek daha anlamlıdır. Eğer bu bir eğitim serisi olacaksa ileride tekrardan bakılabilecek ya da içeriği kullanılabilecek türden giriş uygulamaları daha yerinde bir seçim olacaktır.
Bu tip girizgahlarda profilin zaten öğreneceği programlama dili için gerekli ortamları hazırladığı ya da kolayca muhakeme yapıp sorgulayacağı düşünülmelidir. Örneğin yıllarca ABC dili ile geliştirme yapmış bir ekibe XYZ dilini anlatacağımızı düşünelim ya da üniversite öğrencilerine daha önceden gördükleri programlama derslerinden farklı bir tanesini. Kabul ve yönlendirme, kitlenin bazı hazırlıkları kendisinin yapması gerektiği üzerine olmalıdır. Kişisel görüşüm bu gibi durumlarda programlama dilinin birden fazla özelliğinin beraber kullanıldığı, çıktısı tartışılabilir, yeniden düzenlenmeye (refactor) açık (bu sayede Clean Code teorilerine geçiş kolaylaşır) program kodları yazarak ilerlemektir. Hatta anlatılan kitle için araştırma yapmalarını sağlayacak tavsiyeler bırakmak çok yerinde olacak, tek taraflı bir anlatım yerini sürdürülebilir ve katılımcı bir iletişime bırakacaktır.
İşte bu felsefe ile yola çıkıp mesleki hayatım boyunca sıklıkla kullandığım C# dilinde Hello World yazmak istesem nasıl yapardım sorusuna cevap vermeye çalışıyorum. Bu reponun açılma amacı tamamen buna hizmet ediyor. Kişisel görüşme göre bu senaryolar ve uygulama metodolojisi, farklı programlama dilleri için de söz konusu olabilir. Kodlamada kullanılan ifadeler, anahtar kelimeler profile yabancı gelebilir/gelecektir. Ancak bu birazda sürekli kod yazma pratiği ile alakalıdır. Hello World uygulamalarında amaç, dilin genel felsefesini (burada OOP) sağlamış olduğu araçların küçük bir kümesi ile gerçeklenebilir senaryolar üzerinde gösterebilmektir. Bir başka deyişle syntax veya anahtar kelimeler dert edilmesi gereken son şeyler olmalıdır.
Bu versiyon daha çok üniversite son sınıf öğrencileri veya yazılım kursiyerleri için kullanılabilir. Bir programlama dili dersini almış ya da uğraşmış olmak veya birkaç yıl programlama dili tecrübesine sahip olmak (bireysel çalışmalarla da olabilir, staj programlarındaki işlerle de gerçeklenebilir) ön gereksinimlerdendir. Senaryoyu işleten kod zorlayıcı olabilir ancak amaç düşünmeye itmek ve sorgulatmaktır.
Dönem boyunca verilecek ödevlerin listesi json formatlı bir dosyadan okunarak terminal ekranına yazdırılır.
- Json için nesne modellemesi
- Sınıf tanımlamaları ve metot kullanımları
- Override ile davranış değiştirme
- Basit veri türleri kullanımı
- Encapsulation
- Generic liste verisi ve döngü kullanımı
Bu senaryoda ödevler JSON bazlı bir dosyada durur. .Net çalışma ortamının dışında JSON standartlarında tutulan bir veri içeriğinin, nesne yönelimli dil özellikleri barındıran C# ortamında nasıl ele alınacağına bakılır. Amaç dış dünya kavramlarını nesne olarak modellemenin yollarını tartışmaktır. Model nesnesi tanımı bir başlangıçtır. İçeriğinin doldurulması .Net'in yardımcı kütüphaneleri ile gerçekleştirilir. Bu, dilin bazı noktalarda built-in gelen paketleri kullanarak işleri nasıl kolaylaştırdığını göstermenin ve Nuget ortamını araştırma tavsiyesi olarak vermenin de bir yoludur (Hatta bir Nuget klonunun yazılması dönem ödevi olarak sunulabilir) Bu kavramlar üzerinden geçilirken verinin nasıl ifade edileceği sorusu gündeme gelir ve basit veri tipleri gündeme alınır. Ödevleri benzersizleştirmek için kullanılan Guid ekstra bir bonus olarak görülebilir. Kritik noktalardan birisi Supervisor sınıfının inşasıdır. Ufak ufak, öğrencilerin bünyesinde sorumlulukların doğru dağıtılması için gerekli motivasyon aktarılmaya çalışılır ancak açık uçlu sorular da ortaya bırakılır. ToString metodundan yola çıkılarak ata tür (super class, super object, base object artık nasıl isimlendirirsek) kavramına değinilir ve ortak davranışların değiştirilmesi gündeme taşınır.
Bu uygulama sonrasında öğrencilerden bazı sorular beklenir veya bir tartışma başlatılarak aşağıdaki maddeler üzerinde durulur.
- Dosya adı yanlış yazılırsa veya lokasyonu değişirse ne olur?
- Json içeriğindeki bir alan kaldırılırsa ne olur?
- Veri json dosya yerince csv tabanlı bir dosyadan okunmak isterse nasıl bir yönteme gidilir?
- Söz konusu veri kümesi dosyadan okunmak zorunda mıdır? Farklı makinelerden, farklı process'lerden çekilebilir mi? (İş modellerinin çoğunlukla kapalı devre modeller üzerinde koşmadığı, dağıtık yapıların da var olduğu ve sıklıkla kullanıldığı düşünceleri eşliğinde tartışılabilir)
- Level, sayısal bir değer yerine daha akılda kalıcı bir şekilde ifade edilebilir mi? (Enum türü için yönlendirme)
- Döngü olarak tek kullanım şekli foreach midir? Farklı yollar var mıdır? (Diğer yolları pratik etmek için ödev verilebilir)
Bu versiyon da Hello World I uygulamasındaki profil ve üstü için uygundur.
Bu sefer elimizde CSV formatında bir kullanıcı listesi bulunuyor. Kullanıcıların ad soyad bilgileri, sisteme giriş adları ve e-posta adresleri yer alıyor. Kullanıcı bilgilerinin satır bazında okunması ve ekrana yazdırılması söz konusu.
- CSV dosya formatının kullanılırlığı (Halen pek çok büyük mainframe bu tip dosya formatlarında içerik sunmaktadır. Hatta bir Excel çıktısı bile CSV olarak sisteme dahil edilebilir. Hatta segment bazlı dosyalar da tartışılabilir)
- Dosya satırlarının nesne modellemesi
- class/struct ve record kullanımı (Başlangıçta class/struct olarak tasarlanan veri modelinin salt okunur bir yapıda kullanılması sebebiyle record veri yapısına geçilir ve böylece üç farklı veri yapısı tanıtılmış olur)
- Constrcutor ile nesne inşası
- Readonly field/property kullanımı
- Basit döngü kurguları
- Generic liste verisi ve döngü kullanımı
Bu senaryoda yine çalışma zamanı (runtime) dışındaki bir ortamdan veri çekilmesi ve belleğe alınarak kullanımı planlanmaktadır. CSV türü yaygın kullanılan dosya formatlarından birisidir ve şeması belli veri yapılarının anlatılmasından önce bir altyapı sağlayacaktır. Böylece veri odaklı uygulamalarda veriyi saklama yolları, veriler arasındaki ilişkileri kurmak, şemasız veri modelleri, sistemler arası veri transferi ve bu esnada kullanılan protokollerin önemi ilerleyen derslerde tartışmaya açılabilir. POCO (Plain Old CLR Object ya da Dummy Entity) olarak tasarlanan User veri modeli nihayetinde record türü olarak tanımlanmıştır. Böylece record veri türünün hangi senaryolarda ele alınacağı üzerine tartışma açılabilir. IdentityManager yapısında constructor kavramı ele alınırken varsayılan (default) verisyonun ezilmesi ve sonuçları ortaya konur. Her zaman olduğu gibi sorumlulukların doğru dağıtımı vurgulanmaya çalışılır ve SOLID'in Single Responsibility ilkesi ufaktan düşünce tohumu haline getirilir.
- Struct veya class yerine neden record veri türü kullanıyoruz? (Bellek üzerindeki açılımları, stack ve heap bazındaki yorumlamaları araştırma konusu olarak tavsiye edilir)
- Dosya kolonlarına erişirken 0,1,2 gibi rakamlar program kodunu okuyan için anlamlı değildir. Alternatif/ler ne olabilir? (Enum türüne yönlendirme, mapping kavramları öne çıkarılır)
- Dosya şema yapısı değişirse ne olur?
- Dosya lokasyonu değişirse ne olur?
- Aynı veri kümesini CSV yerine farklı formatlarda sağlamak istediğimizde program kodu bunu nasıl ele alır?
- IdentityManager isimlendirmesi mantıklı mıdır? (Özellikle bu sınıfın aslında bir dosyadan kullanıcı listesi okuyup bir koleksiyonda sakladığı düşünülürse)
İlk iki senaryoda bahsedilen profil ve üstü bu senaryoda ile de çalışabilir.
Bu sefer oyun motorlarının ilerleyen derslerde Entity Component System'e evrilebilecek bir senaryosu üzerinde durulur. İki boyutlu bir platformer oyununda oyuncu ve rakibin yönetici bir nesne içerisinde kurgulanması ve sadece başlangıç konumunda set edilen içeriğin ekrana yazdırılması üzerinde durulur.
- Key;Value türevli koleksiyon kullanımı
- Key;Value türlerinde Value olarak liste verisi kullanımı
- Nesne davranışı değiştirme (ToString override)
- Ortak bileşenler için türetmeden (Inheritance) tanımlama (World nesnesindeki dictionary koleksiyonunda önce Object türü kullanılır ama sonra olması gerektiği gibi bir başka türetme değerlendirilir)
- Object ata türü ve riskleri
- Türetme ve generic kullanımı
Bu senaryo zor görünse de aslında yapılan bol bol sınıf tasarlamak, bu sınıflara ait koleksiyonlar kullanmaktan ibarettir. Çok ilkel olarak platform oyununda hareket etme, yerleşim, kuvvet ve sağlık/can gibi bileşenler gerçekten de bir Component olarak düşünülür. Component'leri birleştirip bunları bir Entity olarak ifade etmek ve bu düşünce felsefesini aktarmak çok kritiktir. Böylece oyun sahasındaki bir karakterin esasında kendisi ile ilişkili bileşenleri içeren bir başka nesne olduğu ifade edilir. Başlangıçta her şeyin Object türünden geldiği düşünülerek farklı nesnelerin aynı tür koleksiyonda toplanması üzerinde durulur. Object türü kullanımının sakıncası ortaya konulduktan sonra türetme ve generic kavramlarından bahsedilir.
- World nesnesinde belli bileşenlere (Component) sahip nesneleri nasıl buluruz? (Mesela sadece velocity kabiliyeti olanları bulmak gibi. Bu ECS'in System fonksiyonlarını açıklayacak bir tartışmadır)
- Çok fazla bileşenden oluşan nesne listelerinde aranan belli bir Entity'ye çabuk gitmenin bir yolu olabilir mi? (Yüzlerce nesnenin olduğu bir senaryoda FPS döngüsünde işleyen fonksiyonlar sıklıkla bir takım Entity'leri bulmak zorunda kalacaktır. Hızlı bir şekilde bunlara erişmenin yolları arama algoritmalarını da gündeme taşıyabilir)
İlk iki senaryoda bahsedilen profil ve üstü bu senaryoda ile de çalışabilir. Belki daha önceden MVC gibi modellere bakmış olanlar için Model View klasörlerini açıklamak daha kolay olabilir.
Terminal kullanıcısı bir servis bilgisini basit bir koleksiyonda toplamak için gerekli işlemleri yapar. Program servisler için çok basit anlamda takma isim, ip ve port bilgilerini alır. Örneğin redis hizmeti için Redis takma adıyla https://127.0.0.1:6379 gibi bir bilgi oluşur. Buna benzer servis bilgileri bir nesne koleksiyonunda toplanır ve fiziki olarak bir dosyaya kayıt edilir.
- Basit model nesnesi oluşturmak
- Static metot kullanımı
- Static metod ile nesne inşa etmek (static factory method)
- Fonksiyonellikleri ilgili sınıflar içerisine dağıtmak
- Tuple, generic List veri türlerini kullanmak
- Olay (Event) tanımı ve basit kullanımı
- Metot override işlemi
- private, public farkları
Bu örnekte bir nesnenin oluşturulmasını kontrol altına almak önemli noktalardan birisidir. Service sınıfının alanlarına hatalı değerler atanması muhtemeldir. Geçeriz IP adresi, anlamsız takma isimler, hatalı port'lar vs. Senaryo basit olarak ele alınmıştır ve bu anlamda sadece üç özellik üzerinden ilerlenmiştir. Service nesnesine ait constructor private hale getirilip üretimin static bir fonksiyona alınmasının anlaşışması önemlidir. Bu daha kapsamlı nesne inşa işlemlerinde Creational Design Pattern konusu için de bir ön zemin hazırlayabilir. Basit bir terminal uygulaması da olsa ekrandaki başlık, inventory içeriğinin ekrana basılması veya kullanıcıdan girdi alınması gibi işlemler static fonksiyonlar haline getirilip View isim alanında yer alan Terminal sınıfı altına alınmıştır. Bu felsefede kodun okunur olması, ana kodun yalınlaştırılması, terminal bile olsa görünüm ile ilgili işlerin başka bir enstrümana yüklenmesi gibi kavramlar öne çıkartılır. Pek tabii tuple gibi türlere, nullable olma hallerine de değinilir. Öğrencilerin daha verimli çıktılar elde edebilmesi için aynı sınıfın Builder kalıbı ile oluşturulması ödev olarak verilebilir.
- Service nesnesini oluşturan fonksiyondan null değer döndürmek yerine daha işe yarar ve anlamlı bir şey döndürülebilir mi? (Result pattern için bir zemin hazırlanabilir Farklı dillerde bu işin nasıl ele alındığı belki ele alınabilir. Örneğin rust dilinde)
- Tekrar eden servis bilgileri eklenmek istendiğinde bu nasıl karşılanmalıdır (Sınıfça tartışılabilir)
- Bazı portlar işletim sistemine özeldir ve kullanılamayabilir. Bunun için bir Policy listesi kullanılmak istense bu sisteme nasıl entegre edilebilir.
- Service'lerin ayakta olup olmadığı kontrol edilmek istense bunun için nereye nasıl bir fonksiyon yazılabilir (Sadece tartışmaya açılır. Amaç Service Discovery gibi mekanizmalara, Consul gibi araçlara zemin hazırlamaktır)
NotImplementedException();
NotImplementedException();
NotImplementedException();
NotImplementedException();
NotImplementedException();