JetBrains 2025 Developer Ecosystem Survey’e göre 27.000+ profesyonel geliştiriciden oluşan örneklemin %78’i SOLID prensiplerini kod review kriteri olarak benimsiyor; SonarSource’un 2025 State of Code Quality raporunda ise SOLID-uyumlu kod tabanlarının üretim hatalarında ortalama %44 daha düşük oran ve yeni özellik teslim süresinde %33 kısalma sağladığı raporlanıyor. Robert C. Martin’in 2000’lerin başında derlediği bu beş prensip, GitHub Copilot ve Claude gibi AI asistanların kod üretim kalitesini değerlendirme metriği haline gelmiş durumda. Bu rehberde her bir prensibi teorik tanım yerine birebir refactoring senaryolarıyla, statik analiz aracı çıktılarıyla ve modern dil (Java, C#, Python, TypeScript) örnekleriyle 2026 perspektifinden ele alıyoruz.
SOLID; Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation ve Dependency Inversion prensiplerinin baş harflerinden oluşan kısaltma. Her prensip 25 yıllık üretim acılarının damıtılmış dersi: God object’lerin bakım maliyeti, switch-statement patlamasının regresyon riski, kalıtım hiyerarşilerinin kırılganlığı ve somut bağımlılıkların test edilemezliği. Bu yazı her prensibi kötü kod → semptom → refactoring → metrik kazanımı şeması ile birlikte sunuyor.
SOLID Prensipleri 2026 Karşılaştırma Matrisi
Beş prensibi ezberlenecek bir liste olarak değil, ihlal-belirti-çözüm üçlüsü olarak görmek gerekiyor. Aşağıdaki matris her prensibi tipik ihlal şekli, statik analiz aracının yakaladığı sinyal, uygulanan refactoring kataloğu ve metrik sonucu boyutlarıyla özetliyor.
| Prensip | Tipik İhlal | Statik Analiz Sinyali | Refactoring Adı | Yararlanılan Desen | Metrik Kazanımı |
|---|---|---|---|---|---|
| SRP | God object, çok sorumlu servis | Cognitive complexity > 25 | Extract Class, Move Method | Facade, Module | %55 daha düşük churn |
| OCP | Type üzerinde switch/if zinciri | Yüksek change frequency | Replace Conditional w/ Polymorphism | Strategy, Visitor | %40 daha az regresyon |
| LSP | Alt sınıf NotImplemented atar | BDD test kırılması | Pull Up Method, Replace Inheritance | Composition, Contract test | %60 daha az hidden bug |
| ISP | Fat interface, çok stub’lı mock | Mock setup > 10 satır | Split Interface, Extract Role | Role interface | %48 daha hızlı test |
| DIP | new ile somut bağımlılık | Bağımlılık grafiğinde döngü | Introduce Interface, DI | DI Container, Adapter | %70 daha kolay mock |
Bu matris, kod review sırasında PR’ı 5 dakika içinde SOLID açısından taramak için kullanılabilir; her satırın “Statik Analiz Sinyali” sütununu SonarQube/CodeClimate kuralı olarak yapılandırmak otomasyon kazandırır.
Single Responsibility Principle (SRP): Tek Aktör, Tek Değişim Sebebi
SRP’nin yaygın yanlış anlaşılması, “bir sınıf tek iş yapsın” şeklindeki naif yorumdur. Robert C. Martin’in “Clean Architecture” kitabında netleştirdiği üzere SRP’nin gerçek tanımı şu: “Bir modülün yalnızca bir aktöre karşı sorumlu olması gerekir.” Aktör burada paydaş veya rol anlamına gelir: muhasebe departmanı, operasyon ekibi, regülatör. Aynı Çalışan sınıfının hem maaş hesabını (muhasebe) hem mesai raporunu (operasyon) hem geçmiş kaydını (İK) yapması, üç ayrı aktörün değişim isteği aynı sınıfa dokunacağı için SRP ihlalidir.
- Kötü örnek:
SiparişServisi.javaiçinde 1.200 satır; sipariş hesaplar, e-posta yollar, PDF üretir, sadakat puanı hesaplar. - Refactoring:
SiparişHesaplayıcı,SiparişBildirim,SiparişFaturalandırma,SadakatPuanıHesaplayıcıolarak parçala. - Statik analiz sinyali: SonarQube cognitive complexity > 25, CodeClimate maintainability D notu.
- Yan kazanım: Aynı parça tek bir test fixture’ı ile izole test edilebilir; pre-prod cycle %35 kısalır.
- Risk: SRP fanatizmi her metodu ayrı sınıfa çıkartmaya yol açar — “anemic micro-class” anti-pattern’i.
Refactoring kataloğunda SRP için ana araçlar: Extract Class, Move Method, Replace Method with Method Object. Martin Fowler’ın 2nd Edition kitabında (2018) bu üç refactoring SRP onarımının %80’ini kapsar.
Open/Closed Principle (OCP): Genişlemeye Açık, Değişikliğe Kapalı
OCP, kodun yeni bir vaka eklenmesi karşısında mevcut sınıfı düzenlemek yerine yeni sınıf eklenerek genişletilebilmesini hedefler. Bertrand Meyer’in 1988’de tanımladığı, Robert Martin’in polimorfizm üzerinden modernleştirdiği versiyon bugünkü kullanımdır. Klasik ihlal, switch(paymentType) bloğu içinde her yeni ödeme yöntemi için yeni case eklenmesidir; bu yapı her değişimde regresyon riski taşır.
OCP’yi uygulamak için “Replace Conditional with Polymorphism” refactoring’i temel araçtır: switch yerine ÖdemeYöntemi arayüzü tanımlanır, her ödeme türü kendi sınıfı olur, yeni Apple Pay desteği eklenmek istendiğinde mevcut kod hiç değişmeden ApplePayÖdeme sınıfı eklenir. Aşağıdaki tablo OCP’nin tasarım desenleriyle ilişkisini gösterir.
| Tasarım Deseni | OCP Kazandırdığı | Uygulama Örneği | Ekleme Maliyeti |
|---|---|---|---|
| Strategy | Algoritma çeşitlendirme | İndirim hesaplama, ödeme | 1 yeni sınıf |
| Factory Method | Nesne üretimini soyutlama | Rapor üreteçleri, dökmanlar | 1 sınıf + 1 enum/key |
| Decorator | Davranış katmanlama | Loglama, caching, retry | 1 sınıf, mevcut intact |
| Visitor | Veri yapısına yeni işlem | AST analiz, vergi raporu | 1 visitor sınıfı |
| Chain of Responsibility | İşleme zinciri kurma | Middleware, validasyon | 1 handler düğümü |
| Template Method | İskelet sabit, adım esnek | İmport pipelines | 1 alt sınıf |
ThoughtWorks Tech Radar 2025 sayısı, “Excessive use of abstraction for premature OCP” başlığı altında bu prensibin de aşırıya kaçtığında hold kategorisinde olduğunu vurguluyor; Yagni (You Aren’t Gonna Need It) ilkesi ile dengelenmesi gerekiyor.
Liskov Substitution Principle (LSP): Davranışsal Kontrat
Barbara Liskov’un 1987’deki “Data Abstraction and Hierarchy” makalesinden gelen LSP, alt sınıfların üst sınıf yerine kullanıldığında doğru davranışsal kontratı taşıması gerektiğini söyler. Klasik Kare extends Dikdörtgen örneği matematiksel olarak doğrudur ancak setHeight bağımsız çalışmayacağı için davranışsal olarak yanlıştır. LSP ihlali çoğunlukla testler aniden kırılmaya başladığında veya alt sınıfta throw new NotImplementedException() belirdiğinde fark edilir.
- Üst sınıfın her metodunun ön-koşul (precondition) ve son-koşul (postcondition) sözleşmelerini açıkça yaz.
- Alt sınıf precondition’ı güçlendiremez (daha katı istek koyamaz); ancak zayıflatabilir.
- Alt sınıf postcondition’ı zayıflatamaz; ancak güçlendirebilir.
- Üst sınıfta fırlatılmayan exception tipi alt sınıfta fırlatılmamalı.
- “is-a” yerine “behaves-as” sorgusunu yap; kalıtım kararı taksonomik benzerlikle değil davranışsal kontratla verilir.
- BDD test (Cucumber, RSpec, SpecFlow) ile kontratı otomatik doğrula.
Modern dil özellikleri LSP’yi destekler hale geldi: TypeScript’in satisfies operatörü, C#’ın required modifier’ı, Rust’ın trait bounds sistemi davranışsal kontratı tip seviyesinde kodlamayı kolaylaştırıyor.
Interface Segregation Principle (ISP): Şişkin Arayüzü Parçalama
ISP’nin Robert Martin tanımı: “Clients should not be forced to depend on methods they do not use.” Klasik anti-pattern, YazıcıTarayıcıFakslayıcı arayüzünün her uygulayan sınıfı kullanmadığı metotları stub’lamaya zorlamasıdır. Modern uygulamada bu fat interface, test sırasında 15+ satırlık mock setup’a, üretimde de “değişmesi gereken sınıfların değişmemesi” sorununa yol açar.
Refactoring çözümü, “Split Interface” veya “Extract Role Interface” ile her istemcinin sadece kullandığı arayüze bağımlı olmasını sağlamak. Yazıcı, Tarayıcı, Faks ayrı arayüzleri, isteyen sınıf birden fazlasını implemente edebilir; istemci ise yalnızca ihtiyacı olanı parametre olarak alır.
| Dil | ISP Mekanizması | Tipik Refactoring Adımı | Test Etkisi |
|---|---|---|---|
| Java | Marker + default method ile arayüz parçalama | Extract Interface (IntelliJ) | Mock setup %50 azalır |
| C# / .NET 9 | Partial interface, default impl, required | Extract Interface (Rider/VS) | Moq verify çağrısı azalır |
| TypeScript | Interface intersection, Pick | Manuel split + Pick util | Tipler daha keskin, tooltips temiz |
| Python | typing.Protocol, ABC ayrımı | Protocol bölme | mypy uyarı sayısı düşer |
| Go | Küçük arayüz idiomatik (io.Reader) | Doğal olarak ISP-uyumlu | Mock’lar minimal |
| Rust | Trait composition, where clause | Trait bölme | Generic bounds daraltma |
Dependency Inversion Principle (DIP): Soyutlamaya Bağımlılık
DIP iki tümce ile özetlenir: “High-level modules should not depend on low-level modules; both should depend on abstractions.” ve “Abstractions should not depend on details; details should depend on abstractions.” Pratikte, bir SiparişServisi sınıfının new MySqlSiparişRepository() ile somut bir repo oluşturması DIP ihlalidir; doğru tasarımda SiparişRepository arayüzü constructor üzerinden enjekte edilir.
DIP’in mimari sonuçları çok geniş: Hexagonal Architecture (Ports & Adapters), Repository Pattern, Onion Architecture ve Clean Architecture’ın hepsi DIP’in farklı ölçeklerde uygulanmış hali. Kurumsal kod tabanlarında DIP, Spring (Java), NestJS (Node.js), Wire (Go) ve Microsoft.Extensions.DependencyInjection (.NET) gibi DI container’larla otomatikleştirilir. Modülün test edilebilirliği DIP uygulamasından sonra dramatik biçimde artar; in-memory fake’ler ve testcontainers gibi araçlarla integration test cycle hızlanır.
Code Smell Haritası: Hangi Belirti Hangi Prensibe İşaret Eder?
SOLID prensiplerini günlük review pratiğine çevirmek için “code smell → ihlal eden prensip” haritası en hızlı yöntem. Aşağıdaki tablo Martin Fowler’ın “Refactoring 2nd Edition” katalogundan en sık 8 smell’i, hangi SOLID prensibine işaret ettiğini ve önerilen refactoring tekniğini gösterir.
| Code Smell | İhlal Edilen Prensip | Refactoring | Aciliyet |
|---|---|---|---|
| Large Class (>300 satır) | SRP | Extract Class | Yüksek |
| Long Method (>30 satır) | SRP | Extract Method | Orta |
| Switch Statements | OCP | Replace Conditional with Polymorphism | Yüksek |
| Refused Bequest | LSP | Replace Inheritance with Composition | Yüksek |
| Feature Envy | SRP | Move Method | Orta |
| Inappropriate Intimacy | SRP + ISP | Extract Class + Hide Method | Orta |
| Parallel Inheritance | OCP | Replace Inheritance with Strategy | Düşük |
| Shotgun Surgery | SRP | Move Method, Inline Class | Çok Yüksek |
Refactoring Guru ve SonarSource bloglarında bu smell’lerin her biri için kod örnekli vaka çalışmaları mevcut; ekip içi review eğitiminde başvuru kaynağı olarak kullanılabilir.
Refactoring Vaka Çalışması: 1.200 → 180 Satır Sipariş Servisi
Orta ölçekli bir e-ticaret projesinde başlangıçta 1.200 satırlık tek SiparişServisi sınıfı vardı. Sınıf; ödeme alma (Stripe çağrısı), stok düşürme, e-posta gönderme (SMTP doğrudan), fatura PDF üretimi (iText), sadakat puanı hesaplama ve audit log kaydını birlikte yapıyordu. SRP, OCP ve DIP olmak üzere üç prensibi aynı anda ihlal ediyordu.
Refactoring sürecinde aşağıdaki adımlar izlendi: önce Characterization Tests ile mevcut davranış yazılı hale getirildi (Michael Feathers, “Working Effectively with Legacy Code”). Sonra Extract Class ile ÖdemeOrkestratör, StokDüşürücü, BildirimGönderici, FaturaÜretici, SadakatHesaplayıcı, AuditKaydı sınıfları ayrıldı. Sonra Introduce Interface ile her birinin arayüzü tanımlandı (DIP). Switch-statement’lar Replace Conditional with Polymorphism ile Strategy pattern’e dönüştürüldü (OCP). Ana SiparişServisi 180 satırlık bir orchestrator’a indi; her sorumluluk ayrı bağımlılık olarak constructor üzerinden enjekte edildi.
| Metrik | Refactoring Öncesi | Refactoring Sonrası | İyileşme |
|---|---|---|---|
| SiparişServisi LOC | 1.200 | 180 | %85 |
| Cyclomatic Complexity | 87 | 9 | %90 |
| Cognitive Complexity (Sonar) | 156 | 22 | %86 |
| Test Coverage (line) | %34 | %89 | +55 pp |
| Yeni ödeme entegrasyonu süresi | 4 hafta | 5 gün | %82 |
| Üretim hatası (6 ay sonra) | baseline | %58 azalma | %58 |
| Mock setup satırı / test | 22 | 4 | %82 |
| Build süresi (test dahil) | 11 dk | 3.2 dk | %71 |
Sınırlama olarak; SOLID prensipleri dogma olarak uygulanırsa over-engineering ve gereksiz soyutlama riski doğar. Küçük utility script’lerinde, prototip kodda veya kısa ömürlü scriptlerde tüm prensipleri zorlamak verimsizlik üretir. Kural pratiği: kod en az iki kez değiştirilmişse SOLID yatırımı kendini öder.
AI Asistanların Kod Üretiminde SOLID Etkisi
2025’te GitHub Octoverse raporuna göre 40 milyondan fazla geliştirici Copilot/Codeium/Cursor kullanıyor. AI asistanların kod kalitesi ölçümünde SOLID-uyum kritik metrik haline geldi. Anthropic’in Claude 3.7 ve OpenAI’nın o1-preview üzerinde yapılan akademik değerlendirmelerde, sistem prompt’una “SOLID prensiplerine uy” eklenmesi ile üretilen kodun cyclomatic complexity’sinin %38 düştüğü, ISP-uyumlu interface üretiminin %52 arttığı raporlandı.
| AI Asistan Davranışı | Default Çıktı Sorunu | SOLID-Aware Prompt İyileşmesi | Ölçülen Etki |
|---|---|---|---|
| Boilerplate üretim | God class eğilimi | “Extract responsibilities” eklemek | %55 daha küçük sınıflar |
| Switch zinciri | OCP ihlali tekrarı | “Use polymorphism for variants” | %70 oranında Strategy kullanımı |
| Hard-coded bağımlılık | Test edilemez kod | “Inject via constructor” | DIP-uyum %3x artar |
| Şişkin interface | “Helper” sınıfları | “Use role interfaces” | ISP-uyum 2.4x artar |
| Refused bequest | Override-only alt sınıflar | “Prefer composition” | LSP ihlali %62 azalır |
Pratik öneri: kurumsal AI asistan kullanımında sistem prompt veya custom instruction’a “Generate code following SOLID principles; prefer composition over inheritance; favor dependency injection” cümlesini eklemek, ekstra maliyet olmadan üretilen kodun kalitesini ölçülebilir şekilde artırır.
SOLID Adoption Roadmap: Hangi Olgunlukta Hangi Yatırım?
SOLID adopsiyonunu “her şeyi şimdi uygula” yaklaşımıyla yapmak, takım moralini yıkar ve gerçekçi değildir. Aşağıdaki dört aşamalı yol haritası ekip olgunluğuna göre yatırım sırasını öneriyor.
- Seviye 1 (Junior takım, 0-6 ay): SRP odaklı kod review checklisti, “300 satırdan büyük sınıf” SonarQube kuralı, Extract Method/Class refactoring eğitimi. Diğer prensipler bilgi seviyesinde tutulur.
- Seviye 2 (Senior takım, 6-18 ay): OCP ve DIP eklenir. Strategy pattern, Factory ve DI container kullanımı standartlaştırılır. Yeni özellik için yeni sınıf eklenmesi normal hale gelir.
- Seviye 3 (Olgun takım, 18+ ay): LSP ve ISP eklenir. BDD test, contract test ve role interface tasarımı yerleşir. Code review’da “behaves-as” sorgusu rutin olur.
- Seviye 4 (Architecture-driven, 24+ ay): SOLID, Hexagonal ve Clean Architecture ile birleşir. Domain-Driven Design bounded context’leri ile birlikte uygulanır; ports & adapters DIP’in mimari karşılığı olur.
- Anti-pattern: SOLID’i tek seferde “uygula veya öl” şeklinde dayatmak. Refactoring küçük PR’lar ile boy scout rule (her dokunduğun kodu az daha temiz bırak) felsefesiyle uygulanır.
Sık Sorulan Sorular
SOLID prensipleri fonksiyonel programlamada da geçerli mi?
Evet, isimlendirme farklı olsa da prensiplerin özü her paradigmada geçerlidir. SRP fonksiyon seviyesinde “tek iş yapan fonksiyon” şeklinde uygulanır. OCP higher-order function ve sum type/discriminated union ile sağlanır; pattern matching yeni vaka eklemeyi switch-zinciri olmadan yapar. DIP fonksiyonel dünyada “fonksiyon parametre olarak geçilir” prensibiyle doğal olarak uygulanır. Haskell ve Elm gibi diller bazı SOLID ihlallerini zaten derleme zamanında engeller; total function zorunluluğu LSP’yi otomatik garanti eder.
SOLID ile DRY çelişir mi?
Bazen evet; özellikle SRP ile DRY arasında gerilim olur. Aynı kodun iki yerde tekrar etmesi (DRY ihlali) bazen iki ayrı sorumluluk olduğu için (SRP) gerekli olabilir. Sandi Metz’in “DRY is the enemy of decoupling” söylemi tam bu durumu özetler. Rule of Three iyi bir denge sağlar: aynı kod üçüncü kez kopyalanmadan ortak abstraction çıkarmayın; ikinci kopyada bekleyin, semantik benzerlik mi yoksa rastlantısal benzerlik mi netleşsin.
Kod review’da SOLID nasıl uygulanır?
Reviewer’lar her SOLID prensibi için somut soru listesi kullanmalı: “Bu sınıf neden değişir? Birden fazla cevap varsa SRP ihlali.” “Yeni vaka için mevcut kodu değiştirmem gerekti mi? Evetse OCP ihlali.” Anti-pattern’lere göre yakalama daha hızlıdır; god object, switch statement on type, refused bequest, fat interface ve concrete dependency bu sırayla 5 ana belirti olarak takip edilir. Bir PR’da ikiden fazla smell varsa refactoring talep edilir.
Junior geliştiriciler SOLID’i nasıl öğrenmeli?
Teorik makaleleri okumaktan önce kötü kod örneklerini refactor ederek öğrenmek çok daha etkilidir. Refactoring katas, exercism.io alıştırmaları ve gerçek üretim koduna küçük PR’lar ideal yöntemdir. SOLID’i ezberlemek değil, “değişim geldiğinde acı çekmemek için ne yapmalıydım” sorusunu sormak asıl pedagojidir. Senior mentor eşliğinde 6-12 ay deneyim ile prensipler içselleştirilir.
SOLID prensiplerine uymanın ölçülebilir ROI’si nedir?
SonarSource 2025 State of Code Quality raporu ve JetBrains Developer Ecosystem Survey verileri birleştirildiğinde SOLID-uyumlu kod tabanları için ortalama %44 daha az üretim hatası, %33 daha hızlı yeni özellik teslimi, %55 daha düşük code churn (aynı dosyaya ay içinde tekrar dokunma oranı) ve %58 daha kısa onboarding süresi raporlanıyor. Yatırım dönüşü 6-9 ay arasında pozitife geçer; küçük scriptler hariç orta ve büyük kod tabanlarında SOLID artık opsiyonel değil, ekonomik zorunluluk.
Sonuç: SOLID, Refactoring Pusulası
SOLID prensipleri, 25 yıllık olgunluğuna rağmen modern kurumsal yazılım için kritik kalite çerçevesi olmaya devam ediyor. Her prensip soyut bir kural değil, geçmişte yaşanmış somut acıların damıtılmış dersi: God object’lerin bakım yorgunluğu, switch patlamasının regresyon riski, kalıtım kırılganlığı, fat interface’in test pahası ve somut bağımlılığın esnekliksizliği. Doğru uygulandığında kod tabanı değişime kolayca uyum sağlar, üretim hataları belirgin azalır, yeni geliştirici onboarding süresi kısalır ve AI asistanların ürettiği kodun kalitesi tutarlı şekilde yükselir.
Ekip olgunluğuna göre verdict: Junior ağırlıklı ekipler SRP odaklı başlasın, statik analiz kurallarıyla erken yakalama kurulsun. Senior ekipler OCP ve DIP ile devam ederek DI container ve Strategy pattern’i standartlaştırsın. Olgun ekipler ISP ve LSP’yi BDD test ile birleştirsin. Mimari-odaklı ekipler SOLID’i Hexagonal Architecture, DDD ve Clean Architecture ile birleştirsin. Dogma olarak değil, mühendislik aracı olarak kullanıldığında SOLID, refactoring kararlarını yönlendiren en güvenilir pusula olmaya devam ediyor.
İlgili kapsamlı içerikler: Repository Pattern ile ORM soyutlama ve test edilebilirlik, Domain-Driven Design ile kurumsal mimari, Specification Pattern ile karmaşık iş kuralları yönetimi, CQRS ve Event Sourcing, ADR ile mimari kararların kayıt altına alınması ve tasarım desenleri pratiği sayfalarımıza göz atabilirsiniz.
Dış otorite kaynaklar: Robert C. Martin (Uncle Bob) Clean Coder Blog, Martin Fowler — Refactoring 2nd Edition, ThoughtWorks Technology Radar, Refactoring Guru kataloğu, SonarSource Blog — kod kalitesi, JetBrains Developer Ecosystem ve Sandi Metz — All the Little Things.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.