SOLID
Tek Sorumluluk, Açık–Kapalı, Liskov Yerine Geçme, Arayüz Ayrımı, Bağımlılığın Tersine Çevrilmesi
Kısaca
SOLID, geliştiricilerin daha anlaşılır, genişletilebilir, test edilebilir ve bakımı kolay kod yazmasına yardım eden beş nesne yönelimli tasarım ilkesidir.
SOLID ilkeleri nelerdir?
SOLID, yazılım mühendisi Robert C. Martin'in 2000'lerin başında yaygınlaştırdığı, sınıf ve modül tasarımına dair beş yönergenin kısaltmasıdır. Her harf bir ilkeyi temsil eder ve birlikte kodun esnek kalmasını, yani yeni özellikler eklenirken mevcut olanların bozulmamasını amaçlar. En çok nesne yönelimli programlamada konuşulur, ancak fikirler birçok kod türüne uygulanabilir.
S, Tek Sorumluluk İlkesi'dir (Single Responsibility): bir sınıfın değişmesi için yalnızca tek bir neden olmalıdır. O, Açık–Kapalı İlkesi'dir (Open–Closed): kod genişletmeye açık, değiştirmeye kapalı olmalıdır; yani yeni davranışı çalışan kodu düzenleyerek değil, yeni kod yazarak eklersiniz. L, Liskov Yerine Geçme İlkesi'dir (Liskov Substitution): bir alt sınıf, üst sınıfının beklendiği her yerde çalışabilmelidir.
I, Arayüz Ayrımı İlkesi'dir (Interface Segregation): sınıfları ihtiyaç duymadıkları metotları uygulamaya zorlayan tek bir büyük arayüz yerine, birkaç küçük ve odaklı arayüz daha iyidir. D, Bağımlılığın Tersine Çevrilmesi İlkesi'dir (Dependency Inversion): üst düzey kod, belirli bir veritabanı sınıfı gibi somut ayrıntılara değil, arayüz gibi soyutlamalara bağımlı olmalıdır.
İyi düzenlenmiş bir alet çantası güzel bir benzetmedir: her alet tek bir işi yapar, yeni aletler eskilerine dokunmadan eklenebilir ve doğru ölçüdeki her tornavida aynı vidaya uyar. SOLID ilkeleri katı yasalar değil, yönergelerdir; fazla sıkı uygulanırsa çok sayıda küçücük sınıf ve gereksiz soyutlama katmanı ortaya çıkabilir.
Önemli noktalar
- S: Tek Sorumluluk, değişmek için tek bir neden.
- O: Açık–Kapalı, mevcut kodu düzenlemeden davranışı genişletmek.
- L: Liskov Yerine Geçme, alt sınıflar üst sınıflarının yerine güvenle geçebilmeli.
- I: Arayüz Ayrımı, küçük ve odaklı arayüzleri tercih etmek.
- D: Bağımlılığın Tersine Çevrilmesi, somut sınıflara değil soyutlamalara bağımlı olmak.
Örnek
// Depend on an interface, not on a concrete class
interface Notifier {
send(message: string): void;
}
class EmailNotifier implements Notifier {
send(message: string) { console.log("Email:", message); }
}
class OrderService {
constructor(private notifier: Notifier) {} // any Notifier works here
placeOrder() { this.notifier.send("Order placed"); }
}
new OrderService(new EmailNotifier()).placeOrder();Sık sorulan sorular
SOLID neyin kısaltmasıdır?
SOLID; Tek Sorumluluk (Single Responsibility), Açık–Kapalı (Open–Closed), Liskov Yerine Geçme (Liskov Substitution), Arayüz Ayrımı (Interface Segregation) ve Bağımlılığın Tersine Çevrilmesi (Dependency Inversion) ilkelerinin baş harflerinden oluşur.
Tek Sorumluluk İlkesi nedir?
Tek Sorumluluk İlkesi, bir sınıf ya da modülün değişmesi için yalnızca tek bir neden olması gerektiğini, yani sistemin davranışının yalnızca bir bölümünden sorumlu olduğunu söyler. Örneğin hem fatura hesaplayan hem de e-posta gönderen bir sınıf genellikle ikiye bölünmelidir.
SOLID ilkeleri nesne yönelimli programlama dışında da geçerli mi?
Evet. Küçük ve odaklı birimler ile soyutlamalara bağımlılık gibi altta yatan fikirler, ifade biçimi nesne yönelimli tasarımdan gelse de fonksiyonel ve modüler kodda da yararlıdır.
İlgili sayfalar
- OOPProgramlamanın Temelleri, s. 41OOP, yani nesne yönelimli programlama, kodu ilişkili verileri onlar üzerinde işlem yapan fonksiyonlarla birleştiren nesneler etrafında düzenleme yöntemidir.
- Tasarım DeseniYazılım Mimarisi, s. 42Tasarım deseni, yazılım tasarımında sık görülen bir soruna kanıtlanmış, yeniden kullanılabilir çözümdür; hazır kod değil, genel bir şablon olarak anlatılır.
- RefactoringYazılım Mimarisi, s. 32Refactoring, mevcut kodun dışarıdan görünen davranışını değiştirmeden daha temiz ve bakımı kolay hâle getirmek için yeniden yapılandırılması sürecidir.
- Teknik BorçYazılım Mimarisi, s. 43Teknik borç, daha uzun sürecek daha iyi bir yaklaşım yerine şimdi hızlı ya da sınırlı bir çözüm seçilmesiyle doğan, gelecekteki ek iş maliyetidir.
- Dependency InjectionYazılım Mimarisi, s. 10Dependency injection, bir nesnenin ihtiyaç duyduğu diğer nesneleri kendisi oluşturmak yerine dışarıdan almasını sağlayan bir tasarım tekniğidir.
- DRYYazılım Mimarisi, s. 13DRY, her bilgi ya da mantık parçasının çoğaltılmak yerine tek bir yetkili temsile sahip olması gerektiğini söyleyen bir yazılım tasarım ilkesidir.
- UyumYazılım Mimarisi, s. 45Uyum, bir modül, sınıf ya da servis içindeki sorumlulukların birbirine ne kadar ait olduğunun ölçüsüdür ve yüksek uyum iyi tasarımın işaretidir.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin