Yazılım geliştirmede, kodun okunabilirliği, sürdürülebilirliği ve değiştirilebilirliği önemli unsurlardır. Bu noktada, SOLID prensipleri, yazılım geliştirmenin temel taşlarını oluşturan beş prensipten oluşan bir rehberdir. Bu prensipler, yazılım tasarımını daha esnek ve anlaşılır hale getirerek, geliştiricilere yol gösterir. Şimdi, SOLID prensiplerini ayrıntılı bir şekilde inceleyelim.
1. S (Single Responsibility Principle – Tek Sorumluluk Prensibi)
Bu prensip, bir sınıfın veya modülün sadece bir sorumluluğu olması gerektiğini belirtir. Yani, bir sınıfın değişiklik nedeni sadece bir olmalıdır. Bu sayede, kodun daha anlaşılır, bakımı daha kolay ve değişikliklere daha açık olmasını sağlar.
class KargoIslemleri {
kargoGonder() { /* ... */ }
kargoIzle() { /* ... */ }
faturaKes() { /* ... */ }
}
Bu sınıfın her üç fonksiyonu da farklı sorumlulukları yerine getiriyor. SOLID prensiplerine uygun hale getirmek için bu fonksiyonları ayrı sınıflara bölmek daha doğru olacaktır.
2. O (Open/Closed Principle – Açık/Kapalı Prensibi)
Bu prensip, bir sınıfın genişletilmeye açık, değiştirmeye kapalı olması gerektiğini ifade eder. Yeni özellikler eklemek için sınıfı değiştirmek yerine, var olan kodu genişletmek tercih edilmelidir.
Örnek:
class Odeme {
odemeYap() { /* ... */ }
}
class KrediKartiOdeme extends Odeme {
taksitYap() { /* ... */ }
}
Bu şekilde, yeni bir ödeme yöntemi eklemek için Odeme sınıfını değiştirmek zorunda kalmazsınız. Yalnızca yeni bir sınıf oluşturarak genişletebilirsiniz.
3. L (Liskov Substitution Principle – Liskov Yerine Koyma Prensibi)
Bu prensip, bir sınıfın alt sınıflarının, üst sınıfın yerine kullanılabilecek şekilde tasarlanması gerektiğini belirtir. Yani, alt sınıflar, üst sınıfların yerine geçebilmelidir ve beklenen davranışı sergilemelidir.
Örnek:
class UcanKus {
uc() { /* ... */ }
}
class Penguen extends UcanKus {
// Hatalı örnek, penguen uçamaz!
uc() { throw new Error("Penguenler uçamaz!"); }
}
Bu durum, Penguen sınıfının UcanKus sınıfından türetilmesinin yanlış olduğunu gösterir. Çünkü penguenler uçamaz, bu nedenle uc metodunu kullanmak beklenen bir davranış değildir.
4. I (Interface Segregation Principle – Arayüz Ayrımı Prensibi)
Bu prensip, bir sınıfın ihtiyaç duymadığı metodları içeren arayüzleri uygulamaması gerektiğini ifade eder. Bir sınıf, yalnızca ihtiyaç duyduğu metodları içeren arayüzleri uygulamalıdır.
Örnek:
// Hatalı örnek, IAracArayuzu'nü implemente etmek gereksiz metodları getirir.
class Araba implements IAracArayuzu {
hareketEt() { /* ... */ }
dur() { /* ... */ }
sirenCal() { /* ... */ } // Araba bu metodu kullanmaz
}
Bu durumda, IAracArayuzu arayüzünü implemente etmek yerine, sadece Araba’nın ihtiyaç duyduğu metotları içeren bir arayüz tasarlamak daha doğru olacaktır.
5. D (Dependency Inversion Principle – Bağımlılıkların İnversiyonu Prensibi)
Bu prensip, yüksek seviyeli modüllerin, düşük seviyeli modüllere bağlı olmamalıdır. İkisi de soyuta bağlı olmalıdır. Soyutlamalar detaylara bağlı olmamalıdır.
Örnek:
// Hatalı örnek, yüksek seviyeli modül düşük seviyeli modüle bağımlıdır.
class VeritabaniBaglantisi {
// Detaylar burada...
}
class KullaniciServisi {
private veritabaniBaglantisi: VeritabaniBaglantisi;
constructor() {
this.veritabaniBaglantisi = new VeritabaniBaglantisi();
}
// Detaylara bağlıdır...
}
Bu durumda, KullaniciServisi sınıfı düşük seviyeli VeritabaniBaglantisi sınıfına doğrudan bağlıdır. Bu yerine, bağımlılığı tersine çevirmek için bir arayüz veya soyutlama eklemek daha doğru olacaktır.
Umarım bu yazımız, SOLID prensiplerini anlamanıza ve yazılım geliştirmenizde uygulamanıza yardımcı olur. Bu prensipleri benimsemek, kodunuzun daha temiz, esnek ve sürdürülebilir olmasına katkı sağlayacaktır.
0 yorum