Aspect-Oriented Programming (AOP3 - İlgiye Yönelik
Programlama) yeni aspect birimleri sayesinde crosscutting (enine kesen)
ilgilerin birbirinden ayrışmasına olanak sağlamaktadır.Separation of Concerns
(SoC, İlgilerin Ayrışması), AOP yardımıyla gelişmektedir çünkü her ilgi aspect
birimi olarak ayrı bir şekilde tasarlanmaktadır. Yukarıda gösterilen metodu
tekrar düşünürsek, içindeki 4 ilgi artık 4 farklı birbirinden ayrı bir
crosscutting birim olarak oluşturulacaktır. Diğer bir deyişle, doSomething
metodunun içindeki ilgiler kendi birimlerine aktarılacak ve böylece metod kendi
esas kodlarını uygulayarak metodun okunabilirliği ve bakımı da doğru orantılı
bir şekilde artmış olacaktır. Daha önce de belirttiğimiz kod dağınıklığı ve kod
saçılmasının da önüne geçmiş oluyoruz AOP yaklaşımını projemizde kullanarak.
Şekil 2 bu yapılanmanın bir örneğidir. Sol tarafa bakacak olursak, artık
turuncu ilgi birimlerin (A, B, C) içinde mevcut değildir, sadece bu ilgilinin
program başlatıldığında çalışması gerektiği yerler belirlenmiştir. Tekrar B
birimine yakınlaşırsak göreceğimiz en belirgin özellik kod miktarındaki
azalmadır çünkü artık B birimi sadece kendi kodlarından sorumludur. Dikkatle
bakıcak olursa en üstteki ve en alttaki gri (esas) kod bloğu bu ilgiler ile
çalışmaktadır. Üstteki gri blokta sarı, kırmızı ve turuncu ile alttaki gri ilgi
de turuncu (tekrar) ve turkuvaz ilgileriyle çalışmaktadır. Şekilde tüm noktalar
crosscutting birimlerine işaret etmektedir ve bunlar AspectJ dilinde Join Point
Shadows (birleşim noktası gölgeleri) olarak adlandırılır.
Aynı kod bloklarında birden fazla
crosscutting ilgileri olabilir (örneğin: doSomething metodu ve Şekil 2 sağ
taraf). Bu ilgilerin hangi düzende çalışacağını belirlemek için AspectJ
Composition Mechanism (Düzenleme Mekanizması) kullanmaktadır. Kod saçılması
size kopyala-yapıştır mantığını çağrıştırabilir. Nitekim öyle çünkü aynı kodu
(ilgiyi) sürekli diğer birimlere uyguluyoruz (Şekil 1 sol taraf). Aspect birimleri
sayesinde bu kopyalama işlerinden de sıyrılmış oluyoruz. Tek bir ilgiyi bir
modülde yazıp bağlanması gerektiği yerlere bağlayarak çalışmasını sağlıyoruz
(Şuan bu bahsettiğim tam anlaşılmayabilir ileriki bölümlerde bunların hepsini
rahatlıkla kavrayacaksınız).
AOP ayrıca önemli Agile
programlama prensiplerinden "You aren’t gonna need it" (YAGNI) pratik
yapmanıza imkan verir. Asıl sistem kodlarını yani esas kodları değiştirmeden
ayrı aspect birimleri uygulayarak sistemin gereksinimlerini giderebilirsiniz,
ayrıca gerektiğinde mevcut sistemin mekanizmasını bozmadan o fonksiyonelliği
çıkarabilirsiniz. AOP aynı zamanda sistemlerin gelişmesine yardımcı olur, yeni
crosscutting ilgilerin uygulanmasını kolaylaştırır. Ayrıca, esas birimlerin
kodlarına karışmaz ve sistemin bu esas birimleri aspect birimlerinden tamamen
farkında olmazlar. Ayrıca bir önemli bilgiyi de sizlere kısaca anlatmak
istiyorum. Sistemin esas birimleri aspect birimlerinden habersiz olmaları
AOP’un bize sunduğu bir dezavantajdır aslında. Şöyleki, crosscutting ilgilerin
esas bölümlerden ayrı yerlere konulup sistemin çalışma akışını bozmadan aspect
birimlerinin içinde devam etmesi, esas sınıfların bu ilgilerden habersiz
olmalarına yol açıyor çünkü esas sınıflar bu aspect birimlerini göremiyor (ne
extends ne de implements yolu ile bunlara ulaşamıyorlar). Bu AOP topluluğunda
obliviousness (dikkatsizlik, bihaber olma, ilgisizlik) olarak geçmektedir.
Sonuç olarak, AspectJ geliştiricileri için ve sınıfların bu ilgilere
ilgisizliğini azaltmak amacıyla farklı plug-inler geliştirilmektedir (Örnek:
AJDT4 ).
Şekil 1.2. AOP yaklaşımı ile sorunun giderilmesi
Kaynaklar:
