Yazılım prensipleri neden önemlidir ? SOLID nedir?

Neden SOLID prensiblerini kullanmalıyım? Nedir bu SOLID prensibleri?

Bu yazımda SOLID prensibleri nedir, neden bu kadar önemli ve neden kullanmalıyız gibi bir çok sorunun cevabını bulmanızda yardımcı olmaya çalışacağım.

Haydi başlayalım 😊

Bir yazılım geliştiricisi, bir projeyi belli standartlara göre geliştirmelidir. Bir standartımız yoksa geliştirdiğimiz proje büyüdükçe, çok karmaşık bir yapı haline gelebilir. Bu karmaşık yapıya spagetti kod diyoruz. Spagetti denmesinin sebebi proje geliştirilirken hiç bir standartın olmamasından kaynaklı yapılan işin anlaşılabilirliğinin çok düşük, herhangi bir özellik eklemeye çalıştığımızda çok zorlaşması, bakım ve test edilebilirliğin önemli şekilde karmaşıklaşmasından kaynaklanıyor. Bu yüzden bir yazılım geliştirirken bir standartımız olmalıdır.

Örneğin bir tipe göre bir işlem yapıyoruz ve if-else-if yapısı kurduk, başlangıçta 10 adet tipimiz vardı ve biz gelen tipin hangi if bloguna ait olduğunu belirleyerek bir işlem yapmak istiyoruz. Peki bizim tip ihtiyacımız sürekli artsaydı, bu ifleri kullanarak yaptığımız yapı ne kadar doğru olurdu. Her seferinde yapıyı tekrar düzenlememiz gerekeceği gibi, bir tipten vazgeçtiğimizde de ona ait if blogunu kaldırmamız gerekebilirdi. Bu yüzden yapıları daha kontrol etmek için, daha anlaşılabilir ve esnek bir yapı sağlamak için SOLID prensiplerini kullanmamız gerekir.

Peki nedir bu SOLID?

SOLID bir yazılım prensibidir. Bu prensipler, geliştirilen yazılımın esnek olması, yeniden kullanılabilir olması, sürdürülebilir ve anlaşılabilir olmasını sağlayan, kod tekrarını büyük ölçüde önleyen bir yazılım prensibidir. SOLID’in her harfi bir kurala denk gelmektedir.Kısaca SOLID’in her harfi;

• S -> Single responsibility principle = Tek sorumluluk prensibi
• 0 -> Open-Closed principle = Açık-kapalı prensibi
• L -> Liskov substitution principle = Yerine geçme prensibi
• I -> Interface segregation principle = Arayüzlerin ayrımı prensibi
• D -> Dependency injection principle = Bağımlılığın ters çevirilmesi prensibi

Bu kurallar sayesinde kısaca aşağıdaki avantajları sağlar;

• Geliştirilen yazılımın gelecekte gelebilecek herhangi bir geliştirmeye kolayca adapte olabilmesi
• Eklenen yeni bir özellik, kodda bir değişikliğe gerek kalmadan kolayca eklenebilir olması
• Yeni gereksinimlerde, mevcut kodumuzda üzerinde az değişim olması
• Kod üzerinde sürekli düzeltme, hata yönetimi, yeniden yazma gibi sorunlara yol açtığı zaman kaybınıda minimuma indirmektedir.

Örneğin yukarıdaki problem için SOLID‘in o’ (Open-closed prensibi) harfi imdadımıza koşuyor ve yeni eklencek bir tipi mevcut yapıyı bozmadan eklememize olanak sağlıyor. Tabi bu yazıda size anlatmak istediğim ve SOLID’in en önemli prensiplerinden birisi olan, SOLID’in “s” harfi single responsibility yani tek sorumluluk prensibini anlatmaya çalışacağım.

Tek sorumluluk prensibi, bir sınıf yada bir method tanımlanırken sadece bir sorumluluğu olmasını sağlamamızı söyler. Peki neden tek bir sorumluluğa ihtiyacımız var ? Bir sınıf veya bir method ne kadar sorumluluk alırsa yazdığımız kod parçaları çok fazla değişime uğrayabilir, ihtiyaçlar çoğalabilir veya kod parçası gerektiğinden çok fazla büyüyebilir. Tek sorumluluk prensibi bize der ki, her kod parçasının tek bir sorumluluğu olmalıdır. Sorumluluğun azalması demek değişime daha kolay adapte olabileceği anlamına gelir.

Örneğin, yukardaki User sınıfını ele alalım, bu sınıfta bir kullanıcının belirli özellikleri mevcut. Burada dikkat edecek olursak, user sınıfımıza birden fazla role1, role2 gibi özellikler verilmiş. Peki User sınıfımızda kullanıcı rollerinin bu şekilde eklenmesi doğru mu? Bu tarz sorunları çözmek için tek sorumluluk ilkesini kullanmamız gerekir.

Yukarıdaki User sınıfına dikkat edicek olursak, artık eklenecek herhangi bir role, User sınıfımızı etkilemeden çalışmasına devam edecektir. Artık User sınıfımız tek sorumluk ilkesini karşılamaktadır.

Bir örnek olarakta bir method üstünden inceleyelim 😊

Elimizde yeni bir user oluşturulan bir method var. Yukarıdaki bu method ilk olarak, CreateUserRequest’ten gelen email ile kayıtlı bir kullanıcının var olup olmadığını kontrol ediyor. Eğer varsa bir exception atıyor, yoksa yeni bir user oluşturuyor. Yeni bir user oluştururken salary değerini hesaplamak için belli işlem yapıyor ve kullanıcıyı kaydediyor.

Peki sizce bu kod yapısı doğru mu? Bu methodumuz tek sorumluluk prensibini karşılıyor mu?

Burada methoda baktığımızda birden fazla sorumluluğu olduğunu rahatlıkla görebiliriz. Bir kullanıcının varlık kontrolünü yapıyor, bir salary için belli bir hesaplama kodu yazılıyor ve son olarak kullanıcıyı kayıt ediyor. Fakat bizim method ismine verdiğimiz sorumluluk sadece createUser yani sadece bu kod bir kullanıcıyı kayıt etmesi başka bir iş yapmaması gerekir.

Peki bunu nasıl düzenleyeceğiz ve tek sorumluluk prensibine uygun olarak tasarlayacağız gelin birlikte inceleyelim 😊

İlk olarak bir kullanıcının var olup olmadığı işlemi kontrol eden yapıyı ayrı bir method olarak yazmalıyız. Burada bu varlık kontrolu birden fazla yerde kullanılabilir. Örneğin bir kullanıcı silmek istediğimizde o kullanıcının var olup olmadığını kontrol etmemiz gerekir.

İkinci olarak böyle bir hesaplamayı createUser’dan ayırmamız gerekir. CreateUser sadece kullanıcıyı kaydetme işlemi yapmalı 😊 Belkide bu method’a bir yerde daha ihtiyaç duyulabilir. Burada bu method sayesinde başka yerlerde kullanılacak kod tekrarlarınıda önlemiş oluyoruz.

Son olarak bizim ana methodumuz bu hale geliyor, herhangi başla bir iş kodu yazılmadan kullanıcıyı kaydetme işlemi yapıyoruz. SOLID’i kullanmak bize en büyük faydası gördüğümüz gibi methodlarımızın anlamlı ve daha kısa kod parçasından oluşması, bu method’a ileride bir unit test yazmak istersek daha kolay bir şekilde yazabiliriz çünkü unit test’i kolaylaştırıcak en önemli kriter, kod parçasının anlamlı ve çok kısa tutulmasıdır.

Evet arkadaşlar bu yazımda kısaca size SOLID prensibinden ve SOLID’in “s” harfi tek sorumluluk prensibini anlatmaya çalıştım. Umarım keyifli bir okuma olmuştur. Başka yazılarda görüşmek dileğiyle sağlıcakla kalın 😊