SOLID prensipleri: esnek ve bakımı kolay sınıf tasarımı için beş ilke
SOLID, nesne yönelimli yazılımı bakımı kolay ve esnek tasarlamaya yarayan beş ilkenin baş harfleridir. Her ilkenin anlamı ve örneği burada.
SOLID nedir?
SOLID, nesne yönelimli tasarımda sınıfların ve modüllerin değişime dayanıklı, anlaşılır ve test edilebilir olmasını amaçlayan tasarım ilkelerinin baş harflerinden oluşan kısaltmadır. İlkeler, yazılım mühendisi Robert C. Martin'in çalışmalarıyla yaygınlaştı; bu isim ilkeleri bir araya getiren kısaltmayı yaygın hale getirdi.
Bunlar kesin kurallar değil, tasarım kararlarını değerlendirmek için kullanılan yol göstericidir. Ortak hedefleri şudur: bir yerdeki değişiklik, ilgisiz başka yerleri bozmasın.
Beş ilke ve anlamları
- S, Tek Sorumluluk İlkesi (Single Responsibility): Bir sınıfın değişmesi için tek bir sebep olmalıdır. Hem fatura hesaplayan hem de PDF üreten hem de e-posta gönderen bir sınıf, farklı sebeplerle değişir; bunları ayırmak gerekir.
- O, Açık-Kapalı İlkesi (Open-Closed): Yapılar genişlemeye açık, değişime kapalı olmalıdır. Yeni bir ödeme yöntemi eklerken mevcut kodu değiştirip koşul eklemek yerine, ortak bir arayüzü uygulayan yeni sınıf yazılır.
- L, Liskov İkame İlkesi (Liskov Substitution): Alt sınıf nesneleri, üst sınıf beklenen yerde sorunsuz kullanılabilmelidir. Üst sınıfın sözünü bozan alt sınıf bu ilkeyi çiğner.
- I, Arayüz Ayrıştırma İlkesi (Interface Segregation): İstemciler kullanmadıkları metotlara bağımlı olmaya zorlanmamalıdır. Büyük bir arayüz yerine küçük ve amaca özel arayüzler tercih edilir.
- D, Bağımlılık Tersine Çevirme İlkesi (Dependency Inversion): Üst düzey iş mantığı alt düzey ayrıntılara değil, soyutlamalara bağlı olmalıdır.
Kısa bir örnek: Açık-Kapalı ve Bağımlılık Tersine Çevirme
Örneğin bir sipariş servisi, ödeme yapmak için doğrudan belirli bir sağlayıcının sınıfını çağırıyor ve yeni bir yöntem eklendiğinde servisin içindeki koşullar büyüyor. SOLID'e uygun tasarımda servis, ödeme alma işini tanımlayan bir arayüze bağımlıdır. Kart, havale ya da cüzdan bu arayüzü uygulayan ayrı sınıflardır; hangisinin kullanılacağı dışarıdan verilir.
Sonuç: yeni yöntem eklemek servise dokunmayı gerektirmez, sınıflar birbirinden bağımsız test edilebilir ve ödeme sağlayıcısı değiştiğinde iş mantığı etkilenmez. Test sırasında gerçek ödemeyi çağırmak yerine sahte bir uygulama enjekte edilebilir.
Liskov ihlali nasıl görünür?
Klasik örnek, bir 'kuş' sınıfının uçma davranışı tanımlaması ve bunun alt sınıfı olan 'penguen'in uçamaması yüzünden hata fırlatmasıdır. Kodun 'her kuş uçabilir' varsayımıyla yazılmış bölümü, penguen geldiğinde bozulur. Çözüm, davranışı doğru soyutlamaya ayırmak ve kalıtımı yalnızca gerçek 'is-a' ilişkisinde kullanmaktır.
Bu ilkeyi sezmenin pratik yolu şudur: alt sınıfta bir metot boş bırakılıyor, hata veriyor ya da üst sınıfın koşullarını sıkılaştırıyorsa tasarımı gözden geçirin.
Diğer kavramlarla ilişkisi
SOLID, tasarım desenleri (design patterns) ve temiz mimari (clean architecture) ile birlikte anılır. Desenler somut çözüm şablonlarıdır, SOLID ise bu çözümlerin neden iyi çalıştığını açıklayan ilkelerdir. Temiz mimarideki katman bağımlılık yönü, bağımlılık tersine çevirme ilkesinin mimari ölçeğe taşınmış halidir. Yeniden düzenleme (refactoring) ise mevcut kodu bu ilkelere yaklaştırma çalışmasıdır.
Sık yapılan hatalar
En yaygın hata ilkeleri aşırı uygulamaktır: her sınıf için arayüz ve her arayüz için fabrika yazmak, küçük bir problemi gereksiz soyutlamayla boğar. İlkeler, değişimin gerçekten beklendiği yerde işe yarar; bugünden öngörülemeyen esnekliği kurmak zaman kaybıdır.
Diğer hatalar: tek sorumluluğu 'tek metot' sanmak, ilkeleri ezberleyip koddaki gerçek acı noktalarını görmemek ve kalıtımı her yerde kullanmak. İyi yol, önce kodu yazıp gerçek değişim ihtiyacı çıkınca ilkeye göre düzenlemektir.
Mindset programlarında nerede işlenir?
Mindset'in SOLID Prensipleri ve Nesne Yönelimli Tasarım eğitimi, nesne yönelimli tasarımın temelleri, tek sorumluluk, açık-kapalı, Liskov ikame ve arayüz ayrıştırma, bağımlılık tersine çevirme ile ilkelerin birlikte uygulanması başlıklarını işler.
İlgili Mindset programı
SOLID Prensipleri ve Nesne Yönelimli Tasarım
Sık sorulan sorular
SOLID sadece Java ya da C# için mi geçerli?
Hayır. İlkeler nesne yönelimli bir dilde sınıflarla anlatılır ama fikir dilden bağımsızdır: sorumlulukları ayırmak, soyutlamaya bağlanmak ve genişlemeyi kolaylaştırmak işlevsel ya da modüler tasarımda da karşılık bulur. Dilin kolaylıkları ilkelerin biçimini değiştirir.
SOLID'in hepsine her zaman uymak zorunda mıyım?
Hayır. İlkeler bir kontrol listesi değil, dengelenecek yönlerdir. Küçük ve kısa ömürlü kodda tam uyum gereksiz karmaşıklık yaratabilir. Kodun sık değiştiği, ekibin büyüdüğü ve test zorlaştığı yerlerde ilkeler daha fazla değer üretir.
Tek sorumluluk ilkesi 'bir sınıf bir iş yapar' demek midir?
Tam olarak değil. İlke, sınıfın değişmesi için tek bir sebep olması gerektiğini söyler; yani aynı aktörün aynı gerekçeyle değiştireceği şeyler birlikte durur. Bir sınıfın birçok metodu olabilir, yeter ki bunlar aynı sorumluluğa hizmet etsin.
SOLID'i öğrenmeye nereden başlamalı?
Önce nesne yönelimli temelleri (kapsülleme, kalıtım, çok biçimlilik) kavrayın. Sonra tek sorumluluk ve bağımlılık tersine çevirmeyi kendi kodunuzda deneyin; bu ikisi en hızlı fayda sağlar. Diğer ilkeler yeniden düzenleme sırasında doğal olarak öne çıkar.