immutable

• ing. asla değişmeyen, sabit.
• smashing pumpkinsin machines of god albumundeki stand inside your love sarkısında gecen kelime.
  -you and me meant to be immutable, impossible..
• javada, degeri degi$tirilemeyen nesneler icin kullanilan niteleme. wrapper nesneleri ya da string nesneleri, ornek olarak verilebilir.
  
  ornek:
  string x = "obafemi";
  x.concat(" martins");
  system.out.println("x = " + x);
  
  yukaridaki kodun ciktisi; x = obafemi olur. cunku string nesneleri, tanim geregi, immutabledir, degerleri degi$tirilemez, bu durumda ikinci satirda cagrilan concatenation method'u, x'in mevcut degerini degi$tirmez, sadece yeni bir string nesnesinin yaratilmasina sebep olur, ama yaratilan bu nesne, herhangi bir referans degi$kenine atanmadigi icin, memory'de eri$ilemez bir $ekilde durmaya mahkumdur.
  
  ote yandan, immutable taniminin biraz kafa kari$tiran bir yani daha vardir: immutable bir nesnenin atandigi referans degi$keni immutable degildir.
  
  yukaridaki string orneginden devam edersek:
  string x = "obafemi";
  x = x.concat(" martins");
  system.out.println("x = " + x);
  
  bu kez cikti; x = obafemi martins olur. cunku x'e atanan string degerinin pe$ine yeni bir string daha yapi$tirilmi$tir ve bu yeni string de, referans degi$kenleri immutable olamayacagi icin, tekrar x'e atanabilmi$tir.
• yazilim tasariminda onemli bir kavramdir immutable types.
  
  genis bir codebase uzerinde calisiyorsaniz, immutable tiplerin faydasini anlamayanlarin saldirilarina mutemadiyen maruz kalabilirsiniz.
  
  konusma icerisinde kullanalim:
  
  tangut: ben o nesnenin sadece o degerini degistirmek istiyorum degistiremiyorum ne bicim kutuphane yaziyorsunuz!
  kuzu: degistiremiyorsan degistirmemen gerekiyordur minik bizon.
  
  fonksiyonel programlama dillerinde (haskell, lisp) tum veri tipleri dogasi itibariyle zaten immutable'dir.
• objective-c code yazarken kullanilan nsarray'in de yarrattigi array object'i immutable'dir. icinde hole olmasina izin vermez. bu array'e inject edilen butun item'lar olmalari zorunlu oldugu icin ordadir. ilginc dil bu objective-c
• (bkz: immutability)
• (bkz: immutable.js)
• kisacasi:
  setter kullanmayin kardesim. bir sinifa degerler atarken sadece constructorlar tarafindan yapin.
• yazılım mühendisliğinde bir değerin değiştirilemez olması demektir. peki böyle bir değere neden gerek vardır ? ilk planda verinin korunması amacıyla böyle bir şeye ihtiyaç varmış gibi duruyor ama aslında bunun çok önemli bir mimari karşılığı var ve büyük bir uygulama geliştiriyorsanız “immutable” kavramı ile içli dişli olmanız çok olası. ayrıca fonksiyonel programlamanın ne demek olduğunu kavramak ve object oriented programlamadan farkını daha iyi idrak etmek için en önemli konu budur.
  
  bu kavram ile aslında farkında olmadan birçok yerde karşılaşıyoruz. ben daha iyi anlaşılması için soyut yazılım mühendisliği yerine daha somut olan otomotiv sanayisi üzerinden ifade edeyim durumu.
  
  bir tane araba firması düşününün, ürettiği arabaları belli standartlara göre üretiyor ve aracı satılması için dağıtım ağına gönderiyor. örneğin alman bmw firmasının ürettiği aracı, türkiye'de ana firmadan farklı borusan firması ithal ediyor ve türkiye’deki aracın satışı, bakimi gibi islerle bu yerel firma ilgileniyor. sonra bu yerel ithalatçı firma da bu aracı türkiye’nin birçok yerinde farklı araba showroomlarina, galerilere satıyor. bu satılan arabalar almanya’dan nasıl çıktıysa büyük oranda müşterinin eline kadar değişmeden geliyor.
  
  peki durum farklı olsaydı nasıl olurdu? araçlar almanya’dan çıktıktan sonra örneğin ithalatçı firma araçların lastiklerini kendi anlaşmalı olduğu firmanın lastikleri ile değiştirse, lokal satış galerileri aracı büyük oranda değiştirip öyle satışa sunarsa son kullanıcının elindeki araç ilk üreten firmanın ürününden büyük oranda farklı olurdu. üreticiden çıkan araç üretim ağının herhangi bir noktasında bir önceki veya bir sonraki halinden çok çok farklı özelliklere ama en önemlisi farklı problemlere sahip olurdu. bu da bu problemleri analiz etmeyi ve problemlerin çözümünü zorlaştırırdı.
  
  mesela bmw müşterileri aracın frenlediğinde yeterince iyi durmadığı şikâyeti ile geldiğinde bu problemin nedeni değişen lastikler, ya da değişine fren balata sisteminden olabilir, ve asla aracın gerçekten ilk çıktığı zamanda da bu probleme sahip olup olmadığına emin olamazdık. kimse problemin kaynağını tam olarak tespit edemezdi. hele problem tek bir noktadan kaynaklı değil de örneğin o lastik ile o balatanın hiç bilinmez şekilde uyumsuz olması ve problemin tek bir kaynaktan değil de birçok farklı kaynaktan gelen durumun sonucu olursa ne üretici firma ne ithalatçı ne de son satan firma isin içinden çıkamazdı.
  
  işte bu noktada ilk çıkan urun belli oranda değişmez “immutable” olur ise bir problemle karşılaşır isek bu problemin kaynağına iner, orada gerekli incelemeyi yapar, problemi çözer ve kendimizden emin şekilde urunu dağıtabiliriz. yani araç hatası ile doğrusu ile ilk çıktığı gibi olur.
  
  iste yazılım mimarisi de ayni bu duruma sahip. bir veri bir kaynaktan çıktıktan sonra birçok farklı sitem üzerinden geçer, her sistem bu verinin bir noktasını kullanır ve bir başka sisteme devreder. örneğin databaseden çıkan bir veri bir programlama dili üzerinde ilk haline gelir daha sonra çeşitli “pipeline” üzerinde gerekli “stack” ve “queue” larda tutulur, sonra farklı “thread” ler veriyi kullanır, çeşitli “message queue” lar veriyi farklı lokasyonlarda çalışan sunuculardaki “microservices” lere gönderir, onlar da verinin içinden bir şeyleri kullanır ve veri bir noktada seyahatini bitirir. ama bu seyahat sırasında birçok farklı kod parçası bu veriyi islemek için yarışır ve kimi önce kimi daha sonra bu veriye erişir ve isler.
  
  iste karmaşanın asil nedeni budur, bu veri immutable olmaz ise, yani veriyi her bir kod parçası kullanırken kendine gerekli kısımı kullandığı gibi bir yandan da bu veriyi değiştirir ise verinin tüm seyahati sırasında olası problemlere hazır olmamız gerekir. örneğin çalışan bir kodun ihtiyacı olduğu bir şeyi bir başka kod siler ise ne olur. belki hiçbir şey olmaz çünkü çalışan ilk kod o veriyi kullanır ve bir diğeri o veriyi aldığında o veri kullanılmış olduğu için silebilir. belki milyon denemede bile hiçbir problemle karşılaşılmaz. ama gün gelir de çalışan ilk kod çok farklı nedenlerden dolayı birkaç milisaniye geç çalışsa ve diğer ikinci kod o veriyi daha önce ele alıp gerekli değeri silerse iste o anda problemle karşılaşmamız olası.
  
  bu durumun tespiti de o kadar karmaşık ki. bu durum belki geliştirme yapılan, veya testlerin yapıldığı cihazdaki donanımdan veya yükten dolayı oluşmamış olabilir ama belki de sadece gerçek sunucuda bu durumla karşılaşıyor olabiliriz. ya da belki de sunucu da anlık yüklenmeye göre belli bir sure bu durumla karşılaşıyor ama daha sonra bu problem önümüze çıkmamış olabilir. ya da ilk çalışan kodda eklediğimiz yeni bir özellik kodu birkaç milisaniye geciktirmiş olabilir. yani bir problemin oluşması birçok farklı durumun kombinasyonu olabilir ve bu kombinasyon o kadar büyük olabilir ki problemin üzerinde gerekli testleri yapmak ve çözmek imkânsız olabilir.
  
  yani özetle değişebilen “mutable” bir veri ve bu veri birçok farklı kod parçası “thread” tarafından isleniyor ve hatta birkaç farklı cihazda çalışan “microservices” bu veriyi isliyor ise o zaman yazılan kodun ne zaman bozulacağına asla emin olamayız ve her zaman kodumuza kâğıttan yapılmış ve her an yıkılmak üzere olan bir kule edasıyla yaklaşmamız gerekir. bunun en kökten çözümü ise mümkün olduğunca “immutable” veri tipi ile çalışmaktır.
• arkadaslar cinsiyeti immutable tanımlamayin basiniza bela almayin aranizda hala cinsiyeti immutable tanimlayan yazilimcilar var goruyoruz^*