|
|
|
C# Programlama Rehberi - 1 |
|
| Gönderiliyor lütfen bekleyin... |
|
|
Geçen gece evdeki
bilgisayarımda elektronik kitaplarımı karıştırırken rastlantı eseri gözüme takılan
ve okuduğumda çok hoşuma giden bir rehber oldu. Rehberde C# ile nesne yönelimli
yazılım geliştirirken hem tasarım hem de uygulama aşamasında bizlere çok yradımcı
olacak tavsiyeler bulunmaktaydı. Bu altın değerindeki öğütleri tüm yazılımcı
arkadaşlarla paylaşmak istedim. Hatta okurken kendi kendime yaptığım yorumları
da Çevirmenin Notu şeklinde sizlere aktarmayı uygun gördüm.
Rehberde altmışın
üzerinde madde olmakla birlikte bunların yarıya yakını sistem analizi ve tasarımı
ile ilgilidir. Diğer kalan ksımı ise sistemin uygulanması(implementasyonu) konusunu
kapsamaktadır.
Bu
belge Thinking In C# (Larry O’Brien & Bruce Eckel ) kitabının sonundaki
EK C’den Türkçe’ye çevrilmiştir.
Bu dökümanda;
yazılım geliştirirken alt seviye tasarım ve kod yazma hususunda biz programcılara
yardım edecek, rehber olacak, bir takım öneriler bulunmaktadır. Burda yazılanlar
birer öneri olup birer kural olarak algılanmamalıdır. Dökümanda bahsedilenler
önceki deneyimlere dayanarak ortaya çıkan parlak fikirler olarak da görülebilir.
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.
Makale:
C# Programlama Rehberi - 1 C#, Visual C# ve .NET Ahmet Faruk Nacaroğlu
|
|
|
|
|
-
-
Eklenen Son 10
-
Bu Konuda Geçmiş 10
Bu Konuda Yazılmış Yazılmış 10 Makale Yükleniyor
Son Eklenen 10 Makale Yükleniyor
Bu Konuda Yazılmış Geçmiş Makaleler Yükleniyor
|
|
|