Değişken İsimlendirme Standartları

Ekim 24, 2008

Arkadaşlar program yazarken işinizi kolaylaştıracak, sizi kodlar arasındaki karışıklıklardan kurtaracak olan pratik bir bilgi.

Değişkenin türü
İsimlendirme şekli Örnek
Private “_” ile başlayan, Camel Casing _userCode
Public Pascal Casing UserCode
Property Pascal Casing UserCode
Scope değişkenleri – geçici değişkenler Camel Casing userCode
Method İsimleri Pascal Casing GetUserCode
Method parametreleri “p” ile başlayan, Pascal Casing pUserCode
Class İsimleri Pascal Casing User
Structure İsimleri “Str” ile başlayan Pascal Casing StrUserData
Enum İsimleri Pascal Casing UserType
Interface “I” ile başlayan, Pascal Casing IUser
Exception class’ları Sonu “Exception” ile biten, Pascal Casing UserNotFoundException
GUI form ve Control’ler (Windows ve Web) Hungarion Notation txtUserCode, frmMessage

Add to Technorati Favorites


String.Format

Ekim 15, 2008

Programlarımızda sık yaptığımız işlerden birisi de sayıları veya string tipindeki ifadeleri belli bir formata göre yazdırmaktır. Mesela, Ürün fiyatının binler basamakları nokta ile ayrılması ve virgülden sonra sadece iki rakamın gösterilmesinin sağlanması gibi. Bu yazımızda bu ve benzer isteklerimizi karşılayan string.format fonksiyonunu kısaca inceleyeceğiz.

Genel kullanım :

String yenistring = String.Format(�Birim Fiyatı : {0}�,fiyat);

Burada {0} ifadesiyle, ifadenin yerine fiyat isimli değişkenin geleceğini belirtiyoruz. Bu şekilde birden fazla değişken tanımlaması yapabiliriz.

Uygulama Üzerinde Örnek

Basit bir örnekle kullanım şeklini görelim.Yeni bir web projesi oluşturalım ve sayfanın Page_Load özelliğine aşağıdaki kodları yazalım.

string _today = DateTime.Now.ToString(“dd.MM.yyyy”);
string tarih = string.Format(“Tarih : {0}”, _today);
Response.Write(tarih);

Uygulamayı aşağıdaki linkten indirebilirsiniz.
http://uploaded.to/?id=75wriq

Kaynak :
http://www.csharpnedir.com/makalegoster.asp?MId=486

Add to Technorati Favorites


Neden OOP?

Ekim 15, 2008

1. Kod güvenliği ve tutarlılık
2. Hızlı geliştirme ve merkezi yönetim
3. Az kodla çok iş
4. Gerçek hayatın modellenmesi
5. Doğru kodun doğru yerde yazılması
6. Her class’ın kendi işini yaptığı kod

Add to Technorati Favorites


Nesne Yönelimli Programlamanın Özellikleri

Ekim 15, 2008

Encapsulation (Kapsülleme) : Bu özellik bize dilediğimiz değişken ve fonksiyonları saklama, dilediklerimizi halka açma şansını verir.Public ve private kavramları encapsulation konusunun temelini teşkil eder.

Inheritance (Miras Alma) : Bu özellik temel sınıfların özelliklerinin yeni sınıflar tarafından otomatik olarak devralınmasını sağlar. Yeni sınıflar temel sınıflardan miras aldıkları özellikleri modifiye edebilir veya üzerine yenilerini ekleyebilirler.

Polymorphism (Polimorfizm) : Bu özellik aynı fonksiyonun farklı sınıflarda farklı şekillerde davranabilmesini sağlar.

Kaynak : Programcılık Mantığı (s.295) kitabı

Add to Technorati Favorites


Nesne Yönelimli Programlama Prensipleri

Ekim 15, 2008

(Object Oriented Programming Principles)

- Single Responsibility Principle

Single Responsibility Principle(SRP) bir ilkedir ve nesneye yönelik programlama da nasıl kodlama yapılmalıdır,tasarım nasıl tutulmalıdır sorularına verilebilecek cevaplardan bir tanesidir.

Her sınıfa verilebilecek en az görev verilmeli, her sınıf ayrı bir iş yapmalıdır.

ÖRNEK

Bilgi tutma ayrı bir iştir, bilgi kaydetme ayrı bir iştir. Aynı class hem bilgi tutup hemde bilgi kaydetme ile ilgili metoda sahip olmamalıdır.

Kitap class’ı id, ad, fiyat değerlerini tutan bir nesnedir. KitapManager class’ı kitap nesnesini parametre alan kaydet methoduna sahiptir. Böylelikle herkes kendi işini yapar.

- Open Closed Principle

Bu prensibin amacı test edilmiş kodun tekrar test edilmemesi sadece değişiklik yaptığımız yeri test etmemizdir. Sınıflar değişikliğe kapalı olmalıdır. Çünkü bir sınıfta değişiklik yapmak, buna bağlı bulunan bundan türeyen veya bunu kullanan diğer tüm sınıfları da buna uygun hale getirmeyi veya en azından yeniden derlemeyi, versiyon atlatmayı ve müşteriye yeniden yüklemeyi gerektirir.

Her turlu yazılım birimi geliştirmeye ve genişlemeye açık ancak modifikasyona kapalı olmalıdır.

- Liskov Subsitution Principle

Bir temel sinifta referans ya da pointeri kullanan fonksiyon, bu temel siniftan turetilen bir baska sinifi da sorunsuz olarak onun yerine kullanabilmelidir.

Çok parametreli az parametreliyi her zaman base alır.

ÖRNEK

Örneğin daire ve elips çizmek istiyoruz . İkiside birbirine çok yakın şekiller.Bu nedenden dolayı önce şekilleri nasıl çizebileceğimizi düşünmemiz gerekiyor.Daireyi yarı çap değeri vererek çizebilirz (r,r), elips için ise iki farklı değer atamamız gerekecek (a,b). İkisi içinde ayrı ayrı kod yazmak yerine daireyi elips sınfından türetebiliriz.

- Dependency Inversion Principle

Bu prensip OCP’nin (Open-Close Principle) direk bir sonucudur. Prensibe göre, ileride değişmesi muhtemel somut sınıflara direk erişmek yerine, bu sınıflara arayüz veya soyut sınıflar üzerinden erişmemiz gerekir. Bu yolla somut sınıflara ve bunların eriştiği tüm diğer somut sınıflara olan bağımlılığı yokedebiliriz. Bu prensibe aykırı yapılar, birbirine bağımlı sınıflar doğurur, ki bu da temelde OCP (Open-Close Principle), yani değişmeden genişleyebilme prensibine terstir. Çünkü bir sınıfta yapılacak olan değişiklik, diğer tüm sınıflarda değişiklik yapmayı gerektirebilir.

Örneği alınabilen sınıfların bağımlılıkları abstractlar üzerinden kurulmalı.

- Interface Segregation Principle

İyi tanımlanmış her bir yetenek için ayri bir arayüz tanımlanmasını öneren nesne yönelimli yazılım geliştirme prensibidir.

Sırf abstraction yapmak için içine bir sürü şey doldurulmuş tek bir interface hazirlamak yerine, her biri ayrı bir işlevi tanımlayan birden fazla interface tanımlamak daha iyi olacaktır. Bunun yarari bir gün o devasa interface’i kullanan başka bir class tanımlamaya kalkarsanız hiç gereği yokken diğer metodları da implemente etmekle uğraşmamaktır.

- Reuse Release Equivalency Principle

Bu prensip genelde bir uygulama üzerinde birden fazla takım çalışıyorsa kullanılır. System yoluyla released edilmiş componentler efektif şekilde kullanılabilir.

Tekrar kullanılabilir olanlar bir arada paketlenir.

- Common Closure Principle

Bu prensip yapı içindeki class’larin değişikliklerden etkilenmesini önlemek gerektiğini öngürür.

Çünkü yapı üzerindeki değişiklik, içindeki class’larıda etkileyebilir.

- Common Reuse Principle

Herhangi bir class’ta yapılan değişiklik yapının yeni bir versiyonunu oluşturmuş olur.

Bir yapı içindeki bütün classlar tekrar kullanılabilir halde olmalı.

- Acyclic Dependencies Principle

Eğer programınız birbirleriyle ilişkili yapıları olduğu gibi kullanacaksa dependencyler en üstten yani root’tan en alt kadameye kadar ayarlanmalı.

- Stable Abstractions Principle

Stabilitesi fazla olan yapıların abstraction’ı da fazla olmalı ve stable paketler arasında abstract sınıflar olmalı.

Kötü Tasarım İlkeleri

Rigidity : Yaptığınız değişikliğin bir çok yeri etkilemesi.

Immability : Bir modülün başka bir yerde kullanıyor olması.

Fragility : Bir değişiklik başka yerleri kırıyor, sorun çıkartıyor.


Add to Technorati Favorites