SOLID bakım yapılabilir, esnek OOP sistemleri oluşturmak için beş tasarım prensibidir. Her biri katı, kırılgan kodun yaygın bir nedenini ele alır.
SOLID bakım yapılabilir, esnek OOP sistemleri oluşturmak için beş tasarım prensibidir. Her biri katı, kırılgan kodun yaygın bir nedenini ele alır.
| Harf | Prensip | Tek satır anlamı |
|---|
| S | Single Responsibility | Bir sınıfın değişmesi için tek bir nedeni olmalıdır |
| O | Open/Closed | Genişletme için açık, değişiklik için kapalı |
| L | Liskov Substitution | Alt tipler taban türün olduğu yerde kullanılabilir olmalıdır |
| I | Interface Segregation | Birçok küçük arayüz bir tane büyün arayüzden daha iyidir |
| D | Dependency Inversion | Somut sınıflar yerine soyutlamalara bağlı olun |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService özellikle e-postaya bağlı değildir — ona dokunmadan SMS veya test double ile değiştirin (D). Yeni bir bildirimci türü eklemek OrderService değişiklik gerektirmez (O).
SOLID rehberlik, kanun değildir. Aşırı uygulanması — sınıf başına bir arayüz, her yerde dolaylı — çözdüğü sorunu takip etmekten daha zor olan "soyutlama çorbası" üretir.
SOLID paylaşılan bir tanı dili sağlar: gözden geçirenler bir sınıfın neden değiştirilmesi zor olduğunu adlandırabilir ("bu SRP'yi ihlal ediyor") tat konusunda tartışmak yerine.
Hüküm ile uygulandığında, ilkeler dalga etkilerini azaltır — değişiklikler yerel kalır, yeni özellikler yeniden yazmak yerine genişlenir ve testler gerçek bağımlılıklar için sahte ortakları değiştirebilir.