SOLID nedir?
Solid, popüler Amerikan Yazılım Mühendisi Robert C. Martin’in 2000 yılında Design Principles and Design Patterns adlı makalesinde tanıttığı beş tasarım ilkesinin anımsatıcı bir kısaltmasıdır. Bu ilkeleri takip etmek bize; Proje büyüdükçe sürdürülebilir, esnek, anlaşılır yazılımlar sağlar.
Not: Bu ilkeler Java, C#, Php gibi çeşitli programlama dilleri için geçerli olabilir; . Uygulanan ilkeleri göstermek için Java programlama dili ile pseudocode yöntemini izleyeceğim. Ben görsel hafızanın gücüne inanıyorum, bu yüzden draw.io’dan görseller oluşturarak açıklamaya çalıştım ve isterseniz bu görseleleri istediğiniz yerde kullanabilirsiniz.
1.Single Responsibility Prensibi
Aşağıdaki resme bakalım ve bazı sorular soralım, olur mu? Düşünün, bir proje var ve bu projeyi oluşturmak için Yazılım Geliştirici, Analist, Tasarımcı ve Testçi olarak tüm sorumluluğu alan biri var. Proje başarılı olsa bile proje anlaşılır ve sürdürülebilir mi? Diğer yandan tüm sorumlulukları olan arkadaşımız hastalanırsa ne olacak :)
Bir sınıfa birden fazla sorumluluk yüklememeliyiz ve sınıfı değiştirmek istediğimizde tek bir neden olmalıdır.
Bu prensibi, projemizin daha anlaşılır, yönetimi daha kolay, hataları çözmesi hızlı ve değişiklik yaptığımızda etkilenen alanları yönetmesi ve düzeltmesi kolay olması için takip etmeliyiz.
2.Open-Closed Prensibi
Projemizde yazılımcı olarak çalışan bir arkadaşı düşünelim, ondan avukat olmasını istemek mi, yoksa kendini geliştirmesini ve mesleki kalitesini yükseltmesini beklemek doğru olur mu?
Entitiler geliştirmeye açık ancak değişikliğe kapalı olmalıdır.
Bir sınıf veya fonksiyon, mevcut özellikleri korumalı ve değişikliklere izin vermemelidir. Yani davranışını değiştirmemeli, yeni özellikler kazanabilmelidir.
3.Liskov Substitution Prensibi
Normal bir motor kullanarak hızlanan bir araba üretecek bir yapımız var. Ve buradan yapılmış motoru olmayan bir elektrikli araba nasıl hızlanabilir?
Türetilmiş bir sınıf, türetildigi sınıf özelliklerini gösterebiliyor olmalıdır..
Türetilmiş sınıflar, türetildiği sınıfların tüm özelliklerini kullanmalıdır. Aksi takdirde gereksiz kodlar ortaya çıkacaktır.
4.Interface Segregation Prensibi
Diyelim ki sadece Java öğrenmek istiyorsunuz ve iki seçeneğiniz var. Sadece java derslerine katılmak mı daha mantıklı yoksa tüm C, Php ve Java derslerinin anlatıldığı paket bir kursa katılmak mı?
Daha büyük arayüzler daha küçüklere bölünmelidir
Sınıflarının yalnızca kendilerini ilgilendiren özelliklerleri barındırdıgından emin olun.
5.Dependency Inversion Prensibi
Diyelim ki bir projeniz var ve projenizde Yazılım geliştirici, testçi, analist ve tasarımcı var. Bir projeyi doğrudan şirket sahibi ile yönetmek mi daha kolay ve doğru yoksa teknik detaylara hakim bir yönetici ile yönetmek mi ?
Üst sınıflar doğrudan alt sınıflara bağlı olmamalıdır.
Sınıflar arası bağımlılıklar mümkün olduğunca az olmalı, özellikle üst düzey sınıflar alt düzey sınıflara bağımlı olmamalıdır..
Bu yazıda, SOLID ilkelerinin tarihçesi ile başladım ve daha sonra resimleri kullanarak her bir ilkenin nedenlerini ve nasıllarını net bir şekilde anlamaya çalıştım. SOLID ilkeleri, bir sonraki özelliğinizi veya uygulamanızı tasarlarken aklınızın bir köşesinde tutmanız gereken, araç kutunuzdaki değerli araçlardır. Yanlış bir bilgi yakalarsanız benimle paylaşın ve birlikte kendimizi geliştirelim.