SOLID

SOLID, nesne yönelimli programlama ve yazılım tasarımı için önerilen beş temel prensibin baş harflerinden oluşan bir kısaltmadır. Bu prensipler, yazılımın daha anlaşılır, esnek, sürdürülebilir ve bakımı kolay olmasını sağlamayı amaçlar. SOLID prensipleri, Amerikalı yazılım mühendisi ve eğitmen Robert C. Martin tarafından ilk olarak 2000 yılında yayımlanan "Tasarım İlkeleri ve Tasarım Modelleri" (Design Principles and Design Patterns) makalesinde tanıtılmıştır.[1][2][3][4]
"SOLID" kısaltması, 2004 yılı civarında Michael Feathers tarafından, Robert C. Martin’in ilkelerini sistematik biçimde adlandırmak üzere önerilmiştir.[5]
Bu ilkeler özellikle çevik yazılım geliştirme (agile development) ve uyarlanabilir yazılım metodolojilerinde temel felsefe olarak benimsenmiştir.[6]
S-O-L-I-D Kısaltması
[değiştir | kaynağı değiştir]SOLID ilkeleri şunlardır:
- S - Tek sorumluluk ilkesi (Single Responsibility Principle)
- O - Açıklık-kapalılık ilkesi (Open/Closed Principle)
- L - Liskov'un Yerine Geçme İlkesi (Liskov Substitution Principle)
- I - Arayüz ayrımı ilkesi (Interface Segregation Principle)
- D - Bağımlılığın tersine çevrilmesi ilkesi (Dependency Inversion Principle)
SOLID İlkeleri
[değiştir | kaynağı değiştir]Tek sorumluluk ilkesi (Single Responsibility Principle - SRP)
[değiştir | kaynağı değiştir]Bir sınıfın değişmesi için yalnızca bir nedeni olmalıdır. Her sınıf veya modül yalnızca tek bir sorumluluğa sahip olmalıdır.[7]
- Tek sorumluluk ilkesine uymayan sorunlu kod örneği:
Hem veri kaydeden hem de raporlayan tek bir sınıf.
class Rapor {
void VeritabaninaKaydet() { /* ... */ }
void RaporOlustur() { /* ... */ }
}
- Tek sorumluluk ilkesini uygulayan kod örneği:
Her sınıfın sadece bir sorumluluğu var.
class RaporOlusturucu {
void RaporOlustur() { /* ... */ }
}
class RaporKaydedici {
void VeritabaninaKaydet() { /* ... */ }
}
Açıklık-kapalılık ilkesi (Open/Closed Principle - OCP)
[değiştir | kaynağı değiştir]Yazılım varlıkları (arayüzler(soyutlama/interface), sınıflar, modüller, fonksiyonlar vb.) genişletmeye açık, ancak değişikliğe kapalı olmalıdır. Yani mevcut kodu değiştirmek yerine yeni işlevsellik eklemek için kodun genişletilmesi gerekir.[8]
abstract class Sekil {
public abstract double Alan();
}
class Dikdortgen : Sekil {
public override double Alan() { /* ... */ }
}
class Daire : Sekil {
public override double Alan() { /* ... */ }
}
Liskov'un yerine geçme ilkesi (Liskov Substitution Principle - LSP)
[değiştir | kaynağı değiştir]Alt sınıflardan oluşturulan nesneler, üst sınıfın nesneleri ile yer değiştirdiklerinde aynı davranışı sergilemelidir. Barbara Liskov tarafından 1987'de tanımlanan bu ilke, türetilmiş sınıfların, temel sınıfların yerine sorunsuzca kullanılabilmesini sağlar.[9]
Aşağıdaki örnekte Devekuşu, Kuş yerine geçemediği için LSP ihlal edilmiş olur.
class Kus {
public virtual void Uc() { /* ... */ }
}
class DeveKusu : Kus {
public override void Uc() { throw new Exception("Deve kuşu uçamaz!"); }
}
Arayüz ayrımı ilkesi (Interface Segregation Principle - ISP)
[değiştir | kaynağı değiştir]İstemciler, kullanmadığı arayüzlere(interface) bağımlı olmamalıdır veya bağımlı olmaya zorlanmamalıdır. Büyük ve genel arayüzler yerine, daha küçük ve özelleşmiş arayüzler oluşturulmalıdır.[10]
interface IYazici {
void Yazdir();
}
interface ITarayici {
void Tara();
}
class CokFonksiyonluYazici : IYazici, ITarayici { /* ... */ }
class BasitYazici : IYazici { /* ... */ }
Bağımlılıkların tersine çevrilmesi ilkesi (Dependency Inversion Principle - DIP)
[değiştir | kaynağı değiştir]Bu ilke temel olarak 2 ilkeye dayanır.
1- Üst seviye modüller, alt seviye modüllere bağlı olmamalıdır.
2- Üst seviye modüller arayüzler veya soyutlamalara bağımlı olmalıdır.[11]
interface IMesajGonderici {
void Gonder(string mesaj);
}
class EpostaGonderici : IMesajGonderici {
public void Gonder(string mesaj) { /* ... */ }
}
class Bildirim {
private IMesajGonderici gonderici;
public Bildirim(IMesajGonderici gonderici) { this.gonderici = gonderici; }
public void Bildir(string mesaj) { gonderici.Gonder(mesaj); }
}
Önemi ve Etkileri
[değiştir | kaynağı değiştir]SOLID prensipleri yazılım geliştirme sürecinde aşağıdaki katkıları sağlar:
- Kodun yeniden kullanılabilirliğini artırır
- Sistemin bakımını ve genişletilmesini kolaylaştırır
- Daha test edilebilir ve modüler sistemler sağlar
- Yazılımda esneklik ve ölçeklenebilirliği destekler
Ayrıca bakınız
[değiştir | kaynağı değiştir]- Nesne yönelimli programlama
- Tasarım desenleri (Design Patterns)
- Temiz Kod (Clean Kod[12])
- GRASP (nesne yönelimli tasarım)
- Kalıtım
Kaynakça
[değiştir | kaynağı değiştir]- ^ "ArticleS.UncleBob.PrinciplesOfOod". butunclebob.com. 25 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 2 Mayıs 2025.
- ^ Martin, Robert C. (2000). "Design Principles and Design Patterns" (PDF). 6 Eylül 2015 tarihinde kaynağından (PDF) arşivlendi.
- ^ "Getting a SOLID start. - Clean Coder". sites.google.com. 17 Eylül 2013. 17 Eylül 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 2 Mayıs 2025.
- ^ Confreaks (24 Mart 2015), GORUCO 2009 - SOLID Object-Oriented Design by Sandi Metz, 29 Şubat 2020 tarihinde kaynağından arşivlendi2 Mayıs 2025
- ^ Martin, Robert C. (12 Eylül 2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449432-6.
- ^ Sandi Metz (May 2009). "SOLID Object-Oriented Design". YouTube. 29 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 13 Ağustos 2019.
- ^ Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2003. s. 95. ISBN 978-0135974445. 6 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 2 Ekim 2025.
- ^ "Open/Closed Principle" (PDF). 5 Eylül 2015 tarihinde kaynağından (PDF) arşivlendi.
- ^ "Liskov Substitution Principle" (PDF). 5 Eylül 2015 tarihinde kaynağından (PDF) arşivlendi.
- ^ "Interface Segregation Principle" (PDF). 1996. 5 Eylül 2015 tarihinde kaynağından (PDF) arşivlendi.
- ^ "Dependency Inversion Principle" (PDF). 5 Eylül 2015 tarihinde kaynağından (PDF) arşivlendi.
- ^ Martin, Robert C. (12 Eylül 2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design (İngilizce). Prentice Hall. ISBN 978-0-13-449432-6.