SOLID Prensiplerini Anlamak: Temiz Kodun Temeli
Eğer sürdürülebilir, ölçeklenebilir ve sağlam yazılımlar yazmayı hedefleyen bir geliştiriciyseniz, muhtemelen SOLID terimiyle karşılaşmışsınızdır. Robert C. Martin (Uncle Bob) tarafından ortaya atılan bu beş prensip, iyi nesne yönelimli tasarımın bel kemiğini oluşturur. Bu makalede, her prensibi detaylandıracak, pratik örnekler verecek ve kodlama becerilerinizi geliştirmenize yardımcı olacak bazı az bilinen bilgiler paylaşacağız.
S — Tek Sorumluluk Prensibi (Single Responsibility Principle — SRP)
Tanım: Bir sınıfın değişmesi için yalnızca bir nedeni olmalıdır, yani yalnızca bir işi veya sorumluluğu olmalıdır.
Neden Önemlidir: SRP’ye uymak, kodunuzu anlamayı, test etmeyi ve bakımını kolaylaştırır. Her sınıf tek bir sorumluluğu yerine getirdiğinde, sistemin bir parçasındaki değişiklikler diğer ilgisiz parçalara etkisi en aza indirilir.
Örnek: Hem kullanıcı kimlik doğrulaması hem de log tutma işlemlerini yöneten bir sınıf düşünün. Bunları kimlik doğrulama ve loglama için iki ayrı sınıfa bölerseniz, log tutma mekanizmasındaki herhangi bir değişiklik kimlik doğrulama mantığını etkilemez.
İlginç Bilgi: SRP yalnızca sınıflar için değil, aynı zamanda fonksiyonlar, modüller ve mikro servisler için de geçerlidir. Farklı soyutlama seviyelerinde SRP uygulamak, genel sistem mimarisini önemli ölçüde iyileştirebilir.
O — Açık/Kapalı Prensibi (Open/Closed Principle — OCP)
Tanım: Yazılım varlıkları (sınıflar, modüller, fonksiyonlar vb.) genişletmeye açık olmalı, ancak değişikliğe kapalı olmalıdır.
Neden Önemlidir: OCP, yazılımınızı yeni işlevsellik eklenirken mevcut kodda minimum değişiklik yapacak şekilde tasarlamanızı teşvik eder. Bu, mevcut ve çalışan kodda hata riskini en aza indirir.
Örnek: Bir Shape sınıfınız ve bir calculateArea() metodunuz olduğunu varsayalım. Sınıfı yeni şekiller eklemek için değiştirmek yerine, Circle veya Rectangle gibi yeni alt sınıflar oluşturabilirsiniz.
İlginç Bilgi: OCP’yi ilk ortaya atan Bertrand Meyer, bu prensibi gerçekleştirmenin genellikle çok biçimlilik ve soyut sınıflar kullanmayı gerektirdiğini vurguladı. Ancak, Strateji veya Dekoratör gibi tasarım desenlerini stratejik olarak kullanmak da OCP’yi gerçekleştirmeye yardımcı olabilir.
L — Liskov Yerine Geçme Prensibi (Liskov Substitution Principle — LSP)
Tanım: Bir üst sınıfın nesneleri, alt sınıfın nesneleri ile değiştirilebilmelidir ve programın doğruluğu bozulmamalıdır.
Neden Önemlidir: LSP, bir alt sınıfın üst sınıfının yerine geçerek hataya neden olmadan veya beklenmedik davranışlara yol açmadan çalışabilmesini sağlar. Miras kullanımı, kodunuzun güvenilirliğini zedelemeyecek şekilde teşvik eder.
Örnek: Bir Bird sınıfınız ve bir Penguin alt sınıfınız varsa, Penguin'i Bird yerine koymak kodunuzu bozmayacaktır. Eğer Bird sınıfının bir fly() metodu varsa, Penguin bunu miras almamalıdır çünkü penguenler uçamaz.
İlginç Bilgi: LSP genellikle ince yollarla ihlal edilir. Yaygın bir tuzak, bir alt sınıfta metod davranışını değiştirmek, örneğin dönüş tipini veya metod imzasını değiştirmektir. Arayüzleri akıllıca kullanmak, bu tuzaklardan kaçınmanıza yardımcı olabilir.
I — Arayüz Ayrımı Prensibi (Interface Segregation Principle — ISP)
Tanım: Hiçbir istemci kullanmadığı yöntemlere bağımlı olmaya zorlanmamalıdır.
Neden Önemlidir: ISP, çok fazla iş yapan “şişkin” arayüzleri önler. Sınıfların yalnızca kendileriyle ilgili arayüzleri uygulamasını sağlar, bu da sistemi daha modüler ve yeniden düzenlemeyi kolaylaştırır.
Örnek: print(), scan() ve fax() yöntemlerine sahip bir Printer arayüzü düşünün. Basit bir yazıcının scan() ve fax() yöntemlerini uygulaması gerekmez. Bunun yerine, Printer, Scanner ve Fax gibi ayrı arayüzler oluşturun.
İlginç Bilgi: ISP, özellikle büyük kod tabanlarında birden çok sınıfın karmaşık arayüzlerle etkileşime girdiği durumlarda yararlıdır. Arayüzleri küçük ve odaklı tutarak, sınıflar arasındaki bağımlılığı azaltır, kod tabanınızı daha esnek ve gezinmesi daha kolay hale getirir.
D — Bağımlılıkların Ters Çevrilmesi Prensibi (Dependency Inversion Principle — DIP)
Tanım: Üst düzey modüller, alt düzey modüllere bağımlı olmamalıdır. Her ikisi de soyutlamalara bağımlı olmalıdır. Soyutlamalar ayrıntılara bağımlı olmamalıdır. Ayrıntılar soyutlamalara bağımlı olmalıdır.
Neden Önemlidir: DIP, yüksek seviyeli politika ile düşük seviyeli detayların ayrılmasını sağlayarak kodunuzu değişikliklere karşı daha dayanıklı hale getirir.
Örnek: Üst düzey bir OrderProcessor sınıfının düşük seviyeli bir MySQLDatabase sınıfına bağımlı olması yerine, bir DatabaseInterface arayüzüne bağımlı olmalıdır. Bu şekilde, temel veri tabanı uygulaması değiştirilebilir ve üst düzey mantık etkilenmez.
İlginç Bilgi: Bağımlılık Enjeksiyonu, DIP’yi uygulamak için yaygın olarak kullanılan bir tekniktir. Bağımlılıkları enjekte ederek, kontrolü tersine çevirebilir ve yüksek seviyeli modüllerin düşük seviyeli modül implementasyonlarından bağımsız olmasını sağlayabilirsiniz.
Sonuç
SOLID prensiplerini öğrenmek, temiz, sürdürülebilir ve ölçeklenebilir kod yazmayı hedefleyen her geliştirici için çok önemlidir. Bu prensipler, sadece daha iyi nesne yönelimli tasarım yapmanıza yardımcı olmakla kalmaz, aynı zamanda değişen gereksinimlere uyum sağlayabilen sağlam bir mimari oluşturmanıza da yardımcı olur. Unutmayın, SOLID sadece bir dizi kural değil, aynı zamanda bir zihniyettir. Bu prensipleri düşünerek uygulamak, yazılımınızın kalitesinde önemli bir fark yaratabilir.
SOLID prensiplerini anlayarak ve uygulayarak, sadece kod yazmıyorsunuz; iyi tasarlanmış yazılımların mirasını oluşturuyorsunuz. Pratik yapmaya devam edin, meraklı olun ve kodlamada başarılar!
Yazan/Oluşturan: Software Design Patterns Guide
