SOLID: Nesneye yönelik tasarım ilkeleri
SOLID, beş temel tasarım ilkesini temsil eden bir kısaltmadır: Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion. Beş ilke de yaygın olarak kullanılır ve geliştiriciler için önemli faydalar sağlar.
SOLID ilkeleri, Robert C. Martin tarafından 2000 yılında yayınlanan “Design Principles and Design Patterns” makalesinde geliştirilmiştir, ancak kısaltma Michael Feathers tarafından yapılmıştır. Martin yazısında başarılı bir yazılım ürününün değişen ve gelişen olduğunu belirtmiştir. Ancak değiştikçe karmaşıklaşan yazılım ürünü kabul gören bir durum değildir.
SOLID ilkelerinin genel amacı, mühendislerin yazılımın bir alanını diğerlerini etkilemeden değiştirmelerini sağlamak için bağımlılıkları azaltmaktır. Buna ek olarak tasarımların anlaşılmasını, sürdürülmesini ve genişletilebilmesini kolaylaştırmayı amaçlar. Sonuçta bu tasarım ilkelerini kullanmak, yazılım mühendislerinin sorunlardan kaçabilmesini ve uyarlanabilir, etkili ve çevik yazılımlar oluşturabilmesini kolaylaştırır.
SOLID ilkeleri birçok avantaja sahipken daha uzun ve daha karmaşık kod yazımına sebebiyet verebilmektedir. Bu, tasarım sürecini uzatabileceği ve geliştirmeyi biraz daha zorlaştırabileceği anlamına gelir. Buna rağmen yazılımın bakımını, test edilmesini ve genişletilmesini çok daha kolay hale getirmektedir. Okunabilirlik, sürdürülebilirlik, tasarım kalıpları ve test edilebilirlik için daha iyi kod üretimini destekler.
Single responsibility principle (Tek sorumluluk ilkesi)
Robert Martin "bir sınıfın değişmek için bir ve sadece bir nedeni olmalıdır" diyerek bu ilkeyi çok iyi özetlemektedir. Bu ilkeye uymak, her sınıfın yalnızca bir şey yapması ve her sınıfın veya modülün işlevselliğinin yalnızca bir bölümünden sorumlu olması anlamına gelir. Başka bir deyişle, her yazılım bileşeninin tek bir sorumluluğu olmalıdır.
Tek sorumluluk ilkesi, çoğu geliştiricinin kod oluşturmak için halihazırda kullandığı nispeten temel bir ilkedir. Sınıflara, yazılım bileşenlerine ve mikro servislere uygulanabilir. Bu ilkenin kullanılması kodun test edilmesi ve bakımını, yazılımın ise uygulanmasını kolaylaştırır ve gelecekteki değişikliklerin beklenmeyen yan etkilerinden kaçınmaya yardımcı olur.
Geliştirme aşamasında bu ilkenin uygulandığından emin olmak için sınıfların kapsamını (scope) sınırlamak üzere derlemede otomatik bir denetim kullanmak göz önünde bulundurulabilir. Bu kontrol, single responsibility ilkesinin ıuygulanmasından emin olmanın kusursuz bir yolu olmasa da sınıfların bu ilkeyi ihlal etmediğinden emin olmanın iyi bir yolu olabilir.
Görsel 1
Görsel 1’de görülebilen Ogrenci isimli sınıf single responsibility ilkesini ihlal etmektedir. Bunun nedeni öğrencinin kaydı, sonuçlarının hesaplanması ve email gönderilmesi tek bir sınıfın sorumluluğunda olmasıdır. Yukarıdaki kod hatasız çalışsa da bazı zorluklara sebep olur. Bu kodu diğer sınıflar veya nesneler için yeniden kullanılabilir hale getiremeyiz. Ogrenci sınıfında, hataları düzeltmekle zorlanacağımız birbirine bağlı birçok kod parçası bulunmaktadır. Kod tabanı büyüdükçe mantık da büyür ve anlaşılması zorlaşır.
Open-closed principle (Açık-kapalı ilkesi)
Open-closed ilkesinde, sınıfları değiştirmek sorunlara veya hatalara yol açabilir. Sınıfı değiştirmek yerine genişletmek amaçlanır. Bu prensibi uygulamak, revize edilmesi ve bakımı kolay bir kod yazmak için esastır.
Open-closed prensibini, sınıfımız;
- genişletilmeye açık (sınıfın davranışının değiştirilebilirliği),
- değişikliğe kapalı (kaynak kodu ayarlanmış değiştirilemez) olduğunda
özelliklerine sahip olduğunda uygulamalıyız.
Kodu değiştirmeden kolayca genişletilebilir olmasını sağlamanın yolu, soyutlamanın (abstraction) kullanılmasıdır. Kullanılan yöntem ne olursa olsun, bakımı yapılabilir ve revize edilebilir kod yazmak için bu ilkeyi kullanmak önemlidir.
Liskov substitution principle
Beş SOLID ilkesinden Liskov Substitution ilkesi belki de anlaşılması en zor olanıdır. Genel olarak bu ilke, her türetilmiş sınıfın kendi ana sınıfının yerine geçmesini gerektirir. İlke, 1987'de bu kavramı tanıtan Barbara Liskov'un adını almıştır.
İçselleştirilmesi zor bir ilke olsa da, türetilmiş sınıfların davranışı değiştirmeden temel sınıfı genişletmesini sağlamanın bir yolu olduğundan, birçok yönden açık-kapalı ilkesinin bir uzantısıdır.
Bu ilkeye uyulması, değişikliklerin beklenmedik sonuçlarından kaçınmaya yardımcı olur ve değişiklik yapmak için kapalı bir sınıf açma zorunluluğunu ortadan kaldırır. Yazılımın kolay genişletilmesine ve geliştirme sürecini yavaşlamasına yol açarken, geliştirme sırasında bu ilkeyi takip etmek güncellemeler ve uzantılar sırasında birçok sorunu önleyebilir.
Interface segregation principle (Arayüz ayrıştırma ilkesi)
Arayüz ayrımı ilkesinin genel fikri, küçük arayüzlere sahip olmanın birkaç büyük arayüze sahip olmaktan daha iyi olduğudur.
Daha küçük arayüzler, geliştiricilerin kalıtım (inheritance) yerine kompozisyonu (composition) ve birleştirme (coupling) yerine ayrıştırmayı (decoupling) tercih etmeleri gerektiği anlamına gelir. Bu ilkeye göre geliştiriciler büyük, genel amaçlı bir arayüze sahip olmaya değil, müşteriye özel birçok arayüze sahip olmak için çalışır.
Dependency inversion principle (Bağımlılıkların tersine çevrilmesi ilkesi)
Bu ilkenin genel fikri basit olduğu kadar önemlidir: Üst düzey modüller, kolayca yeniden kullanılabilir olmalı ve yardımcı özellikler sağlayan düşük seviyeli modüllerdeki değişikliklerden etkilenmemelidir. Bunu sağlamak için, yüksek seviyeli ve düşük seviyeli modülleri birbirinden ayıran bir soyutlama (abstraction) tanıtmak gerekir.
Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara dayanmalıdır. Soyutlamalar ayrıntılara bağlı olmamalıdır. Detaylar soyutlamalara bağlı olmalıdır. Bu tanımın önemli bir detayı, yüksek seviyeli ve düşük seviyeli modüllerin soyutlamaya bağlı olmasıdır.
Tasarım ilkesi, adını ilk kez okuduğunuzda beklediğiniz gibi yalnızca bağımlılığın yönünü değiştirmez. Aralarına bir soyutlama getirerek yüksek seviyeli ve düşük seviyeli modüller arasındaki bağımlılığı böler.
Özetle;
Geliştirme sırasında SOLID tasarım ilkelerini uygulamak daha sürdürülebilir, ölçeklenebilir, test edilebilir ve yeniden kullanılabilir sistemlere sahip olunmasını sağlar. Sonuç olarak iyi kod oluşturmak ve endüstri standartlarını karşılarken rekabetçi tasarım ilkelerini kullanmak için bu ilkeleri kullanmak esastır. Bu ilkeleri uygularken ilk başta bunaltıcı gelebilse de ilkelerle düzenli olarak çalışmak ve ilkelere uygun olan kod ile uygun olmayan kod arasındaki farkları anlamak iyi tasarım süreçlerini daha kolay ve daha verimli hale getirmeye yardımcı olacaktır.
