Yazılımcılar olarak bir iş mantığını daha hızlı ve kolay geliştirmek için çoğu zaman soyutlamalar (abstractions) kullanırız. Sık ve farklı istemciler tarafından kullanılan bir iş mantığını soyutlayıp istemcilerin işini kolaylaştırmaya çalışırız. Dar boğazımız “zaman kısıtı” ise soyutlama kullanmak çoğu zaman işe yarar ama dezavantajları da beraberinde gelir. Joel Spolsky “The Law Of Leaky Abstractions” başlıklı makalesinde TCP protokolü üzerinden örnek vererek her soyutlamanın mutlaka bir seviye sızdıracağından bahseder. Sızdırmaktan kasıt ise alttaki bir protokolün üzerine soyut bir protokol geliştirildiğinde, hala alttaki protokolle ilgilenme ihtiyacı duymamızdır. Soyutlamadaki alt katmana sızdıran delik ne kadar büyükse karmaşıklık o kadar artar ve işimizi kolaylaştırsın diye seçtiğimiz mantık ayağımıza dolanır. Ne soyutun avantajlarını yeteri kadar kullanabiliriz ne de onu çöpe atıp direk bir alt katmanı kullanabiliriz. Bunu ben en çok tam iki kat arasında kalmış bir asansöre benzetiyorum. Ne tırmanıp üst kattan çıkabilirsiniz ne de eğilip alt kattan. Sıkışıp kalırsınız.

Bu konuyu gündeme getirmemin sebebi yukarıda bahsettiğim gibi her gün bununla çok sık karşılaşmam. Örneğin Redis gibi bir bellek/veri tabanı kullanıyorsanız Redis’in komut satırından çalıştırabildiğiniz onlarca komut bulunuyor. Bu komutların ne iş yaptığını Redis’in kendi dokümantasyonundan net bir şekilde biliyorsunuz. Java programlama dili kullanıyorsanız Redis’e genellikle Jedis isimli istemci kütüphanesi aracılığıyla erişiyorsunuz. Burada bir seviye soyutlama bulunuyor zira Redis komutlarının küçük bir kısmını Jedis ile kullanamıyorsunuz. Bir de Jedis’in üzerine spring-data-redis gibi bir kütüphane daha kullanıyorsanız Redis komutlarının üzerine iki kat çıkmışsınız demektir. Operasyonlarda işiniz kolaylaştı fakat Redis’ten de iki kat uzaklaştınız. Varsayalım ki kullandığınız kütüphanelerden bir tanesi bir NullPointerException fırlatıyor. Buradan itibaren artık tamamen “Leaky Abstraction” kavramıyla karşı karşıyasınız demektir ve sorunun çözümü için ters mühendisliğe ihtiyaç duyacaksınız. Kat kat çıktığınız soyutlamaların sızdıran deliklerinden birer birer alt katlara ineceksiniz.

Örneğin spring-data-redis’in RedisOperations.java sınıfını açıyorsunuz ve şu şekilde bir kod dokümantasyonu göze çarpıyor:

“ Returns the operations performed on simple values (or Strings in Redis terminology) bound to the given key.”

Meali: Redis’teki basit operasyonları döner. Biz buna boundValueOps dedik ama bu aslında Redis terminolojisine göre String operasyonlarına karşılık geliyor.

Sızdıran delikten bir alt kata indiniz ve oradaki bir terimin aslında Redis’teki String operasyonları yaptığını öğrendiniz ve problemin karmaşıklığına göre en alt kata kadar inebilirsiniz.

Sonuç olarak biz yazılımcılar sürekli soyutlamaların sızdıran deliklerinden girip çıkıyoruz ve bu konuyu henüz çözebilmiş değiliz. Programlama tarihi de düşük seviyeden başlayıp en yüksek seviye programlama dillerine evrildi (Nesne yönelimli, belleği kendi yöneten diller). Hatta sürükle-bırak yaparak program yazılabileceğini iddia edenler dahi oldu. Bir takım donanım kısıtlarına gelindiğinde ise tekrar düşük seviye diller popüler olmaya başladı (Paralel programlama, Fonksiyonel programlama..vs.). Karşılaştığımız problemlere ve dar boğazlara göre ömrümüz kat kat soyutlamalar arasında inip çıkmakla geçecek gibi görünüyor. 🙂

Yazıya medium’dan da erişebilirsiniz: https://medium.com/@yyenigun/soyutlamalar-478437b70144