SOLID Prensipleri: Nesne Yönelimli Programlamanın Beş Altın Kuralı

"Kod yazmak kolay, iyi kod yazmak zor"

OOP herkes öğrenir ama iyi OOP ayrı bir disiplin. 2000'lerin başında Robert C. Martin ("Uncle Bob") beş prensibi bir araya getirdi:

S - Single Responsibility
O - Open-Closed
L - Liskov Substitution
I - Interface Segregation
D - Dependency Inversion

= SOLID.

Modern OOP eğitiminin vazgeçilmez köşe taşları.

S — Single Responsibility Principle

"Bir sınıfın değişme nedeni tek olmalı."

Yani: bir sınıf tek bir işten sorumlu olmalı.

Kötü:

class Kullanici:
    def kaydet_db(self): ...
    def gonder_email(self): ...
    def loglog(self): ...

Üç farklı sebepten değişir.

İyi: ayrı sınıflar — Kullanici, KullaniciRepo, EmailServis, Logger.

O — Open-Closed Principle

"Genişlemeye açık, değişime kapalı."

Yeni özellik eklerken mevcut kodu değiştirme, yeni kod ekle.

Bertrand Meyer'in 1988 fikri.

Polimorfizm + soyut sınıflar bunu sağlar.

Kötü: if shape.type == 'kare', elif 'daire'...

İyi: Shape soyut sınıfı, alt sınıflar area() metodunu override eder.

L — Liskov Substitution Principle

Önceki yazıda detaylı.

"Alt sınıf üst sınıf yerine kullanılabilmeli."

Klasik ihlal örneği: Kuş → Pinguen. Kuş'un uc() metodu var, Pinguen uçamaz. LSP ihlali.

Çözüm: UcanKus ve UcmayanKus ayrı sınıflar.

I — Interface Segregation Principle

"İstemci kullanmayacağı arayüzlere bağımlı olmamalı."

Büyük arayüz → küçük parçalara böl.

Kötü:

class Worker:
    def cali(self): ...
    def ye(self): ...

Robot için ye() anlamsız.

İyi: Calisan ve Yiyen ayrı arayüzler.

D — Dependency Inversion Principle

"Yüksek seviye modüller düşük seviye modüllere bağımlı olmamalı. Her ikisi de soyutlamalara bağımlı olmalı."

Kötü:

class SaymaServisi:
    def __init__(self):
        self.db = PostgresDB()  # somut bağımlılık

PostgreSQL'i değiştirmek felaket.

İyi:

class SaymaServisi:
    def __init__(self, db: Veritabani):  # soyut bağımlılık
        self.db = db

Dependency Injection ile uygulanır.

Modern bağlam

Functional programlama

SOLID OOP'ye özgü. Functional programmingde benzer prensipler:

• Saf fonksiyonlar (S).
• Currying / composition (O).
• Type classes (L).
• Modüler tipler (I).
• Higher-order functions (D).

Microservices

SOLID sistem seviyesinde:

• Her servis tek sorumluluk.
• Olay tabanlı genişleme.
• API sözleşmesi.
• Küçük servisler.
• Servis discovery.

Modern AI mühendisliği

LLM agent mimarileri SOLID ihlal eder genelde. Çözüm: modular AI.

Faydaları

• Bakım kolaylığı: tek yer değişir.
• Test edilebilirlik: mock'lama kolay.
• Tekrar kullanım: parçalar bağımsız.
• Yeni özellik: mevcut kodu kırma.
• Takım çalışması: net sınırlar.

Aşırıya kaçma

Kötü uygulama: her sınıfa 5 prensip zorla yamamak → gereksiz karmaşıklık.

"Premature abstraction is the root of all evil." — Kent Beck.

Kural: prensiplere ihtiyaç duyana kadar uygulamayı erteleyin.

Tarihsel önem

• 1988: Bertrand Meyer Open-Closed.
• 1987: Liskov LSP.
• 2000'ler: Robert C. Martin SOLID acronyminı popülerleştirdi.
• "Clean Code" (2008) kitabı.

Türkçe yazılım dünyasında

• Bilkent, ODTÜ, İTÜ yazılım derslerinde mecburi konu.
• Yazılım Mimarisi sertifikalarında temel.
• Türk yazılım şirketlerinin code review pratiklerinde standart.

Uncle Bob tartışması

Robert C. Martin sürekli eleştirildi:

• "Aşırı normatif."
• "Modern paradigmaları (functional, async) ihmal ediyor."
• Politik açıklamaları nedeniyle bazı topluluklardan dışlandı.

Yine de SOLID prensipleri kendi başına ayakta.

Felsefe

SOLID temel mesajı: "Değişim kaçınılmaz, ona hazır ol".

Yazılım yaşar, evrilir. İyi tasarım gelecekteki değişimi kolay kılar.

Kapanış

SOLID, OOP'nin kuralsız tarafını disiplinli hale getirdi. Mükemmel değil — her durumda uygulanmaz — ama iyi başlangıç.

Bir yazılım mühendisinin olgunluk işareti: SOLID'i nerede uygulayacağını ve nerede uygulamayacağını bilmek.