C# Programlama Rehberi - 1

1. Tasarımdaki zerafet her zaman kazandırır: Herhangi bir yazılım tasarımı sırasında dikkatli ve olabildiği kadar güzel tasarlamanız size ilk bakışta çok zaman kaybetttiğiniz hissini verebilir. Fakat tasarladığınız sistem veya modül çalışmaya başlayınca siz aslında çok şeyleri kazandığınızı farkedeceksiniz. Bunlardan bazılarını sayacak olursak; benzer bir durumda ya tasarımınızı aynen kullanabileceksiniz ya da çok az bir değişiklikle aynı tasarımı kullanmaya imkanınız olacaktır. Bu sayede belki tasarrufunuz saatleri, günleri ve hatta haftaları bulacaktır. İyi bir tasarım sistemi daha hızlı oluşturma ve hata ayıklamanın yannında daha kolay anlaşılmasına ve güncellenmesine de yardımcı olacaktır ki bu da vakit nakittir prensibi ile yakından ilgilidir. Bazen siz zarif bir iş yaparken kimileri sizin çok çalıştığınızı fakat verimli olmadığınız iddaa edebilir ki siz bunlara kulak asmayın. Diğerleri gibi hızlı iş çıkarmaya çalışmak aslında proje(ler)in daha yavaş ilerlesine yolaçacağına emin olabilirsiniz.

2. Önce çalışan sonra hızlı çalışanı yap: Eğer projenizde bir yer sistemin darboğazı ise ilk etapta onun doğru çalışanını yapın. Sistemdeki darboğaz ile ilgili kısmı olabildiği kadar kolay ve anlaşılır biçimde hazırlayın ve çalıştırın. Sonra performans testlerine tabi tutun. Eğer testlerde büyük bir hız sorunu varsa onu düzeltmeye kalkın. Çoğu zaman darboğazın sizin için aslında çok önemli bir problem olmadığını farkedeceksiniz. Sizin için önemli olan zamanını idareli, tasarruflu, kullanmaktır.

Çevirmenin Notu: Donanım güngeçtikçe artan bir hızla ucuzluyor. Ama yazılım projelerinde sizin vaktiniz çok kıymetli ve sınırlıdır. Ondan dolayıdır ki .NET’i ve RAD kullanmak giderek popüler oluyor.

3. “Parçala, böl ve yut” prensibini her zaman akılda tut: Eğer çözmeniz gereken sistem çok karmaşık ise; programda en temel görevi veya işlevi yapan parça nedir onu bulmaya çalışın. Bu temel görevi yapan sınıfı yazdıktan sonra, diğer yan parçaları ya temel parçaya birşeyler ekleyerek (türetme, veya inheritance ile) veya temel parçayı destekleyici parçalar (sınıflar) geliştirerek sistemin tamamını oluşturun.

4. Sınıf tasarımcısı ile sınıf kullanıcısını birbirinden ayırın: Sınıf tasarımcısının hazırladığı sınıfları kullanan programcılar genelde “müşteri” olarak andlandırılır. Müşteri programcılar sınıfların içinde neyin olup bittiğini bilmelerine gerek yoktur. Sınıf tasarımcısı, sınıf oluşturmada tam bir uzman olmalıdır ki en acemi programcı bile onun tasarladığı sınıfları kolaylıkla kullanabilmelidir. Sınıf kütüphanelerinin kullanım kolaylığı direk olarak sınıfın ne kadar taransparan yazıldığına dayanır.

Çevirmenin Notu: Sınıflar kullanırken onların içinde neyin olup bittiğinin bilinmesine ihtiyaç duyulmaması Nesne Yönelimli Programlamanın en temel prensiblerinden biri olan sarmalama (encapsulation) olarak adlandırlır.

5. Sınıfları oluşturuken isimlendirmeleri sınıf elemanlarının amaçlarını açıklaycı bir şekilde yapın: Bu sayede müşteri programcı için sınıf arayüzünün çok kolay anlaşılır olması hedefine ulaşabiliriz. Ayrıca gerekirse aynı işleri yapan farklı parametre alan metodlar içinde, metotlara aşırı yükleme (method overloading) kullanmanız çok uygun olacaktır.

Çevirmenin Notu: Metodlara aşırı yükleme ayın işi yapana fakat farklı parametre alan metodlara aynı isimleri verme kuralına dayanır. Mesela .NET snıf kütüphanesindeki Convert sınıfında tek bir ToInt32() metodu olmasına karşın, bu metota 18 defa, herbiri ayrı parametreler sayesinde, aşırı yüklenmiştir.

6. Sistem analiziniz ve tasarımınız, en az olarak, sistemdeki sınıfları, onların public arayüzlerini ve diğer sınıflarla ilşkilerini, özellikle temel sınıflarla üretmeli: Eğer sizin tasarım yönteminiz bundan daha fazlasını üretiyorsa; kendinize ekstraların programın yaşama süresi boyunca ne kadar değerleri olduğunu bir sorun. Genelde yazılım geliştirme takımındakiler kendilerinin verimliliğne pek bir katkısı olmayan parçaların bakımını yapmaya yanaşmazlar. Ayrıca bu gerçeği bir çok sistem tasarım metodolojisi gözardı ediyor maalesef.

7. Herşeyi otomatikleştirin: Sınıfın kodunu yazmadan önce, sınıfı tüm özellikleri ile test eden metodu yazın ve bunu sınıf içinde barındırın. Test kodunun çalışmasını makefile veya benzeri bir araçla otomatik hale getirin. Bu sayede sınıfın kodu içinde meydana gelen her türlü değişikliğitest kodu ile test edip muhtemel bir çok hatayı kolayca farkedip düzeltme imkanınız olacaktır. Her ne kadar derleyiciler ve yazılım geliştirme araçlarında inanılmayacak kadar çok kontrol özellkileri eklendiyse de ( tip kontrolü, hata ayıklama ve otomatik sözdizimi düzeltimi gibi) bunlar bir yere kadar kodun doğrulunu garanti edebiliyorlar. Eğer sağlam ve güvenilir bir sistem geliştirmek istiyorsak mümkün olduğu kadar dikkatli ve emin adımlarla ilerlemiyiz. Bunu sağlamak için iyi hazırlanmış test kodları ile sınıfın veya programın doğru çalıştığına emin olmalıyız.

Çevirmenin Notu: Window XP projesinde yazılan kodların en az %20 - %25’nin test kodları olduğunu söylersem galiba profesyonellik ve başarı açısından test kodlarının sanırım ne kadar önemli olduğunun altını çizmiş olurum.

8. Bir sınıfın kodunu yazmadan önce onun test kodunu yazınız: Bu tür bir yaklaşımla sınıf tasarımınızın tam anlamıyla doğru ve eksiksiz olduğunu doğrulayabiliriz. Ek olarak, test kodunu yazarken sınıfla ilgili gözden kaçan ve gerekli özellikler ve kısıtlamaların da (genelde tasarım ve analizde farkedemediğiniz) gözünüze çarpmasını sağlar. Test kodunun başka bir yararı da, doğal olarak, sınıfın kullanıma ilişkin bir örnek teşkil etmesidir.

9. Tüm yazılım geliştirme problemleri ek bir konseptsel yön değiştirme ile daha da basit bir hale getirelebilir: Bu yazılım geliştirme mühendisliğinin en temel kurallarından biri olup nesne yönelimli programlanın da dayandığını prensiblerden biridir.

10. Yön değiştirme anlamlı olmalı: Burdaki anlamlı biçimde yön değiştirme en basit hali ile çok kullanılan kodları aynı metod içine koymak olacaktır.

11. Sınıfları olabildiğince küçük tasarlayın: Her bir sınıfın tek ve iyi belirlenmiş bir amacı olmalı. Eğer sınıf tasarımınız çok karmaşık ve uzun olduysa onu daha basit parçalara ayırmayı deneyin. Herhangi bir sınıfın ne kadar sade olduğunun göstergesi: onun eleman sayısı( metotler, üye değişkenleri vs.. ) ve üzerinde yapılan değişiklerin çok olmasıdır. Bu tür durumlarda sınıfı bölerken bir kaç ipucu olarak şunları kullanın:

·         Karmaşık switch yapısı: çok biçimliliği kullamayı deneyin.

·         Çok sayıda ve değişik türden işleri yapan metotlar: değişik sınıflar oluşturmayı deneyin.

·         Çok sayıda ve değişik türden sınıf üye değişkenleri: değişik sınıflar oluşturmayı deneyin.

12. Çok sayıda argüman alan metotlara dikkat edin: Metotları çağırmak karmaşık hale geldiği gibi, kod içinde metodu çağıran kısımları da okumak ve bakımını yazmak güçleşecektir. O zaman metoda argüman olarak nesne geçirmeyi deneyiniz.

Çevirmenin Notu: Hatta sırf bu amaçla sınıf veya yapı dahi oluşturabilirsiniz. Böylelikle sadeliği korumuş ve uzun vadede çok değişik kazanımlar elde ettiğinizi gözlemleyeceksiniz.

13. Kendinizi tekrarlamayın: Eğer türeyen sınıflardan bir çoğunda tekrarlanan kod parçası olduğunu gözlemlerseniz; o kod parçasını temel sınıfa koyunuz ve onu temel sınıftan çığırın. Bu sayede sadece kodun daha kısa olmasını sağlamazsınız, ayrıca tekrar eden ksımlardaki değişikler için tek bir örneğini değiştirmeniz yeterli olur. Bazen de böyle bir keşif sizin arayüzünüze değerli bir katkı da sağlacaktır.

Çevirmenin Notu: Bir çok nesne yönelimli programlama anlatan kaynaklarda geçen gemotrik şekillerle ilgili bir sınıf kütüphnesini tasarımından örnek verelim. Diyelim sizin kare, dikdörtgen ve eşkaner dörtgen isimli üç sınıfınız var. Bu üç sınıf için gerekli olan Çiz() metodunu herbirinde tekrar tekrar yazmaktansa, üçünün birlikte türediği dörtgen sınıfında yazmak ile daha az kod yazmış olursunuz. İleride ParaleKenar isimli bir sınıfa ihtiyacanız olunca; bu sınıf için tekrardan Çiz() metodunu yazmaktan kurtulursunuz. Hatta ilk versiyonda tek bir kalem (sabit kalınlık ve renk) ile çizim yaparken ilerki versiyonlarda farklı kalemler( kalınlık ve renk detaylarıyla) ile çizmek gibi özellikler ekleyince tüm dörtgenler için tekbir Çiz() metodu tanımlamanın size kazandıracağı zamanı ve sistemin sadeliğini düşünün bir!

14. switch ve çoklu if-else yapılarını gözlemleyin: Bunlar genelde tip-kontrollü kodlamanın göstergesidir. Yani, siz tip bilgisine göre hangi kodu çalıştıracağınıza karar veriyorsunuz(genelde tip bilgisi belli olmayabilir) demektir. Bu tür durumlarda switch ve ve if-else yapıları yerine kalıtım ve çok biçimliliği kullanın. Çok biçimli bir metot sizin yerinize tip kontrolünü yapar ve argüman tipine göre gerekli işleri yapar veya türeyen sınıflar vasıtası ile yaptırır. Yine kodunuz daha kolay okunabilir ve kolayca genişleyebilir bir hal alır.

Çevirmenin Notu: Yine gemoetrik şekiller ile ilgili sınıf kütüphanemizi düşünelim. Çiz() metodu 3 farklı parametreye bağımlı olarak işini yaptığını varsayalım. Bunlardan birincisi şekil, ikinicisi kalem ve üçüncüsü ise çizgi tipi (kesikli, noktalı, normal veya herhangi başka bir özel şekillerden biri..). Sizin de farkedeceğiniz gibi minumum olarak bizim şekil parametresidir. Diğerleri ise seçimliktir(opsiyonel).

Bu durumda tüm parametre kombinasyonlarında göre ya dört farklı metot yazmalıyız ki bunların isimleri farklı olmalıdır:

a. Çiz_Tam( şekil, kalem, çizgiTipi )
b. Çiz( şekil )
c. Çiz_Kalemli( şekil, kalem )
d. Çiz_Şekilli (şekil, ÇizgiTipi )

Ya da tek bir çiz metoduna kalem ve çizgiTipi nesnelerinin birini veya ikisini null olarak geçirmeli ve biraz karmaşık if-else ifadesi kullanmalıyız. Her iki durumda da tasarmızın karmaşıklığı ve kullanım zorluğu olduğu açıktır. Ama biz çok nesne yönelimli programlamanın en temel özelliklerinden biri olan biçimlilik(polymorphism) ile bu tür sorunları kolayca aşabiliriz. Metot isimleri aynı kalmak şartı ile parametre lsitelerini değiştirince Çiz metodunun 4 farklı hali şunlar olacaktır:

a. Çiz( şekil, kalem, çizgiTipi )
b. Çiz( şekil )
c. Çiz( şekil, kalem )
d. Çizi( şekil, ÇizgiTipi )

15. Tasarım aşamasında, değişebilir ve değişmeyen parçaları ayırmaya çalışın: Sistemde değişebilir elemanların olup olmadığını araştırın. Değişebilirleri ayrı sınıflar olarak tasarlayın ki ilerde bunlardaki değişmeler tüm sistem tasarımını veya önemli bir bölümünü değiştirmeye zorlamasın sizi.