SOLID Prensipleri — Open-Closed Principle
SOLID prensiplerini açıkladığım yazı serisinin ikincisi olan “Open Closed Principle” kavramını açıklayacağım. Bir önceki yazımda Single Responsibility Principle kavramından bahsetmiştim. Olabildiğince basit ve anlaşılır şekilde bu prensibi anlatmak istiyorum.
Prensiplerin hepsinin ayrı bir önemi var ve bu prensipler doğrultusunda geliştirme yapmak bize gerçekten esneklik ve vakit kazandırıyor. Open-Closed kavramıda aynı şekilde geliştirme yaparken bize ileride oluşabilecek sorunlara karşı kompleks bir yapıdan arındırmayı hedefliyor. Bahsettiğimiz bu prensipte amaçlanan gelişime açık, değişime kapalı bir tasarımdır.
Geliştirdiğimiz yazılımda zamanla ve müşterinin ihtiyacına yönelik olarak güncellemeler, eklentiler veya modüller eklenebilir. Bununla beraber planlanan tasarımda değişikliklerden kaçınmak kaçınılmazdır. Peki bu değişiklikleri nasıl olurda yapıyı bozmadan, komple bütün olarak mimariyi bozmadan ekleyebiliriz. Open-Closed prensibi bu yüzden var. Yapılan bir değişikliğin bütün olarak bir yapıyı bozmadan güncelleyebilmek ve daha sonrasında tekrar değişikliğe uğradığında işleyişin bozulmamasını amaçlar. Her ne kadar ileriye dönük esnek (Extendability) bir tasarım oluşturursak, zamanla yapılacak güncellemeler ve yenilikler karşısında kompleks bir yapıyla karşılaşma olasılığımız düşük olur. Bunların yanında bu prensiplere uymak sadece bizim için değil, bizden sonra yazdığımız kod üzerinde geliştirme yapacak insanların işini kolaylaştırır.
Bu prensibin daha anlaşılabilir olması için bir kod örneği ile açıklamak istiyorum.
Burada bahsedilen senaryo müşterinin kart tipine yönelik bir indirimin yapılması üzerine oluşuyor. Burada her bir CardType classını ve methodunu abstract class olarak tanımlıyoruz. Çünkü burada indirim oranları kart tipine göre değişiklik gösteriyor. Bakınız StandartCard için %5'lik bir indirim uygulanırken, GoldCard için %15'lik bir indirim söz konusu. İndirim oranını CardType’ı miras olan belirler, biz kendimiz sürekli bunu değiştiremeyiz. Bu nedenle CardType classını abstract class olarak olarak tanımlıyoruz. Burada müşteriye ait dört farklı kart tipini CardType classından miras alacak şekilde tanımladık. Hepsinin kendine özel bir methodu var. İleriye dönük olarak bu yazdığımız kod örneğinde PremiumCard’a ait indirim oranı değişirse kompleks bir yapıyı değiştirmeye gerek kalmayacaktır.
Özet olarak geliştirdiğimiz bir yazılımın sürdürülebilir ve esnek bir yapıda olması, hem bizim için hem de bizden sonraki geliştiriciler için daha anlaşılabilir ve gelişime açık olmasını sağlamak önemlidir. Open-Closed prensibinin amacını tekrar hatırlatıcak olursak, gelişime açık, değişime kapalı tasarım yapmaktır.