Neden Spring, JPA ve Diğer Çatılar ÖğrenilmeMEli

Bu başlığın çok provokasyon yüklü olduğunu biliyorum. Ama zaman ayırıp, yazımın geri kalanını okuyabilirseniz, ne demek istediğimi açıklamaya çalışacağım.

Yazılımda bağımlılıkların tersine çevrilmesi (DIP – Dependency Inversion Principle) isminde bir tasarım prensibi var. Burada yer alan yazımda bu tasarım prensibinin ne olduğunu ve nasıl uygulandığını göstermeye çalıştım. DIP kullanılmadığı taktirde kırılgan kod birimleri oluşur. Bunun başlıca sebebi, bağımlılıkların sıkça değişikliğe uğrama potansiyeline sahip olan somut sınıflar yönünde olmasıdır.

DIP yazılımda iki kavramın varlığına işaret ediyor. Bunlar:

• Soyutluk
• Somutluk

Yazılımda soyut yapılar hangi işlemin yapılması gerektiğini tanımlarlar, ama nasıl yapıldıklarını göstermezler. Örneğin Java dilinde interface sınıfları yardımı ile soyut işlemler tanımlanır. Aşağıda bunun bir örneğini görmekteyiz:

public interface Logger{
 
  void log(String msg);
}

Bu örnekte Logger isminde soyut bir sınıf tanımladık. Bu sınıf bünyesinde yine soyut olan ve log ismini taşıyan bir metot yer alıyor. Logger sınıfı loglama işlemini soyut bir şekilde tanımlamakta. Sınıf bünyesinde loglama işleminin somut olarak nasıl yapıldığını göremiyoruz. Şimdi Logger sınıfının somut bir halini görelim:

public class Logger{
 
  void log(String msg){
       System.out.println(msg);
  }
}

Yukarıda yer alan Logger sınıfı somut bir sınıftır, çünkü loglama işlemi için somut bir implementasyona sahiptir. Bu implementasyon değişikliğe uğrayabilir. Örneğin log4j bazlı bir loglama yapılmak istendiğinde, somut olan Logger sınıfının adapte edilmesi gerekmektedir. Bu adaptasyon Logger sınıfını kullanan diğer sınıflar üzerinde etki yaratır ve onların da değiştirilmesine sebep olabilir. Bu yüzden somut sınıflara olan bağımlılıklar uygulamanın kırılganlığını artırır. Bunun önüne geçmenin yolu DIP tasarım prensibini uygulamaktan geçer. Ama bu yazımda maksadım DIP tasarım prensibini tanıtmak değildi. DIP’i örnek vererek, çok daha değişik bir konuya değinmek istiyorum.

DIP ve diğer tasarım prensipleri uygulamaların nasıl yapılandırılmaları gerektiği konusunda fikir beyan eden soyut yapılardır. Kendilerinin nasıl implemente edilmeleri gerektiği konusuna değinmezler. Kullanılan programlama dilini göre somut implementasyonları değişmektedir. Bu yüzden tasarım prensiplerini bir yazılım felsefesi olarak düşünebiliriz. Bu felsefeyi tanıdığımız sürece onları istediğimiz bir dilde uygulayabiliriz. Onlardan faydalanabilmek için nasıl uygulandıklarını değil, ne için var olduklarını bilmemiz, yani bu felsefeye hakim olmamız gerekmektedir.

Dün genç bir yazılımcı arkadaşımızdan bir e-posta iletisi aldım. “Spring çatısını öğrenmeye çalışıyorum, ama ne amaçla kullanıldığını bir türlü anlayamıyorum” demiş. Spring’i yeni öğrenen herkesin bu sıkıntıyı çektiğinden eminim. Bu gerçek problemin ne olduğunu örten bir semptom. Spring ve diğer çatıları öğrenmek isteyenler bu acıları çekiyorlar, lakin asıl sorunun ne olduğunu bilmiyorlar.

Yazımın başında yazılımda var olan iki kavramdan bahsetmiştim: soyutluk ve somutluk. Eğer DIP soyutluk ise, Spring ve var olan diğer tüm yazılım çatıları somutluktur. DIP soyut bir felsefe ise, Spring somut bir teknolojidir.

Spring’in temelinde şu felsefeler yatıyor:

• interface bazlı programlama: Spring bağımlılıkların soyut sınıflara doğru olmasını teşvik ediyor. Spring somut bir DIP implementasyonudur.
• Bağımlılıkların enjekte edilmesi: Spring ile bir sınıfın ihtiyaç duyduğu tüm bağımlıklar o sınıfa dışarıdan enjekte edilebilir. Bu somut implementasyonun altında Hollywood prensibi (dont call us, we call you) ya da felsefesi yatıyor. Bu felsefeye göre bir sınıf ihtiyaç duyduğu şeyleri toplamak yerine, bu şeyler sınıfa dışarıdan enjekte ediliyor.
• Nesnelerin olusturulması: Spring singleton ve prototype tasarım şablonlarını kullanarak, nesneleri oluşturur ve ihtiyaç duyan nesnelere enjekte eder.
• Transaksiyon yönetimi: Spring bir veri tabanı transaksiyonunu yönetmek için vekil tasarım şablonunu implemente eder.

Tasarım prensipleri ve şablonları konularında hiç ihtisas yapmamış birisinin Spring çatısının ne olduğunu ve neden kullanılması gerektiğini anlaması imkansızdır. Bir teknolojinin nasıl kullanıldığını bilmek ile neden kullanılması gerektiğini bilmek arasında büyük farklılıklar vardır. Nedenin cevabını verebilmek için altında yatan felsefeyi kavramış olmak gerekmektedir. Bir şeyin nasıl kullanıldığını öğrenmek için neden kullanılması gerektiğini bilmek zorunluluğu yoktur. Lakin neden kullanılması gerektiği bilinmeyen bir şeyin nasıl kullanıldığını bilmekte çok faydasızdır. Yazılım piyasasında ne yazık ki bir takım çatıların nasıl kullanıldığını bilen ama neden kullanılmaları gerektiği konusunda fikir sahibi olmayan yazılımcılar mevcuttur, çünkü temelde yatan felsefe ve soyutluktan bihaberdirler.

Günümüzde, özellikle yazılım sektöründe somutluk soyutluğun yani teknoloji felsefenin önüne geçmiş durumda. Yazılımcılar işin temelinde yatan felsefeyi anlamadan somut teknolojilere yönelmektedirler. Birçok yazılımcının Spring ve Hibernate gibi bir takım çatıları öğrenme çabasında olduklarını gözlemliyorum. Bana gelen sorular da genelde “hangi çatıyı öğrenmeliyim” şeklinde oluyor. Bu konuda benim cevabım aynı oluyor: “teknolojiyi değil, bu işin felsefesini öğrenmeye gayret edin”. Ne olduğu kavranamayan bir çatıyı kullanmaya çalışmak beyhude bir iştir. İşin felsefesine değil de teknolojisine yönelen yazılımcılar daha iyi programcı olamama yolunda istikrarlı bir şekilde yürümektedirler.

Şimdi tekrar yazımın başlığına geri dönmek istiyorum. “Neden Spring, JPA ve diğer çatılar öğrenilmemeli” demiştim. Bu başlığı “Neden teknoloji yerine önce felsefesi öğrenilmeli” şeklinde değiştirmek istiyorum.

Teknolojiler gelip, geçicidir, felsefeler ise her zaman daim…

EOF (End Of Fun)
Özcan Acar