Serhat Yılmaz

Front-End Developper & Cyclist

Solid Prensipleri Nedir?

Ocak 2nd, 2017 by

solid

 

Solid bağımlılık yönetim biçimidir , dünya çapında yazılımcılarca kabul edilmiş olan OOP standartıdır. Geliştirmiş olduğumuz uygulamalar sizce yeni özellik eklemeye ne kadar uygun veya yazdığımız kodlarda tekrarlanan kodlar var mı? Eğer cevabınız evet ise dünya üzerinde Solid prensipleri olarak kabul edilen bu 5 temel prensibi bilmemiz gerekiyor.

 

Single Responsibility Principle

Büyük bir projemiz olduğunu düşünelim , bu projemizde bir değişiklik yapmak gerekti. Ancak revizyon yapmamız gerektiğinde , ufacık bir değişiklik için bile bir sürü gereksiz kodun ne yaptığını incelememiz gerekebilir. Bu projeler çöp proje olarak nitelendirilmektedir.

Proje içerisinde ki methodlar o kadar iç içe geçmiştir ki bazen düzenleme yapmak mümkün olmayabilir veya çok uzun süremizi alabilir. Bu projede yazılmış olan bir methodu , class’ı alıp başka bir projede kullanmak mümkün olmayabilir. İşte bu sorunu ortadan kaldırmak için bu prensibe uymalısınız. Prensibe göre her bir method sadece tek bir işlem yapmalıdır , hatırlarsınız algoritmanın en başında da bize bu öğretilmektedir.

Aynı zamanda bu prensibe uyduğunuz takdirde yazmış olduğunuz bir kod başka bir yazılımcı tarafındanda oldukça kolay düzenlenip , geliştirilebilecektir.

 

Open/Closed Principle

Günümüzde yer alan her teknoloji gelişmeye açık olmalıdır , her ürün aslında basit bir versiyon ile çıkarak zaman içerisinde değişimlere uğrayarak günümüzdeki halini almıştır. Düşünün ki bir arabanız var ve arabanızın bir parçasını değiştirmek için tüm arabayı değiştirmeniz gerekiyor , bu durum OCP prensibinin bizim için ne kadar önemli olduğunu yeterince anlatıyor olsa gerek.

OCP’yi bir de yazılım projesinde düşünelim. Projemizde kullandığımız nesneler , tıpkı bir makinenin parçaları gibidir dolayısıyla bu nesnelerin işlevleri ve sayıları değişebilir. OCP nesnelerin geliştirmeye açık olup , sayfa içerisinde yazdığımız kodların geliştirilmeye kapalı olması anlamına gelmektedir.

 

Liskov’s Substitution Principle

Liskov’un yer değiştirme prensibine göre alt class’lardan oluşturulmuş olan nesneler üst sınıfların nesneleri ile yer değiştirildiğinde aynı davranışı göstermek zorundadırlar. Yani türeyen sınıflar türetildikleri sınıfların tüm özelliklerini kullanabiliyor olmalıdırlar.

 

Interface Segregation Principle

Bu prensibi ilk bakışta Single Resposibility Principle’ın interface üzerinde uygunlanması olarak düşünülebilir.

ISP’ye göre nesneler ihtiyaç duymadıkları metotların bulunduğu interfacelere bağlanmak zorunda kalmamalıdır. Yani örnek vermek gerekirse bir yazılımınız var aynı anda birden çok işlem yapıyor fakat kullanmadığımız bir işlem hakkında size gereksiz sorular soruyor , bunun olmasını ister miydiniz?

Örneğe bir mesajlaşma uygulamasıyla devam edelim. Varsayalım ki bir mesajlaşma uygulaması yazdık , görüntülü , sesli ve yazılı şekilde mesajlaşılabiliyor. Ancak bir mesaj her zaman görüntüye veya sese sahip olmak zorunda mıdır? Tabii ki hayır işte bu durumda tasarımımızı bölerek nesnelerin sadece gerekli zamanlarda gerekli methodllara ulaşabiliyor olmasını sağlamamız gerekir.

 

Dependency Inversion Principle
  • – Bu prensibe göre yüksek seviye modüller , düşük seviye modüllere bağlı olmamalı. Her ikiside abstract kavramlara bağlı olmalıdır.
  • – Aynı zamanda soyut kavramlar detaylara bağlı olmamalı , detaylar soyut kavramlara bağlı olmalıdır.

Öncelikle bu prensibin neden ortaya çıktığına bakalım. Günümüzde teknoloji oldukça hızlı gelişmekte ve yazılımlarımız değişime açık olmalıdır. Buna gündelik hayattan örnek vermek gerekirse ampulümüz patladı değiştirmemiz gerekiyor peki bir ampulü değiştirmek için bütün elektrik tesisatını değiştirmemiz gerekir mi?

Yazılım tarafından örnek vermek gerekirse XML olarak veri paylaşımı yapan bir servisimiz var. Şuan sorunsuz çalışıyor fakat günümüzde JSON diye yeni bir paylaşım formatı çıktı , veri paylaşımımızı JSON ile yapmak için bütün yazılımı tekrar yazmak pekte etik olmazdı. Bu sebeple yazılımımızın mimarisini oluştururken yüksek seviyede ki modüllerin ileride gelebilecek yenilikleri de düşünerek detaylara bağlamamamız gerekir.