object oriented software design
(nesneye dayalı programlama
)'nın üzerine java ve çeşitli oo
(object oriented) dillerde derleyici
sine (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.