Temiz Kod (Clean Code) Prensipleri – 2 : SOLID

Yazılım geliştirmenin temel prensiplerinden olan SOLID; geliştirilen yazılımın temiz, genişledikçe kompleksleşmeyen ve daha sürdürülebilir olmasını sağlayan prensiplerdir. Bu prensiplere dikkat edilerek yapılan geliştirmeler hem şirketi hem de yazılımcıyı yormayacak ayrıca projede geliştirme yapan yazılımcıyı da motive edecektir. Şirket için ise X bir geliştirmenin zaman maliyeti daha az olacaktır.

SOLID prensipleri, sıkı bağlantıyı (tight coupling) azaltmaya ve gevşek bağlantıyı(loose coupling) kullanmaya yardımcı olur.

  • Sıkı bağlantı, bir sınıfın veya modülün diğer sınıflara veya modüllere güçlü bir şekilde bağımlı olduğu durumları ifade eder. Bu durumda, bir değişiklik yapmak veya bir sınıfı değiştirmek diğer bağımlı sınıfları etkileyebilir ve büyük bir kod değişikliği gerektirebilir. Kodunuzda bundan kaçınmanız gerekir.
  • Gevşek bağlantı ise bir sınıfın veya modülün dışarıdan bağımlılıkları azaltıldığında veya soyutlanarak bağımsız hale getirildiğinde ortaya çıkar. Bu durumda, bir sınıfın veya modülün içinde yapılan değişiklikler diğer bağımlı bileşenlere çok az veya hiç etki etmez. Bu, kodunuzdaki değişiklikleri en aza indirir, kodun daha yeniden kullanılabilir, bakımı yapılabilir, esnek ve kararlı olmasına yardımcı olur.

Gelelim prensiplere;

S – Tek Sorumluluk Prensibi (Single Responsibility Principle)

Bir sınıfın yalnızca bir işlevi olmalı ve bir işe odaklanmalı. Birden fazla sorumluluğa sahip olmamalı. Örneğin UserService diye bir sınıfınız var ve burada CRUD işlemlerini yürütüyorsunuz. Aynı sınıf içerisine Product ile ilgili bir işlemin olmaması gerekir. Ayrıca X bir metodun birden fazla sorumluluğu olmamalı, herşeyi bir metoda yazmamalısınız.

O – Açık Kapalı Prensibi (Open-Closed Principle)

Bir sınıf veya fonksiyon, geliştirilebilir olmalı ancak değiştirilemez olmalıdır.

L – Liskov İlkesi (Liskov Substitution Principle)

Bu prensip, kalıtım aldığınız sınıf içerisindeki bir metodu ilgili sınıfınızda kullanmıyorsanız bunu ayrıştırmanızı ifade eder. Örneğin “Tavuk” diye bir sınıfınız var ve içinde “Uc” diye bir metot olan “Kuslar” sınıfından kalıtım aldınız. Tavuk uçamadığı için Kuslar sınıfı içerisindeki “Uc” metodunu kullanmayacaktır. Burada Liskov ilkesi bu özelliği ayrıştırmamızı öneriyor. Yani “Ucabilir” şeklinde bir sınıf oluşturup bunu da ayrıca inherit etmelisiniz.

I – Arayüz Ayrımı Prensibi (Interface Segregation Principle):

Bir sınıf, kullandığı arayüzlerde yalnızca ihtiyaç duyduğu metotları içermelidir. Yani, bir arayüz, onu kullanan sınıflar için gereksiz veya uygunsuz olmamalıdır.

D – Bağımlılıkların Tersine Çevrilmesi Prensibi (Dependency Inversion Principle):

Sınıflar arası bağımlılıklar olabildiğince az olmalıdır özellikle üst seviye sınıflar alt seviye sınıflara bağımlı olmamalıdır. Bu kural ile ilgili örnek bir uygulama yaptım buradan kontrol edebilirsiniz.

Kısaca SOLID e değinmiş olduk.
Başka bir yazıda görüşmek üzere.

Leave a Comment

Comments

No comments yet. Why don’t you start the discussion?

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir