Yazdığımız kod gelişime açık fakat değişime kapalı olmalıdır. Örneğin yazdığımız bir sınıf içerisindeki metodların gövdesi mümkün mertebe değişmemelidir.
Yine sınıf örneğinden devam edecek olursak; yeni bir özellik kolayca eklenebilmelidir. Mevcut kod yeniliklere açık, yani bloklayıcı durumda olmamalıdır. Yeni kod ekleyebilmek için mevcut kodda değişikliğe ihtiyaç duyulmamalıdır.
Değişime karşı çıkılmasının temel nedeni yapılan bu değişikliğin ilgili metodu kullanan yerlerde bozukluğa neden olabilme ihtimalidir (ki genellikle olurlar, sonradan fark edilen bozukluklar çok daha fazla can sıkar). Mevcut akışta soruna neden olan bu değişimler breaking change şeklinde ifade edilir.
Yeni bir şey eklemek için mevcut kodun değişmemesinden ne kastediliyor?
Örneğin önek ekleyen bir metodumuz olduğunu düşünelim. Bu metod’a string tipinde A86275 verdiğimizde bize TR-A86275 dönmesini bekleyelim. Şimdi bu metod input adında bir değişken ile A86275 bilgisini alır ve metod içerisinde sabit kodlanmış (hard coded) biçimde TR- eklersek (return “TR-” + input) gelecekte TR- ön ekinin değişmesi halinde bu metodun gövdesini güncellemek zorunda kalırız. Böyle bir gereksinimin oluşmaması için input değişkenine ek olarak prefix adında bir değişken daha alalım ve bunu dinamik hale getirerek gelecekteki olası değişimlerin çok daha az maliyet ve stabil şekilde gerçekleştirilebilmesini sağlamalıyız (return prefix + “-” + input).
Yani koda dökecek olursak mevcut kodun değişmesine neden olan (bu prensibin değişime kapalı olma kısmını ihlal eden) eden sınıfımız BadStringHelper iken, bu prensibin dikkate alınarak yazıldığı sınıfımız NiceStringHelper şeklinde olacaktır.
Yazdığınız kodların başka bir geliştirici arkadaşınıza yük olmadığı ve sizinde gelişime açık kodlarla bezenmiş projelerde çalıştığınız güzel günlerde karşılaşmak dileğiyle…