Gerçek Dünya Örnekleriyle SOLID İlkeleri Rehberi

Yazılım geliştirmede, hem işlevsel hem de sürdürülebilir kod yazmak her zaman bir hedef. SOLID ilkeleri, bu hedefe ulaşmamız için bize yol gösteren bir dizi prensip sunuyor. Bu yazıda, her bir SOLID ilkesini yakından inceleyeceğiz ve gerçek dünya örnekleriyle, bu ilkelerin yazılım tasarım yaklaşımınızı nasıl dönüştürebileceğini keşfedeceğiz. Kendi projelerimden yola çıkarak, bu kavramları sizin için sade ve uygulanabilir bir şekilde açıklayacağım. Haydi, başlayalım!

1. Tek Sorumluluk İlkesi (SRP – Single Responsibility Principle)

Tek Sorumluluk İlkesi, bir sınıfın yalnızca tek bir değişim nedenine sahip olması gerektiğini vurgular. Yani, bir sınıfın tek bir amacı veya sorumluluğu olmalı. Bunu bir örnekle açıklayalım:

Bir e-ticaret uygulaması geliştirdiğinizi düşünün. Sipariş yönetimi, stok takibi ve e-posta bildirimlerini tek bir devasa SiparisYoneticisi sınıfında toplamak yerine, sorumlulukları ayırabilirsiniz:

• SiparisIsleyici: Sipariş işleme mantığını yönetir.
• StokYoneticisi: Stokla ilgili görevleri halleder.
• EpostaBildirimci: E-posta bildirimlerini gönderir.

Bir projemde, SRP’yi uygulayarak bir ödeme modülünü ayrı bir sınıfa böldüm. Bu, kodun bakımını kolaylaştırdı ve yeni özellik eklerken hata riskini azalttı. SRP sayesinde sınıflar modüler, anlaşılır ve genişletilebilir hale gelir.

2. Açık/Kapalı İlkesi (OCP – Open/Closed Principle)

Açık/Kapalı İlkesi, yazılım bileşenlerinin genişlemeye açık, ancak değişikliğe kapalı olması gerektiğini savunur. Bu, soyutlamalar ve arayüzler kullanarak değişimlere uyum sağlamayı teşvik eder. Bir örnekle bakalım:

Bir çizim uygulaması geliştiriyorsunuz ve çeşitli şekillerle çalışıyorsunuz. Her şekil için yöntemler içeren tek bir Sekil sınıfı yerine, bir soyut temel sınıf veya Sekil arayüzü oluşturup Daire ve Dikdortgen gibi sınıfları bundan türetebilirsiniz.

Yeni bir şekil eklemek istediğinizde, mevcut sınıfları değiştirmeden sadece yeni bir sınıf oluşturursunuz. Bir grafik uygulamasında bu yaklaşımı kullandığımda, yeni bir şekil eklemek yalnızca birkaç satır kodla mümkün oldu. OCP, mevcut işlevselliği bozmadan yenilik eklemeyi sağlar.

3. Liskov Yerine Geçme İlkesi (LSP – Liskov Substitution Principle)

Liskov Yerine Geçme İlkesi, bir üst sınıfın nesnelerinin, alt sınıf nesneleriyle değiştirilebilir olması gerektiğini belirtir; bu, programın doğruluğunu etkilememelidir. Klasik bir örnekle açıklayalım:

Bir geometri kütüphanesi geliştiriyorsunuz ve Dikdortgen sınıfı, genişlik ve yüksekliğe göre alan hesaplıyor. LSP’ye göre, bir Kare sınıfı Dikdortgen’den türemeli ve beklentileri bozmamalı. Ancak, bir karenin genişliğini değiştirirken yüksekliği de güncellemek gerekir, bu da karmaşıklığa yol açabilir.

Bu durum, LSP’nin önemini gösteriyor. Bir projemde, bu tür bir hiyerarşi sorun yarattığında, sınıfları yeniden düzenleyerek daha sağlam bir yapı kurdum. LSP, sınıf hiyerarşilerini dikkatlice tasarlamanın önemini hatırlatır.

4. Arayüz Ayrımı İlkesi (ISP – Interface Segregation Principle)

Arayüz Ayrımı İlkesi, büyük ve kapsamlı arayüzler yerine küçük, özel arayüzler oluşturmayı vurgular. Bir yazılım mimarisi örneğiyle inceleyelim:

Bir kütüphane sistemi geliştiriyorsunuz ve IYazici arayüzü, hem belgeleri hem de resimleri yazdırma yöntemlerini içeriyor. Ancak, her sınıfın her iki yönteme de ihtiyacı olmayabilir.

ISP’ye uygun olarak, IYazici arayüzünü IBelgeYazici ve IResimYazici arayüzlerine bölebilirsiniz. Böylece sınıflar, yalnızca ihtiyaç duydukları arayüzleri uygular. Bir yazdırma modülü geliştirirken bu yaklaşımı kullandım ve gereksiz bağımlılıkları ortadan kaldırarak kodumu daha temiz hale getirdim.

5. Bağımlılık Ters Çevirme İlkesi (DIP – Dependency Inversion Principle)

Bağımlılık Ters Çevirme İlkesi, yüksek seviyeli modüllerin düşük seviyeli modüllere bağlı olmaması, her ikisinin de soyutlamalara bağlı olması gerektiğini belirtir. Bir örnekle açıklayalım:

Bir günlük kaydı (logging) sistemi düşünün. Sınıflarınızda belirli bir günlük kaydı uygulamasını doğrudan kullanmak yerine, bir IGunluk arayüzü tanımlayın ve sınıflarınızı buna bağımlı yapın. Böylece, dosya tabanlı veya konsol tabanlı günlük kaydı arasında kolayca geçiş yapabilirsiniz.

Bir API projesinde, DIP’yi uygulayarak günlük kaydı sistemini değiştirdiğimde, üst düzey mantığı hiç değiştirmeden geçiş yaptım. DIP, esnek ve sürdürülebilir bir mimari oluşturmayı sağlıyor.

Sonuç

SOLID ilkeleri, daha iyi yazılım tasarımı için bir yol haritası sunar. Bu ilkeleri takip ederek kodunuzun sürdürülebilirliğini, yeniden kullanılabilirliğini ve genişletilebilirliğini artırabilirsiniz. Gerçek dünya örnekleri, SOLID ilkelerinin modüler, uyarlanabilir ve sağlam yazılım sistemleri oluşturmada nasıl fark yarattığını gösteriyor. Bir web uygulamasında bu ilkeleri uyguladığımda, kodumun ne kadar düzenli ve değişime açık hale geldiğini gördüm. Yazılım geliştirme yolculuğunuzda, SOLID ilkelerini rehber edin ve zaman testine dayanacak yazılımlar yaratın!

Siz SOLID ilkelerini hangi projelerde kullandınız? İlginç bir deneyim mi yaşadınız? Yorumlarda paylaşın, birlikte tartışalım! Daha fazla ipucu için bloguma göz atın veya benimle iletişime geçin!