|
|
|
C# Programlama Rehberi - 2 |
|
| Gönderiliyor lütfen bekleyin... |
|
|
Geçen gece evdeki
bilgisayarımda elektronik kitapalrıımı karıştırıken rastlantı eseri gözüme takılan
ve okuduğumda çok hoşuma giden bir rehber oldu. Rehberde C# ile nesne yeönelimli
yazılım geliştirirken hem tasarım hem de uygulama ş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
makalenin başlangıcı olan
C# Programlama Rehberi - 1’i burdan okuayabilirsiniz.
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 husuunda 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.
16.
Temel fonksiyonelitelikleri genişletmek için sınıf türetmeye başvurmayın:
Eğer arayüz elemanlarından biri o sınıf için vazgeçilmez ise, o eleman ana sınıfta
bulunmalıdır. Eğer yeni metotlar eklerken kalıtım kullanıyorsanız tasarımınızı
bir kere daha gözden geçirmeyi aklınıza getirin.
17.
Azar Azar: Herhangi bir sınıf için; olabildiğince az arayüz
ile işe başlayın. Sınıfınız hali hazırdaki problemi çözecek kadar yetenekli
olursa başarılır. Sınıf ile ilgi şu an ihtiyaç duyulmayan elemanları eklemeye
kalkmayın. Sınıfınız kullanıldıkça onu genişletmenin yollarını, ihtiyaca binaen,
zaten kaşfedeceksiniz. Fakat bir sınıf herhangi başka bir kod tarafında kullanımda
iken sınıfın yeteneklerini kısmaya kalkmak ölümcül bir hata olacaktır. Eğer
yeni yeteneklere ihityacınız varsa bunları eklemniz sadece sınıfın kodunu tekrar
derlemek gerektirecektir. Eğer yeni ekledikleriniz arayüzde değişiklikler gerektiriyorsa,
eski arayüzü genişletin sadece. Eski arayüzü değiştirmek size ciddi anlamda
sorunlar yaratabilir. Ayrıca metot(lar)a yeni argüman ekleyeceğiniz durumlarda
arayüzün eski halini koruması için çok biçimlilikten faydalanın. Yani metotlara
aşırı yükleme yapın.
Çevirmenin
Notu: Aynı örneğimize( geometrik şekiller) devam edecek olursak;
ilk başta sizin ihtiyacınız olmadığı halde kalem ve çizgiTipi’ni belirteren
Çiz() metotlarını yazmayın. Her ne kadar işimizin olabildiğince ince düşünmeye
bizi alırsa bile? İlk hali ile Çiz( şekil ) olan metodumuzun sonradan Çiz( şekil,
kalem ) versiyonuna ihtiyaç duyarsak Çiz( şekil ) metodunu koruyun. Zaten nesne
yöenlimli proramlama yapıyoruz. Onun nimetlerinden biri olan çok biçimlilik
bize büyük bir nimet olarak verilmiş.
18.
Sınıflarınızın mantıklı olduğuna emin olmak için onları sesli biçimde okuyunuz:
Özellikle ana ve türeyen sınıflar arasındaki “is-a” ve sınıf içindeki nesnelerin,
sınıf ile olan “has-a“ilişkilerine dikkat ediniz.
Çevirmenin
Notu: Kare bir Dikdörtgen sınıfından türemiştir. O zaman kare bir
dikdörtgendir denilebilmeli ( “is-a” ilişkisi ). Öte yandan Dörtgen nesnemizin
köşelerinin koordinatlarını tutmak için 4 tane noktamızın olduğunu varsayalım.
Bu durumda her bir bir nokta nesesi Dörtgen sınıfının birer eleamanıdır( “has-a“
ilişkisi )
20.
Kalıtım ve kompozisyon arasında karar vermek durumunda kalırsanız türeyen sınıftan
temel sınıfa yukarı tür dönüşümüne ihtiyacınızın olup olmadığını kendinize sorunuz:
Eğer böyle bir tür dönüşümüne gerek duymacaksanız kopozisyonu tercih edin. Bu
sayede çok sayıda temel sınıf oluşmasını önlemiş olursunuz. Yok eğer kalıtım
kullanırsanız; sınıfınızı kullananlar yukarı yönde tür dönüşünü yapmaları gerektiği
hissine kapılabilirler.
21.
Sınıf içindeki değerlerdeki değişmeler ve temel sınıflardaki metotların üstüne
yazılması için üye değişkenlerini kullanarak sınıfınızın farklı işler yapmasını
sağlayın: Eğer sınıfınızdaki bir takım metotlar aldıkları parametre
veya üye değişkenlerinin değerlerine göre davranışlarını değiştiriyorlarsa;
tekrar bir tasarım yaparak daha iyi sonuçlar elde edebilirsiniz. Yeni tasarımızda
değişik sınıf davranışları için türeyen sınıflar ve metotların üstüne yazmayı
kullanmanız gerekecektir.
22.
Metotlara aşırı yüklemeyi kullanın: Bir metot kendisine geçirilen
argümanların tiplerine bakarak çalışmasında koşullu ifadelere yer vermemeli.
Bunun yerine iki veya daha fazla aşırı yüklenmiş metot hazırlamak daha uygun
olacaktır.
23.
Bazen basit bir kompozisyon işe yarar: Herhangi bir havayolu
şirketindeki “yolcu konforu sistemi” birbirinden bağımsız elemanlar oluşacaktır:
koltuk, klima, video vb.. Bunlarda her bir uçak için yüzlerce oluşturmak gerekecektir.
Her bir elemanı private üye değişken yapıp, onların her bir işlemi içinde yeni
arayüz oluşturmak çok mantıklımıdır? Onun yerine her bir eleanı public üye değişkeni
olarak tanımlamak ve bu üye değişkenlerin metot ve özelliklerine ulaşmayı serbest
bırakmak daha akılcı ve yeteri kadar güvenli bir çözüm olur. Öte yandan basit
kompozisyonun her zaman doğru bir çözmü olmamasına rağmen bu durumda işe yarayacaktır.
Çevirmenin
Notu: Sizin de bildiğiniz
gibi herhangi bir dörtgeni belirmek için 4 tane noktaya ihtiyacımız olacaktır.
Noktalarımızın isimleri n1, n2, n3 ve n4 olsun. Bunlardan herhangi birinin X
ve Y koordinatlarını değiştirmek için Dörtgen sınıfımız içinde 4 veya daha fazla
metot tanımlamaya ve Dörtgen sınıfının arayüzünü genişletmek ne kadar mantıklı
sizce? Eğer biz noktalarımızı public tanımlarsak onların koordinat değiştirme
özellik veya metoduna Dörtgen nesnemizden kolayca ulaşabiliriz ve sadeliği koruyabiliriz.
Örnek olarak:
Dörtgen
dörtgenim = new Dörtgen();
dörtgenim.n1.X
= 25;
dörtgenim.n1.Y = 43;
kullanımı
daha hoş olmazmıydı ?
24.
Sizin kodunuzu kullanacak ve bakımını yapacak programcıları düşünün:
Sınıfınlarınızı olabildiğince açık, net ve temiz tasarlayın. İlerki muhtemel
değişikleri düşünerek olabildiğince kolay değiştirebilir sınıflar tasarlayın.
Çevirmenin
Notu: Bilmiyorum siziz başınıza hiç geldi mi? Maalesef çok defa
başkasının hızlı ve kötü yazmış olduğu kodu değiştirmek zorunda kaldım. Hele
birileri yüzlerce satırlık kodda tek satır yorum yazmadıysa ve değişken isimleri
x1, z, t gibiyse çıldırmak elde değil. Aslında kendim bile 3 gün önce yazdığım
kodda neler olup bittiğini anlamakta zorluk çekiyordum. Bu durumda bol bol yorum
satırı yazmak, değişken, metot ve diğer sınıf üyelerinin isimleri amaçları doğrultusunda
yazmak en mantıklısı. Yoksa değil başkası kendi kodunuzun bakımını yaparken
bile kendizie hakaret etmemeniz kaçınılmazdır!
25.
Çok büyük nesne sendromuna düşmeyin: “Bu ne demek şimdi?” gibi
bir soru aklınıza gelecektir. Hemen açıklayalım isterseniz. Bu tür vakalarda
genelde uzun süre prosedüerk programlama yaptıktan sonra nesne yöenlimli programlama
yeni geçiş yapmışlarda görülür. Genelde belirtileri ise koca programı bir veya
iki nesne ile halletmeye çalışmalarıdır. Porgramdaki nesneler programın kendisin
değil sadece programdaki değişik ve küçük kavramları temsil etmelidir.
Çevirmenin
Notu: Bu birazda müslüman mahallesinde salyangoz satmaya benziyor.
Bir ipucu: sistem ile ilgili senaryoda isimler nesne olurken fiiller birer metot
olurlar.
26. Eğer
sınıf içinde herhangi bir şeyi çirkin veya hoş olayana bir şekilde yaptıysanız,
en azından bu çirkinliği sınıf içinde belirtiniz.
Çevirmenin
Notu: Yani delikanlı programcı ol canımı ye demek isteniyor burda...:-)
27.
Nesneleriniz sadece bir takım verileri tutmak için kullanılmamalı:
Sınıflarınızın üye değişkenleri gibi iyi tanımlanmış çeşitli davranışları(metotları)
da bulunmalıdır. Genelde veri yapıları verileri tutmak için iyi bir yol olmalarına
rağmen çok nadiren sadece verileri tutan sınıflar da tanımlamak ve kullanıma
açmak zorunda kalabilirsiniz.
28.
Önce Kompozisyonu deneyin: Eğer gerçekten gerekiyorsa kalıtımı
kullanın. Kompozisyonun sizin ihtiyaçlarınızı karşıladığı durumlarda yine de
kalıtım yapmayı seçerseniz gereksiz yere sistemi karmaşıklaştırmış olursunuz.
29.
Kalıtım ve metotlara aşırı yükleme ile davranışlardaki çeşitliliği ve alanlar
ile durumdaki değişkenlikleri ifade ediniz: En uçtaki örnek
olarak değişlik nesnelerin renklerini belirtmek için o nesneleri Renk sınıfından
türetme yerine her birinde renk isimli al anları kullanmak verilebilir.
30.
Uyuşmazlıklara dikkat edin: Birbirinden farklı gibi duran iki
farklı sınıfın aslında aynı temellere sahip olabilirler. Bu durumda birini diğerinden
türetmeniz tavsiye edilebilir. Fakat, tam anlamıyla bir ana ve türeyen sınıf
ilişkisi göremediyseniz ikisi için tek bir ana sınıf yapın ve bu ana sınıftan
iki sınıfınız da türesin. Belki biraz fazla kod yazmış olacaksınız ama; hem
kalıtımın faydalarından yararlanacaksınız hem de tasarımızla ilgili çok önemli
bir noktayı keşfedeceksiniz.
31.
Kalıtım sırasında sınırlandırmalara dikkat edin: En doğru tasarımda
kalıtım ile yeni sınıfa bir takım yenilikler eklenir. Diğer taraftan kalıtımla
oluşturulan sınıfa yeni bir şeyler eklenmemiş ve ana sınıftaki bazı yetenekler
silinmiş veya kısıtlanmışsa bu tasarıma şüpheyle bakılır. Yalnız “kurallar kırılmak
için yapılmıştır” düsturu bazı durumlarda geçerlidir. Eğer çok eski bir sınıf
kütüphanesi üzerinde çalışıyorsanız ve hali hazırdaki sınıf hiyerarşisi sizin
dilediğiniz gibi değilse türeyen bir sınıfı hiyerarşinin bir üst basamağına
taşımanız da gerekiyorsa yapacak bir şey yok. Yani türettiğiniz bir sınıfın,
temel sınıftan gelen bir takım özelliklerini kısıtlamanız gerekiyor...
32.
Analizdeki paralelliklere dikkat edin: Projelerde oğu zaman
herşeyi tam olarak öğrenmeden işe koyulmamız gerekiyor. Bu tür durumlarda olası
tüm ihtimalleri düşünüp onlara göre bir çok şey tasarlamak yerine ilerdeki değişmelere
göre değişime açık bir sistem tasarlamak daha mantıklı. Ne de olsa neyin nasıl
olacağını bilmek için neyin ne olduğunu bilmek gerekir. Nesne yönelimli metodoloji
sayesinde ilerde sınıflarınızın değişmesi sistemin bütünlüğüne karşı büyük bir
tehlike oluşturmayacaktır.
Çevirmenin
Notu: Nesne yönelimli programlanın bu yanını seviyorum. Bir sınıfın
arayüzünü değiştirmemek kaydı ile içinde ne yaparsan yap. Kimseyi rahatsız etmediğine
de emin olabilirsin. Eğer projenin tamamı hakkında yeteri kadar bilgiye sahip
değilsen ve bunu hemen elde etme şansın yoksa bildiğin kısımdan başla ve gerisini
sonra yaparsın ama çok dikkatli olmak şartı ile...
33.
Eğer güzel bir analiz, tasarım, ve implementasyon yaptığınıza kanaat getiriyorsanız;
çalışmanızı adım adım inceleyiniz: İnceleme işelmi için sizin
proje grubundan birinin kolundan tutun va masaya oturturun( bunun bir sanışman
olmasına gerek yok! ). Onunla birlikte yaptığınız çalışmayı adım adım ve detaylı
bir biçimde gözden geçirin. O kişi sizin göremediğiniz bir çok şeyi kolayca
görecektir ki bu birlikte çalışmanın size ve patronunuza zaman ve para bakımından
epey bir miktar tasarruf ettireceğine emin olabilirsiniz.
Çevirmenin
Notu: Açıkcası kendimde bu yöntemi kullanıyorum. Kimse böyle
bir yol izle demedi ama işi sağlam yapmaka adına başka bir proje grubundan birini
çekiyorum yanıma; kardeş bak bakalım olmuş mu? Eksik gedik veya gereksiz nereleri
var sence? İşin kötüsü her defasında kaydeğer değişiklikleri yapmak zorunda
kalıyorum. Ama projenin ilerleyen kısımlarında çok rahat ettiğimi de belirtmek
isterim...
Makale:
C# Programlama Rehberi - 2 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
|
|
|