Makale Özeti

Nesneye yönelik programlama varolduğundan beri temel programlama ilkeleri geçerliliğini halen yitirmiş değil. Dünden bugüne 2 temel ilke üzerine bina edilmiş programlar üzerinde çalışıyoruz. Temel amaç tekrardan kaçınmak ve yazılımın entropi düzeyini başedilir seviyelere indirmek.

Makale

Özet

Nesneye yönelik programlama varolduğundan beri temel programlama ilkeleri geçerliliğini halen yitirmiş değil. Dünden bugüne 2 temel ilke üzerine bina edilmiş programlar üzerinde çalışıyoruz. Temel amaç tekrardan kaçınmak ve yazılımın entropi düzeyini başedilir seviyelere indirmek. Bu temel ilkeler:

1. Kapsülleme : değişmeye açık program birimlerinde bilgi ve tasarım saklama tekniğidir. Program birimini kullanan istemciler olası değişimlerden en az seviyede etkilenirler.

2. Uyuşma : program birimi içersinde yer alan kodlar sadece bir tek amaca hizmet eden dolayısıyla kendi içinde tutarlılık sağlama tekniğidir. Eğer satınlam metodunuzda satınalma hizmetinin dışında farklı alanlara hizmet eden kod parçacıkları varsa burada uyuşmadan bahsedilemez.

Nesneye yönelik programlama her ne kadar sınıflar düzeyinde bu temel ilkeleri sağlamaya yönelik önemli bir devrim yapmışsa da, halen bazı kısıtlar ve problemlerden kurtulmuş değil.

Cepheye Yönelik Programlama

Cepheye Yönelik Programlama (Aspect Oriented Programming) yaklaşımı aslında çok yeni bir kavram değil, temelleri 90’lı yıllara dayanan bir geçmişi var. Framework ve araçların gelişmesine paralel yaygınlığı giderek artış göstermekte.

Yazılımların kod tabanlarını incelediğimizde, bazı noktaların (ilgilerin) farklı katman ve modüllerde sürekli tekrar ettiğini farketmişsinizdir. Örneğin exception handling, transactionlar, güvenlik kontrolleri, caching, loglama vb gibi ilgiler (concern) yazılımların en çok tekrarlanan etmenlerinden bazıları. Bu ilgiler literatürde cross-cutting concerns olarak geçmekte. Bunu enine kesen ilgiler olarak çevirmek mümkün. Terimin aklınızda canlanması için aşağıdaki resmi kısaca açmak istiyorum. Dikeyde bulunan dikdörtgenler bir kod dosyasını temsil ediyor. Dikdörtgenin içinde geçen kırmızı çizgilerse enine kesen ilgilerden oluşan kod parçaları.

Ortalama bir tahminle kurumsal mimari standartlara uygun bir yazılımda, enine kesen ilgiler toplam kod tabanının 10% ile 15%’ ine tekabül eder. Bu yüzbinler ile ifade edilebilecek bir sistemde 10 – 50 bin satır arasında değişebilecek bir kod parçasına denk gelir. İlgilerin fonksiyonel gereksinimleri karşılayan kod birimlerinin içinde yer almasının getirdiği sıkıntılar aşağıdaki gibidir:

- Kodun karmaşıklık düzeyi bir çok ilginin girmesi ile birlikte artış gösterir. İlgiler farklı modül ve birimlere dağılmıştır.
- İlgilerde yapılacak olası bir değişikliğin değişim maliyeti yüksektir. Örneğin yıllar sürmüş bir projenizde caching ve transaction stratejilerinizde yeni teknoloji ve çerçeveler ile yenileme yapmanız gerekiyor. Tüm iş katmanında transactionların, veri katmanında cachingin uygulandığını düşündüğünüzde tüm noktaları refactoring ya da gelişmiş replace ile değiştirmeniz neredeyse olanaksız. Bu sürecin manuel etkisi bi hayli büyük olmaktadır.
- İlgilerin kod içinde olması uyuşma prensibine aykırı düşmekte bu da esnekliğe zarar vermektedir.
- İlgiler metod seviyesinde sürekli olarak tekrarlanmaktadır ve üretkenliği azaltmaktadır.
- İlgiler kurumsal uygulama standartlarının olmazsa olmaz yapılarıdırlar. Bu yapıların programcının insiyatifine göre uygulanması ve denetlenmesi zordur. Sık sık bazı bölümlerde exception handling ya da transaction uygulamalarında eksikler veya standart dışı hatalı kullanımlara rastlamak mümkündür.

AOP yaklaşımı enine kesen ilgileri fonksiyonel kod birimlerinden ayırarak modüler bir yaklaşım geliştirmektedir. İlgiler ayrı modüllere dağıtılmış ve fonksiyonel gereksinimleri karşılayan kodlar ilgilerden tamamen ayrıştırılmıştır.

AOP Framework ve araçları 2 temel teknik ile bunu gerçekleştirmektedir.

1) Dinamik Proxy ve Intercepting : uygulama çalışma kipinde dynamic proxy’ ler ile aspectler uygulanmaktadır. Bu yaklaşım gerek performans gerek aspectlerin uygulandığı sınıfların belli sınıflardan kalıtım yapma zorunluluğu olması nedeniyle kısıtlayıcıdır. Bu yöntem bi çok açıdan tercih edilmemekte ve uygulama alanında zorluklar içermektedir.
2) Derleme Zamanı (Compile Time) : IDE’ lere bütünleşik çalışan AOP framework ve araçları post-compile aşamasında yani derleme sonrasında aspect’ leri kodun içersinde gerekli yerlere enjekte etmekte ve o şekilde derlenmesini sağlamaktadır. Bu yöntem performans ve uygulanabilirlik açısından şuanda en kolay yöntem olarak tercih edilmektedir. Post-compiler’ lar yardımı ile kaynak kodların içersinde bulunmayan cepheler derleme aşamasının sonunda koda eklenmektedir.

Örnek Uygulama

Örnek olarak basit bir metod ele alacağız. Uygulama standartlarımız gereği tüm iş katmanı sınıflarında yetki kontrolü, denetim loglama, ön bellekleme, transaction yönetimi ve exception yönetimi gibi ilgileri uygulamak zorundayız. Bu durumda AOP’ in getirdiği fark nasıl olurdu?

Geleneksel Programlama


AOP’ li Proglama


Şaşırtıcı bir fark doğrusu. AOP’ li uygulamada custom attribute’ ların kullanımı ile ilgiler metoda kolaylıkla bağlandı. Metod sadece kendi sorumluluk alanı içersinde 3 satırlık kod içeriyor. Kodun okunabilirliği çok basit ve sade. Neresinden bakarsanız bakın kardasınız.

Peki bu nasıl mümkün oldu. Bir sonraki yazımızda AOP’ in Policy Injection Application Block ve Postsharp’ ın birlikte kullanımı ile pratik uygulamalarından bahsetmeye çalışacağız.

Faydalı Bağlantılar

· https://mice.cs.columbia.edu/getTechreport.php?techreportID=438
· http://www.postsharp.org/aop.net
· http://blogs.microsoft.co.il/blogs/dorony/archive/2007/01/29/Using-AOP-and-PostSharp-to-Enhance-Your-Code_3A00_-Part-A.aspx
· http://en.wikipedia.org/wiki/Aspect_oriented_programming
· http://www.codeplex.com/entlibcontrib
· http://blogs.msdn.com/edjez/
· http://www.codeplex.com/entlib

www.oguzbayram.com