aspect oriented programming

• (bkz: object oriented programming)
  (bkz: structured programming)
• object oriented software design (nesneye dayalı programlama)'nın üzerine java ve çeşitli oo (object oriented) dillerde derleyicisine (compiler) eklenti olarak kendi derleyici'si olan oo eklenti (extension). aslında eklenti demek yanlış olur ama, bu kendi görüşüm. oo programlama sürecinde nasıl bir adım olduysa aspect oriented design da (aod) eğer tutarsa bir oo’dan türemiş ve oo’yu geliştiren bir adım olacaktır, bu yüzden eklenti demenin uygun olduğunu düşünüyorum.
  
  aspect oriented design’nın çıkış noktası ve odaklandığı alan yazılım geliştirme temellerinde yer alan “konuların ayrımı” (separation of concerns), minimum eşleştirme (low coupling), ve her objenin tek işi olması (cohesive) konularıdır. oo tasarımında bu faktörlere dikkat ederseniz, yarattığınız objeler kolaylıkla yeniden kullanılabilir ve genişletilebilir olacaktır.
  
  oo tasarımda ikinci adım, işin mühendisliğidir. her mühendislik alanında olduğu gibi bilgisayar mühendisliğinde de mühendislerin yarattıkları yapıları desteklemek için design patterns (tasarım yapıları) ortaya konulmuştur. şu anda yaklaşık 45 tane yapı bulunmaktadır.
  
  önce işin temeli olan oo temellerini uygularsınız, sonra da design patternleri uygularsınız.
  
  örnek vererek durumun daha iyi açıklanabileceğine inanıyorum:
  bir class'ınız var.
  public class test
  {
  private int x;
  public int y;
  public void setx(int x)
  {
  x = x;
  }
  public int sum ()
  {
  return x + y;
  }
  }
  
  bu class'da diyelim test amaçlı bir nedenden dolayı x'in her değiştiğinde bunu ekrana bastırmak istiyoruz. veya bir simulatör yazıyoruz, ve kasıtlı olarak x'in her değişimini ekrana bastıracağız.
  bu durumda setx(int x) methodunu şu şekilde değiştirmemiz gerekir. ama bu durumun classın orjinal yapılış amacı (evet, x'i tutmak, y'i tutmak, ve x ile y'yi toplayan bir methodu tutmak, başka hiç bir şey değil, yani ekrana bastırmak aslında bu classın işi olmamalı)nın dışına çıkmış oluyoruz.
  public void setx(int x)
  {
  x = x;
  system.out.println(x);
  }
  bu durumu sadece system.out.println'ı kullanmak olarak düşünmeyin, burada ikincil bir classın varlığı da olabilir, ve bu class ile aslında sadece interaksiyon olması yüzünden orjinal test classımızın yapısını bozmuş oluruz. ve aslında bu test classını ikincil classın olmadığı yerlerde kullanmak istesek, kullanamayız, yeniden yazmamız gerekir. bu durum test classinin couplingini (ikili eşleştirme) arttırır, oo tasarım temellerine aslında aykırıdır.
  
  hemen önceki println'lı örneğe dönecek olursak, bu classı ileride yeniden kullanmak istersek kodu temizlemiz gerekir. şimdi buradaki örnekte tek satır ekledik, ama 20 classlı bir projede 400 tane methodun içine bunun gibi bir kod koyarsak işi takip etmenin zorlukları başlardı. bu kodların genel olarak yapısını değişirmek istesek (mesela ekrana bastımak yerine bir file’a yazdırsak, o zaman saatlere varan bir uğraş vermemiz gerekirdi).
  
  burada setx() in içinde yer alan println komutunun olduğu noktaya crosscutting concern denir. crosscutting, bir nedenden dolayı bir veya birden fazla classın içine başka classlar ile ilişki kurarak coupling’i arttırmamız, ve (şaçılmış kod) scattering e neden olmamızdır. scattering bir iş için yazmamız gereken kodun yukardaki örnekteki gibi 400 methodun içine başka classlar ile ilişkili kodlar yazarak methodlarımızı merkezi bir yerden değil, dağınık bir yapıda kod ekleyerek kirletmemiz olarak görülebilir. bu durum yukardaki örnekteki sorunları çıkarmaktadır, ve yazdığımız kodun kalitesini düşürmektedir.
  
  crosscut eden konular senkronizasyon, gerçek zamanlı değişkenler, hata kontrolü, hata düzeltme, güvenlik, görselleştirme, vb. olarak görülebilir.
  
  aspect oriented design crosscutting konuları tanımlayarak bu konuları projenizdeki classları kitletmeden modüler bir şekilde kontrolünü sağlamaktadır.
  
  aspect oriented designnın tarihinde çıkan ve literatürde bir yer kazanan teknolojiler:
  - composition filters (1991) university of twelte,
  - aspectj (1997) xerox parc
  - demeterj/dj (1993) northeastern university
  - multi dimentional separation of concerns/hyperj (1999) ibm
  
  joinpoint: eklemek istediğiniz crosscutting konunun (yukardaki örnekteki println) nereye konması gerektiğini belirleyen nokta. bu bir method çağrılması, methodan dönüş, obje yaratımı, ver değişkeinin değiştirilmesi gibi şeyler olabilir.
  pointcut: jplerin tanımlanmasını sağlayan kod parçası.
  
  burada x’in değiştirilmesini sağlayan setx methodunu şu pointcut ile tanımlayabiliriz:
  
  pointcut xdegistir(int x): call(test.setx(..)) && args(x);
  
  bu pointcut test classının adı setx olan ve içine integer parametresini kabul eden methodları çağrıldığı an.
  çok kullanılan pointcut komutları:
  call: çağrıldığı zaman
  execution: çalıştığı zaman
  get: bir değer alındığı zaman
  set: bir değer değiştirildiği zaman
  
  pointcut ile belirttiğimiz joinpointlerde ne yapılacağını advice ile belirtiriz:
  
  after(): xdegistir(int x)
  {
  system.out.println(x);
  }
  
  bunun adı after advicetır. bu advice da belirttiğimiz pointcuttaki noktada paratmetre olarak pass edilen xi ekrana bastıran kod. bu kod method çalışıp bittikten sonra çalışır (before() kullansaydık once çalışırdı).
  
  pek kısa olmadı ama kısaca aspect oriented software design budur. pointcutlar belirtilir, nerede sorusunun cevabı belirtilir. sonrada bu pointcutlarda yapılacak işler yazılır, ve bunlar once aspect compileri ile (bu aspectj olabilir, composition filter olabilir) compile edilir. bu compiler, yazdığınız aspectleri pure java yapar (bunu class seviyesinde yapar), sonrada java compilerı ile compile edersiniz. programınız çalışır.
  
  zaten herşey programımız düzgün çalışsın diye.
• (bkz: http://aosd.net/)
• (bkz: http://www.cs.ubc.ca/…rs/kiczales-ecoop1997-aop.pdf )
• php için bir implementasyonuna şuradan ulaşılabilir:
  http://www.phpclasses.org/browse/package/3215.html
• ilk entry'e bakınca böyle bir programlama mantığının neden bu kadar zaman sonra bile kabul görmediğini ve yahut yaygınlaşamadığını anlamadım. forumlarda ya da hakkında yazılan yazıları okuduktan sonra genelde loglama, print etme, email atma gibi fonksiyonalitelerde kullanılabilirliğinden bahsetmişler. ancak böyle bir yazılım mantalitesini bu kadar dar bir alanla kısıtlamak vicdansızlıktır zannımca.
  
  henüz dotnet tarafından bilfiil desteklenmediği için uzak kalmışım, hiç duymamışım anlaşılan. var olan 3rd party compilerlar ve aspectj uygulamalarını incelediğimde bunun method encapsulation'ı olduğunu düşündüm. yani method'un çağrılma safhalarında araya girebilen daha doğrusu method'u kendisi servis edebilen bir yapı. böylelikle method'u trace edebiliyor, değişkenlerine ulaşabiliyor [galiba].
  
  asıl önemli getirisinin mottosu ise şu: "software development exists because of business concerns" [1]
  
  yani "ticari ihtiyaçlar olmasa idi programcılar babayı almışlardı" demek. bundan yola çıkarak yaptığımız projeleri göz önüne getirelim. aynı uygulamayı farklı müşterilere paket halinde sunsanız bile müşteri her zaman ek ihtiyaç ile gelecek ve "şu da olsun, bu da olsun" diyecektir. eğer paket programa önem veriyor ve müşteri bazlı case'leri uygulamanıza almak istemiyorsanız ya "if (musteri==1)" gibi bok püsürle dolduracaksınız kodu ya da dinamik olarak müşteri bazlı harici yerde tutulan uygulamalar ve datalar ile sisteminizi entegre edeceksiniz. günümüz dll, exe bazlı geliştirmelerdeki problem de burada devreye giriyor işte. compile edilmiş bir koda nasıl müdahale edeceksiniz? müşteri bazlı geliştirmeleri kodu sikmeden nasıl gerçekleyeceksiniz?
  
  bu yöntem bir çözüm olabilir gibi duruyor. joinpoint'lerde araya girip müşteri bazlı geliştirilen harici dll'leri kullanabilirsiniz [sanırım, yapıyı tam anlayınca kesin bir şey söylerim].
  
  event driven programming ile de çok ciddi benzerlikleri var şu an ki hali ile. belki de bu yüzden daha tam olarak ihtiyaç duyulmadı.
  
  bana biraz sap'i hatırlattı birde. user exit denilen müşteri bazlı geliştirmelerin yapıldığı kod bölmelerinin çıktığı ihtiyaçtan çıkmış gibi. sap'de kod veri tabanında durur ve hem orjinal standart koda hem de user exit'lere kod yazabilir, değişiklik yapabilirsiniz. aop bu benzetmede user exit'e denk geliyor.
  
  bana bunun yerine run time'da x dosyasında yer alan kodu [string] compile edecek [primitive type'lar haricindeki type'larda hata vermemek koşulu ile] ve execute edecek bir framework tool'u versinler daha iyi [şu an ki hali için söylüyorum].
  
  [1] http://www.dotnetspark.com/…mming-c-sharpnet--.aspx
  [2] http://www.dotnetspark.com/…mming-c-sharpnet--.aspx
  
  çabuk gelen edit: codedom sınıfı ile yapılıyormuş ama sınıfın kendisini vermek gerekiyor. method compilation yok yine.
  http://www.codeproject.com/…namiccompileandrun.aspx
• ciddi bir iş yapıyorsanız ve ortada gerçekten büyük kompleks bir yapı varsa çok dikkatli kullanılması gereken hede. business logice hakimseniz ama aop olayına hakim değilseniz veya tam tersi aop hadisesine hakim olup business logice hakim değilseniz bulaşmayın derim aksi takdirde elinizde kalması kuvvetle muhtemel. bir noktadan sonra hangi joinpointte hangi advice çalışıyor, ne sırada çalışıyor karışıyor ki biz buna literatürde kimin eli kimin götünde diyoruz.
• spring framework'e oop'nin bir nevi tamamlayıcısı olsun diye eklenmiş programlama modeli. büyüyüp gelişip serpilmesi, aramıza katılması çok uzak değil.
• http://www.gelistiricigunlugu.com/…ted-programlama/
• (bkz: postsharp)