Nesne Yönelimli Programlama Prensipleri

(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

Yorum Yapın