Emeğe Saygı! Temiz Yaz, Kodun Kokmasın!

Çeşitli şirketlerde, farklı büyüklüklerde yapılar içinde yazılım geliştiriyoruz.  Evde tek başına yazılım geliştiriyor olsak dahi farketmemelidir. İşimize saygımız, işimizi iyi yapmayı gerektirir. 

İşimizi iyi yapacağız.  Kodumuz temiz olacak.  Kodun temiz olması nasıl olur demeyelim, temiz olmayan kod kokar ve kendini belli eder 🙂

Sınıf Tasarımı Prensipleri (Principles of Class Design)

Genelde Class ağaçlarından oluşan bir dil kullanıyoruz.  Class yapılarının basit ve tepkileri öngörülebilir olması için temel prensipler vardır. 

• Rigidity (Esnemezlik): Oluşturulan mimari tasarımın geliştirmeye ve yeni eklentilere (plug-in) açık olmamasıdır.
• Fragility (Kırılganlık): Projenin herhangi bir yerinde yapacağınız bir değişikliğin başka bir parçasında sorun çıkarabilmesidir.
• Immobility (Sabitlik): Geliştirilen parçaların/modülün tekrar kullanımına uygun olmamasıdır.

Genel olarak sınıflar arasında sıkı bağlantılara “tight coupling”  adı veriyoruz. Bu tür yapıları tercih etmiyoruz. Bizim istediğimiz sınıflar arası bağlantıların zayıf olması yani “loose coupling” durumudur. 

Object Oriented yazılım geliştirmede en sık kullanılan iyi tasarım yöntemlerinden birisi SOLID’ dir.  

SOLID kısaltması Robert C. Martin (Uncle Bob ) tarafından ortaya atılan bir dizi OOP  prensiplerinden beş tanesidir. ilk defa Michael Feathers tarafından ortaya atılmış bir kısaltmadır. Hem Bob Amca hem de Michael Feathers çağdaş OOP yaklaşımını oluşturan önemli kişilerdir. 

• Single Responsibility : Sınıflarımızın iyi tanımlanmış tek bir sorumluluğu olmalı.
• Open/Closed : Sınıflarımız değişikliğe kapalı ancak yeni davranışların eklenmesine açık olmalı.
• Liskov Substitution : Kodumuzda herhangi bir değişiklik yapmaya gerek kalmadan türetilmiş sınıfları (sub class) türedikleri ata sınıfın (base class) yerine kullanabilmeliyiz.
• Interface Segregation : Genel kullanım amaçlı tek bir kontrat yerine daha özelleşmiş birden çok kontrat oluşturmayı tercih etmeliyiz.
• Dependency Inversion : Katmanlı mimarilerde üst seviye modüller alt seviyedeki modüllere doğruda bağımlı olmamalıdır.

SOLID’ e ek olarak Kiss, Yangi, Dry, Reuse Release Equivalence, Common Closure prensipleri de bulunmaktadır.  Bu prensip ya da yöntemleri aynı şekilde Yazılımda Ustalaşmak başlığında kabul ediyorum.  

Java, C++, Python ya da C# gibi class sistemine dayanan bir Object Oriented dil kullandığımızı varsayıyorum.  Diğer yazılarda bu dillerden örnekler vermeye çalışacağım. 

Bu yöntem ve kalıpların amacının temiz kod yazmamız olduğunu bilelim.  İşimizi iyi yapacağız, temiz kod yazacağız ve kodumuz kokmayacak. 

1.Single Responsibility Principle

Her bir method sadece kendisine verilen işi yapar aynı anda birden fazla modeli etkilemez.  Böylece bir kod parçasında değişiklik yaptığımızda, değişikliğin sadece o paketi etkileyeceğini biliriz. 

2.Open/Closed Principle

Açık kapalı prensibi, yazılım geliştirirken kullandığımız varlıkların (class, method vs.) gelişime açık, kodların ise değişime kapalı olması ilkesidir.

3.Liskov ‘s Substitution Principle

Liskov’un yerine geçme prensibi alt sınıflardan oluşturulan nesnelerin üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorunda olduklarını söyler. Yani; türetilen sınıflar, türeyen sınıfların tüm özelliklerini kullanmak zorundadır. Eğer kullanmaz ise ortaya işlevsiz, dummy kodlar çıkacaktır. Bu durumda üst sınıfta if else blokları kullanarak tip kontrolü yapmamız gerekebilir ve böylelikle Açık Kapalı prensibine de ters düşmüş oluruz.

4.Interface Segregation Principle

Arayüz ayırım prensibi, bir arayüze gerektiğinden fazla yetenek eklemememiz gerektiği söyler.

5.Dependency Inversion Principle

Bağımlılığın ters çevirilmesi ilkesine göre üst seviye sınıflar, modüller, methodlar vs. alt seviyeli sınıflara bağımlı olmamalıdır. Alt sınıflarda yapılan değişiklikler üst sınıfları etkilememelidir.

Kiss Principle : Keep it Simple Stupid

Bir hedefe giden birden fazla yol vardır.  Acemilik hedefe giderken en karışık yolu kullanmaktır. 

 Kiss prensibine göre çözümlerimiz mümkün oldunca sade/anlaşılır olmalıdır. 

Yangi Principle : You Aren’t Gonna Need It!

Hedef giderken ihtiyacın yoksa, kodlara ek özellik ekleme. 

Dry Principle : Don’t Repeat Yourself

Proje içerisinde aynı kodu tekrar tekrar yazıyorsanız dry prensibine uymuyorsunuz demektir.  Proje içerisinde tekrarlaysan kod bloklarının azlığı iyi tasarım için bir metriktir. 

Reuse-Release Equivalence Principle

Projede kullanılan paketler/namespace’ ler arasındaki bağımlılıkları azaltmak “tekrar kullanılabilir” yapılar kurmakla mümkün olur.

Common Closure Principle

SOLID içerisindeki Single Responsibility’ nin namespace’ ler için uyarlanmış halidir. Aynı sebepten değişebilecek sınıflar aynı namespace altında bulunmalıdır.