Yazılım yapmayı zorlaştıran her zaman kod birimleri arasındaki bağimlılıklar ve bu bağımlılıkların yönetimi olmuştur. Bu bağımlılıkları tamamen yok etmek yazılım sistemini anlamsız kılarken, kontrolden çıkmalarına göz yummak yazılım sisteminin ölüm fermanı olabilir. Yazılım mühendisi bunu bilir ve gerekli gördüğü yerlerde DIP, ISP ve SRP gibi tasarım prensiplerini kullanarak kodu dokur.
Kategori arşivi: Tasarım Prensipleri
SOLID
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation ve Dependency inversion) yazılım tasarım prensipleri için kullanılan bir kısaltmadır. Yazılım yaparken SOLID uygulandığı taktirde bakımı ve geliştirilmesi kolay yazılım sistemleri oluşturmak mümkündür. En verimli hali test güdümlü yazılım ile uygulanır. Okumaya devam et
Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi
Bu yazıyı PDF olarak edinebilirsiniz.
Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi (17,2 KiB, 5.951 yükleme)
Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi
Bu yazıyı PDF olarak edinebilirsiniz.
Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi (43,3 KiB, 5.236 yükleme)
Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi
Bu yazıyı PDF olarak edinebilirsiniz.
Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi (36,8 KiB, 4.445 yükleme)
Common Closure Principle (CCP) – Ortak Kapama Prensibi
Yazılım sistemi müşteri gereksinimleri doğrultusunda zaman içinde değişikliğe uğrar. Meydana gelen değişiklerin sistemde bulunan birçok paketi etkilemesi, sistemin bakılabilirliğini negatif etkiler. CCP’ye göre yapılan değişikliklerin sistemin büyük bir bölümünü etkilemesini önlemek için, aynı sebepten dolayı değişikliğe uğrayabilecek sınıfların aynı paket içinde yer alması gerekir. CCP daha önce incelediğimiz, sınıflar için uygulanan Single Responsibility (SRP) prensibinin paketler için uygulanan halidir. Her paketin değişmek için sadece bir sebebi olmalıdır. CCP uygulandığı taktirde sistemin bakılabilirliği artırılır ve test ve yeni sürüm için harcanan zaman ve emek azaltılır.
Common Reuse Principle (CRP) – Ortak Yeniden Kullanım Prensibi
Bu prensip hangi sınıfların aynı paket içinde yer alması gerektiği konusuna açıklık getirir. CRP’ye göre beraberce tekrar kullanılabilir yapıda olan sınıfların aynı paket içinde olması gerekir.
Reuse-Release Equivalence Principle (REP) – Tekrar Kullanım ve Sürüm Eşitliği
Program modülleri paketler (packages) kullanılarak organize edilir. Paketler arasında sınıfların birbirlerini kullanmalarıyla bağımlılıklar oluşur. Bunun bir örneği resim 1 de yer almaktadır. Eğer paket B bünyesindeki bir sınıf paket A bünyesinde bulunan bir sınıf tarafından kullanılıyorsa, bu paket A’nin paket B’ye bağımlılığı olduğu anlamına gelir. Bu tür bağımlılıkların oluşması doğaldır. Amaç bu bağımlılıkları ortadan kaldırmak değil, kontrol edilebilir hale getirmek olmalıdır. Bu amaçla paket bazında uygulanabilecek tasarım prensipleri oluşturulmuştur. Bunlardan birisi Reuse-Release Equivalence (tekrar kullanım ve sürüm eşitliği) prensibidir.
Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi
Birbiriyle ilişkili olmayan birçok metodu ihtiva eden büyük bir interface sınıf yerine, birbiriyle ilişkili (cohesive) metotların yer aldığı birden fazla interface sınıfı daha makbuldür.
ISP uygulanmadığı taktirde, birden fazla sorumluluğu olan interface sınıflar oluşur. Zaman içinde yüklenen yeni sorumluluklarla bu interface sınıflar daha da büyür ve kontrol edilemez bir hale gelebilir. Bunun bir örneğini resim 1 de görmekteyiz.
Dependency Inversion Principle (DIP) – Bağımlılıkların Tersine Çevrilmesi Prensibi
Bu prensibe göre somut sınıflara olan bağımlılıklar soyut sınıflar ve interface sınıflar kullanılarak ortadan kaldırılmalıdır, çünkü somut sınıflar sık sık değişikliğe uğrarlar ve bu sınıflara bağımlı olan sınıflarında yapısal değişikliğe uğramalarına sebep olurlar. Okumaya devam et
Liskov Substitution Principle (LSP) – Liskov’un Yerine Geçme Prensibi
Barbara Liskov tarafından geliştirilen bu prensip kısaca şöyle açıklanabilir:
Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar.
Open Closed Principle (OCP) – Açık Kapalı Tasarım Prensibi
Yazılım disiplininde değişmeyen birşey varsa o da değişikliğin kendisidir. Birçok program müşteri gereksinimleri doğrultusunda ilk sürümden sonra değişikliğe uğrar. Bu doğal bir süreçtir ve müşteri programı kullandıkça ya yeni gereksinimlerini ya da mevcut fonksiyonlar üzerinde adaptasyonları gerekçe göstererek programın değiştirilmesini talep edecektir.
Loose Coupling (LC) – Esnek Bağ Tasarım Prensibi
Bir program bünyesinde, tanımlanan görevlerin yerine getirilebilmesi için birden fazla nesne görev alır. Bu nesneler birbirlerinin sundukları hizmetlerden faydalanarak kendi görevlerini yerine getirirler. Bu durumda nesneler arası bağımlılıklar oluşur. Bir nesne kullandığı diğer bir nesne hakkında ne kadar fazla detay bilgiye sahip ise, o nesneye olan bağımlılığı o oranda artar. Oluşan her bağımlılık bir sınıf için dolaylı olarak yapısal değiştirilme rizikosunu artırır, çünkü bağımlı olduğu sınıf üzerinde yapılan her değişiklik kendi yapısında değişikliğe neden olacaktır. Bu durum programın genel olarak kırılgan bir hale gelmesini kolaylaştıracaktır.
Single Responsibility Principle (SRP) – Tek Sorumluk Tasarım Prensibi
Resim 1 deki gibi bir sınıfa daha önce bir yerlerde rastlamışsınızdır. Bu sınıf kendisini bilgibankasına ekleme, silme, müşteriye email gönderme, login yapma (shop sistemi olabilir) ve sipariş oluşturma işlemlerini yapabilmektedir.