1. ‘Aspect Oriented’ programlama mı…Nedir ki?
2. Peki ama neden ‘Aspect Oriented’ programlama…
3. ‘Aspect Oriented’ programlamaya başlıyoruz…Bölüm I

Bu yazıda bir önceki kod alt yapısını üzerinden giderek, AOP kavramında ki Aspect’leri yaratıyor olacağız. Özellikle “Aspect” şeklinde belirtmek istiyorum ki, yarattığımız bazı örnek sınıfları bu şekilde düşünmeye çalışmak, konunun bütününü anlamak adına yardımcı olacaktır. Hatırlarsanız bir önceki yazıda Person diye bir sınıf oluşturmuştuk örnek olarak ve bu sınıfı bir tane konsol uygulamasında kullanarak methodlarını çağırmadan önce nasıl araya girebileceğimize değinmiştim. Yine aynı sınıf üzerinden, onu biraz daha geliştirerek gidiyor olacağız. Bunun için sınıfımızı aşağıdaki gibi yenilememiz yeterli olacaktır şimdilik. Yeni bir özellik ve metod dışında aslında fazla bir şey de yok.

    [Controller]
    public class Person : ContextBoundObject
    {
        private int _age = 0;
        private string _name = "";

        public string Name { get { return _name; } }

        public Person(string name) : base() { _name = name; }

        public int Age
        {

            get
            {
                return _age;
            }
            set
            {
                _age = value;
            }
        }

        public string DoSomething()
        {

            string logMessage = "Person sınıfının DoSomething() methodu çalıştı";
            Console.WriteLine(logMessage);

            return "";
        }
        public void DoAnotherThing(int parameter1, string parameter2)
        {
            Console.WriteLine("Person sınıfının DoAnotherThing() methodu çalıştı");
        }

    }

AOP, yazılımda ki kesişen ilgileri ayırmak için kullanabileceğimiz bir yöntemdi demiştik. Bu ilgiler her yazılım ürününde bir şekilde olan Logging,Exception Handling gibi kavramlar olabileceği gibi, iş kuralları ve bu kuralların işletildiği methodlar da olabilir. Ama genellikle bir biri ile çakışan ilgiler Logging,Exception Handling, Security gibi kavramlar için daha karmaşık olur. Oluşan Exception için uygun kaydı tutmak, ya da bir metod çalıştığında bu metodun çalışmasına dair bazı bilgileri kayıt altına alabilmek bir çok kavramın iç içe girmesine sebep olur. Bu yazıda bu ilgilere biraz daha yer vererek, bu ilgileri AOP yaklaşımı ile nasıl ayırabileceğimizi anlamaya çalışacağız. Örnek olabilecek bir kaç ilgiyi oluşturup, bunu Person sınıfımızda kullanacağız. Bu ilgileri .NET Framework’ünde bulunan Attribute‘lar ile yaratıp, nesnelerimize,metodlarımıza ve nesnelerin özelliklerine bağlayacağız. Aşağıdaki gibi bir kaç nesne, örnek olması adına yeterli olacaktır diye düşünüyorum.

    //Aspect'lerimiz için ortak bir yapı oluşturuyoruz.
    //Bu örnek için oldukça basit bir yapı oluşturmak
    //şimdilik yeterli olacaktır.
    //Attribute sınıfından türeyen bir BaseAspect sınıfı
    //oluşturuyoruz.
    public abstract class BaseAspect : Attribute
    {
        //abstract anahtar kelimesi ile tanımladığımız bu metodu
        //BaseAspect sınıfından türeyen tüm sınıflar yaratmak durumunda.
        //Bu method bu Aspect'in yapmakla yükümlü olduğu metodu simule ediyor
        //olacak...
        public abstract void Process(ref IMethodCallMessage message);
    }

    //Uygulamamızda Log'lama gerektiren yerlerde kullanabileceğimiz bir
    //ilgiyi bu şekilde tanımlayabiliriz.Bu Log'lama için ne yapılması gerekiyorsa
    //kendi içinde yapıyor olacak. BaseAspect sınıfımızdan gelen Process methodunun
    // message parametresinden istediğimiz özellikleri ihtiyacımıza göre alabiliriz.
    //Eğer kendi Log'lama için kullandığımız arayüzler varsa onları message parametresinden
    //çekip kullanmak mümkün.Bu örnekte konsola kayıt mesajı yazdıracağız.
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Method)]
    public class Logger : BaseAspect
    {
        public Logger()
        {

        }

        public override void Process(ref IMethodCallMessage message)
        {
            StringBuilder sb = new StringBuilder();
            if (message.Args != null)
            {
                //Metoddan gelen parametreleri yazdırıyoruz.
                for (int i = 0; i < message.Args.Length; i++)
                {
                    sb.Append(String.Format("{0}={1}\r\n\t\t\t\t",message.GetArgName(i),message.Args[i]));
                }
            }

            Console.WriteLine("##LOG## "+DateTime.Now.ToString()+" - "+ message.MethodName + " methodu çalışacak.\r\n\t\t\t\t" + sb.ToString() );
        }
    }

    //CanDrive adındaki Aspect'imiz aslında bir iş kuralını temsil ediyor
    //Aldığı parametre ile bir yaş sınırı belirlediğimiz bu ilgimiz
    //beraber kullanıldığı parametrenin yaş özelliğini kontrol ediyor.
    //Bu örnekte önemli olan nokta message parametresinden bize lazım olan bir
    //nesneyi kullanabilmemiz. Bu noktada altını çizmek isteyeceğim bir nokta var.
    //CanDrive kuralı kavram olarak hangi nesneler ile ilgili olacaksa bunların çok iyi belirlenmesi
    //gerekmekte. Buna göre içerisinde ki iş kuralı ve metodları dikkatlice yazılmalı.
    //Bu örnekte CanDrive, Person sınıfını kullanıyor. Çünkü CanDrive'ın ilgisi Person ile...
    //İlk yazımda da dediğim gibi AOP'i ilgileri ayırmak ve ayrıca yönetmek içinde kullanabiliriz.
    [AttributeUsage( AttributeTargets.Parameter)]//Sadece parametrelerde kullanabiliriz bu ilgiyi...
    public class CanDrive : BaseAspect
    {
        private int _age;

        public CanDrive(int age)
        {
            _age = age;
        }

        public override void Process(ref IMethodCallMessage message)
        {
            Person p = (Person)message.GetArg(0);
            if (p.Age < _age)                 throw new Exception(String.Format("{0} araba süremez.Yaşı küçük.{1}", p.Name, p.Age));         }     }     //Bu seferde belli yaş aralığını kontrol eden ilgimiz var.     //CanDrive'a kavram olarak benziyor. Ama uygulama konusunda farklılık var.     [AttributeUsage(AttributeTargets.Property | AttributeTargets.Method)]     public class AgeValidation : BaseAspect     {         private int _age;         public AgeValidation(int age)         {             _age = age;         }         public override void Process(ref IMethodCallMessage message)         {             int ageValue = -1;             if (message.Args != null && message.Args[0] != null)                 ageValue = (int)message.Args[0];             if (ageValue > _age)
            {
                throw new Exception(String.Format("Yaş en çok {0} olabilir.{1} geçerli bir yaş değil.", _age, ageValue));
            }

        }
    }

Bu yaratmış olduğumuz ilgileri bir önceki yazıda oluşturduğumuz alt yapının algılayabileceği şekilde bir kaç değişiklik yapmamız gerekecek. Bunun için aşağıdaki değişikliği Control sınıfımıza eklememiz yeterli olacaktır.

    public class Control : IMessageSink
    {

        private IMessageSink _messageSink;

        //İçeriğe dahil olan nesneler üzerinde kontroller yapabileceğimiz
        //nesneyi yaratmak için kullanacağımız yapıcı metodu,
        //alıcısını alacak şekilde tanımlıyoruz.
        public Control(IMessageSink sink)
        {
            _messageSink = sink;
        }

        //SyncProcessMessage metodu gelen alıcı mesaj aldığı zaman
        //çalışan bir metod. Bu metod ile alıcıya mesaj geldiği zaman
        //çeşitli kontrollerin yapılmasını sağlayabiliriz.
        //Burada mesaj diye tanımladığım operasyon aslında içeriğe dahil olan
        //nesnenin bir metodunun çalışması ya da bir özelliğinin çağrılması.
        //Bu örnekte şimdilik konsola bir mesaj yazdırıyor olacağız.
        public IMessage SyncProcessMessage(IMessage msg)
        {
            if (msg is IMethodCallMessage)
            {
                IMethodCallMessage preCall = (msg as IMethodCallMessage);
                this.BeforeMessageCall(ref preCall);//BeforeMessageCall diye bir metod yaratıyoruz.

            }
            return _messageSink.SyncProcessMessage(msg);
        }

        //AsyncProcessMessage metodu da SyncProcessMessage metodu ile aynı.
        //Sadece asenkron çağırımlarda çalışan versiyonu
        public IMessageCtrl AsyncProcessMessage(IMessage msg,
           IMessageSink replySink)
        {
            Console.WriteLine("Heyyy, önce bir dur bakalım...");
            return _messageSink.AsyncProcessMessage(msg, replySink);
        }

        //BeforeMessageCall metodu ile nesne yaratmadan önce,metod çağırmadan önce
        //ya da bir özelliği çağırmadan önce yapacağımız işlemleri çağırıyoruz.
        //Burada BaseAspect diye Attribute'ten türetilen kendi nesne tipimizi kontrol ediyoruz.
        //Eğer gelen mesajın özellikleri bu BaseAspect tipindense onun Process methodunu çağırıyoruz.
        //Burada hem metod hem de metod'un parametreleri var ise ve parametrelerde de BaseAspect tipi
        //olabilir mi diye kontrol ediyoruz.
        //-----------------------------------------------
        //Burada sadece method ve parametrelerini kontrol ediyoruz. Burada ki yapıyı genişleterek
        // daha güzel bir içerik yapabiliriz.
        private void BeforeMessageCall(ref IMethodCallMessage msg)
        {
            //Methodun
            BaseAspect[] attributes = msg.MethodBase.GetCustomAttributes(typeof(BaseAspect), true) as BaseAspect[];
            foreach (BaseAspect item in attributes)
            {
                item.Process(ref msg);
            }

            //Metodun parametrelerini alıyoruz.
            ParameterInfo[] parameters = msg.MethodBase.GetParameters();
            foreach (ParameterInfo item in parameters)
            {
                //Parametre değerlerinde BaseAspect'ten türeyen bir Attribute var mı kontrol ediyoruz.
                //Var ise metod çağrılmadan önce sahip olduğu Attribute çağırılıyor.
                attributes = item.GetCustomAttributes(typeof(BaseAspect), true) as BaseAspect[];
                foreach (BaseAspect parameterAttribute in attributes)
                {
                    parameterAttribute.Process(ref msg);
                }
            }

        }
   }

Bütün bunları yaptıktan sonra elimizde ne var kısaca bir özetleyelim; metodlarımızı, nesnelerimizi ve nesnelerin özelliklerini çağırmadan araya girebileceğimiz bir alt yapı, bu alt yapı içerisinde çeşitli sınıfları çalıştırmamızı sağlayacak metodlar ve çeşitli sınıflarımız(ilgilerimiz ya da “Aspect”lerimiz)

Şimdi bu yarattığımız ilgileri Person sınıfında kullanalım. Bunun için aşağıdaki gibi eklentiler yapmamız gerekmekte. Bu eklentiler aslında bir yazılım projesinde her kısımda ortak olarak kullanılabilecek ilgileri temsil ediyor. Log’lama gibi…Ya da belli bir değerleri kontrol eden validasyonlar gibi…Aşağıdaki örnek bu iki kavram için yeterli olur umarım.

    [Controller]
    public class Person : ContextBoundObject
    {
        private int _age = 0;
        private string _name = "";

        public string Name { get { return _name; } }

        public Person(string name) : base() { _name = name; }

        public int Age
        {

            get
            {
                return _age;
            }
            [Logger]//Age özelliğine değer ataması yapmadan önce yine kayıt tutuyoruz
            [AgeValidation(150)]//Atanacak değerin kontrolünü AgeValidation ile kontrol ediyoruz
            set                 //Bu noktada bir insanın 150 yaşından büyük olamayacağını düşünüyoruz.
            {
                _age = value;
            }
        }

        //DoSomething metodu çağrılmadan önce metod ile ilgili kayıt tutuyoruz...
        [Logger]
        public string DoSomething()
        {

            string logMessage = "Person sınıfının DoSomething() methodu çalıştı";
            Console.WriteLine(logMessage);

            return "";
        }

        //DoAnotherthing metodu çağrılmadan önce yine kayıt tutuyoruz.
        //Bu sefer metodun 2 tane parametresi olduğuna dikkat edelim.
        [Logger]
        public void DoAnotherThing(int parameter1, string parameter2)
        {
            Console.WriteLine("Person sınıfının DoAnotherThing() methodu çalıştı");
        }

    }

Aşağıdaki gibi basit bir konsol uygulaması ile Person sınıfımızı kullanabiliriz. Dikkat edersiniz ki herhangi ekstra bir ilgi yok.

    class Program
    {
        static void Main(string[] args)
        {

            Person arda = new Person("Arda Çetinkaya");
            arda.Age = 16;
            arda.DoSomething();
            arda.DoAnotherThing(5, "Test parametresi");

            Console.ReadLine();

        }
    }

Çalıştırdığımız zaman bu kodu, aşağıdaki gibi bir çıktı alıyor olacağız. Çıktıyı kontrol ettiğimizde metod çağrımlarından önce ilgilerin çalıştığını göreceğiz.

Uygulamada küçük bir deşiklik yaparak, başka bir çıktıyı da görelim isterseniz. Bunun için aşağıdaki Person sınıfındaki Age özelliğine 200 yazdığımızda programın çıktısı aşağıdaki gibi olacaktır ve yarattığımız AgeValidation ilgisine takılıp Exception fırlatacaktır.

Bu yoğun kodlar içerisinde umarım çok kaybolmamışınızdır ve biraz da olsa bazı şeyleri anlamaya yardımcı olmuştur umarım bu yazı…Ama henüz bitmedi…(: Bir küçük örnek ile AOP biraz daha iyi anlayacağız. Hatırlarsanız önce ki yazılarda nesnelerin bulunduğu duruma göre farklı özellikler kazanabileceğini söylemiştim. Aşağıdaki örnekte buna örnek veriyor olacağım.

    //Car adı altında arabayı simule eden bir nesnemiz var
    //Aldığı Person tipinde ki parametre ile Drive() metodu
    //sınıfın içeriğini oluşturuyor.
    [Controller]
    public class Car : ContextBoundObject
    {
        //Dikkat ederseniz CanDrive() Aspect'i ile parametrenin
        //bu metod için uygun olup olmadığını kontrol ediyoruz.
        //18 yaşını doldurmuş olmak şeklindeki bir iş kuralını
        //bu şekilde uygulayabiliriz.
        //Ama bildiğiniz üzere bu iş kuralı çeşitli ülkelerde
        //değişik bir şekilde çalışır.Bunun için de aşağıdaki
        //sınıfa göz atmakta fayda var...
        public virtual void Drive([CanDrive(18)]Person driver)
        {

            Console.WriteLine("Bas gaza...");
        }
    }

    //Car'dan türeyen yeni bir sınıfımız var. Amerikan arabasını
    //temsil eden bu sınıf türediği sınıfın Drive() metodunu eziyor.
    public class AmericanCar : Car
    {
        //Burada dikkat edecek olursanız CanDrive() Aspect'inin aldığı
        //değer 16...Malum ABD'de araba kullanabilme yaşı 16...
        public override void Drive([CanDrive(16)]Person driver)
        {

            Console.WriteLine("Amerika'da 16 yaşında araba kullanılabiliyor...Bas gaza...");
        }
    }

Yukarıdaki nesneleri canlandırabilecek şekilde konsol uygulamamızı günceliyor ve daha sonra çalıştırıyoruz…

    class Program
    {
        static void Main(string[] args)
        {

            Person arda = new Person("Arda Çetinkaya");
            arda.Age = 17;
            arda.DoSomething();
            arda.DoAnotherThing(5, "Test parametresi");

            AmericanCar cadillac = new AmericanCar();
            cadillac.Drive(arda);

            Car anadol = new Car();
            anadol.Drive(arda);

            Console.ReadLine();

        }
    }

Dikkat ederseniz anadol adındaki değişkenimizin Drive() metoduna kadar sorunsuz çalışacaktır. cadillac tipindeki değişkenin Drive() metoduna parametre olarak verdiğimiz nesnemiz, Drive() metodu için gerekli ön şartı sağladığından onda bir sorun olmadığının altını çizmek isterim. Bu örnekte nesnelerin bulundukları duruma göre sahip oldukları Aspect’lerin değişebileceğini gördük. 17 yaşındaki bir insan Türkiye’de araba kullanamazken, ABD’de araba kullanabilir. Ama insan özellikleri aynıdır (: Bu şekilde nesnelerin özelliklerinin değişebileceği sistemlerde AOP yaklaşımlarını kullanmak, sistem içerisinde ki karmaşıklığı minimuma indirecektir.

Neyse çok daha fazla saçmalamadan bitiriyorum. Umarım bazı şeyler biraz daha netleşmiştir. Biraz karmaşık bir konu ve aslında daha çok konuşacak şey var. Burada bahsetmiş olduğum kodların sadece bir örnek olduğu lütfen aklınızdan çıkarmayın. Geliştirin,hatta geliştirirken benle de paylaşırsanız sevinirim. Bir de .NET tarafında şu anda tam olarak bir AOP desteğinin olmadığı hatırlatmak isterim. Ama .NET’de AOP yaklaşımlarını uygulayabileceğiniz alt yapıyı biraz olsun yaratabileceğinizi unutmayın. Unity’i bu bağlamda kurcalamakta fayda olabilir. Tam olmasa da yaklaşımları AOP ile hemen hemen aynı…

Şimdilik bu kadar…Lütfen her türlü düşünce ve sorunuzu paylaşmaktan çekinmeyin…

Edit: Bu yazıda geçen örnek kodları buradan indirebilirsiniz…

Bu yazı için .NET Framework içerisinde bulunan ContextBoundObject sınıfından faydalanacağız. Bu noktada .NET Framework’de direk olarak bir AOP desteği olmadığı hatırlatmak isterim. Sadece .NET Framework’ün bize sunduğu sınıf ve metodlar ile bu yaklaşımı biraz olsun oluşturmaya ve daha iyi anlamaya çalışıyor olacağız.

Öncelikle ContextBoundObject sınıfının ne olduğu kısaca anlatmaya çalışacağım. Biraz sonra aşağıda vereceğim örneğin daha anlaşılır olması adına gerekli olacağına inanıyorum.

Bir içeriğe(context) ve bu içeriğin kurallarına bağlı olan nesnelere, içeriğe bağlı nesneler deniyor, yani context-bound objects. Peki içerik ne? Belli özelliklerin ve kullanım kurallarının kullanıldığı, nesnelerin bir araya geldiği oluşumlar diyebiliriz. Yani bir nesne bir içeriğe dahil olduğu ya da bağlandığı zaman o içeriğin özelliklerini ve kurallarını uygulamak durumunda oluyor. Bir nesne yaratılırken var olan bir içeriğe ya da meta-data’sında bulunan Attribute’lara(özelliklere) göre yaratılacak yeni bir içeriğe bağlanabilir. Burada ki özellik kavramı da ContextAttribute sınıfı ile .NET Framework içerisinde tanımlanmakta. Biraz daha geniş ve ayrıntılı bilgiyi buradaki MSDN içeriğinden öğrenebilirsiniz. Ama bizim için şimdilik bu kadarı yeterli olacak.

Yukarıda özetlemeye çalıştığım ContextBoundObject sınıfı ile oluşturacağımız nesnelerin bir içerik dahilinde oluşmasını sağlayacağız. Daha sonra bu içerik içerisinde ki kurallara göre kesişen ilgileri kontrollü bir şekilde yönetebileceğiz. Bunu nesneleri yaratırken, tam yaratmadan önce bazı kontrolleri yaparak, nesnenin bir metodunu çağırırken, tam çağırmadan önce bazı kontrolleri yaparak ya da nesnenin özelliklerini değiştirirken, tam değiştirme aşamasından önce yine bazı kontroller yaparak yapacağız. Burada ki kontroller de aslında birbiri ile kesişen ilgiler olacak. Biraz karışık oldu sanırım ama kod örnekleri ile daha net anlaşılacağına inanıyorum.

Öncelikle ContextBoundObject sınıfından türeyen bir Person sınıfı yaratalım…

 public class Person : ContextBoundObject
 {
        private int _age = 0;
        public Person():base()
        {

        }
        public int Age
        {
            get
            {
                return _age;
            }

            set
            {
                _age = value;
            }
        }

        public string DoSomething()
        {
            return String.Format("Person sınıfının DoSomething methodu çalıştı");
        }
 }

Fark etmiş olduğunuz gibi ContextBoundObject’ten türemesine rağmen pek bir farklılığı yok. Bu nesnenin yaratıldığı içeriğin özelliklerini(Attribute) belirlememiz lazım ki, yaratıldığı zaman o özelliğin sağlayabileceği yöntemler ve özellikler ile nesnenin üzerinde kontroller yapabilelim. Bunun için aşağıdaki gibi bir kod bloğu ile ContextAttribute’dan türeyen bir Attribute yaratmamız lazım.

 [AttributeUsage(AttributeTargets.Class)]//Bu özelliğin uygulanabileceği kullanımı belirtiyoruz
 public class ControllerAttribute : ContextAttribute
 {
        //ContextAttribute'un ismini base sınıf sayesinde belirtiyoruz.
        public ControllerAttribute()
            : base("Kontrolcu")
        {
        }

        //IsContextOK metodunu yeniden tanımlayarak, içeriğime bağlanan
        //nesnelerin özelliklerini kontroller edebiliyoruz. Eğer belirttiğimiz
        //özellikleri var ise bu içeriğimiz için uygun oluyor. Ama yok ise
        //özellikleri nesnemize bağlamak gerekiyor.
        //IsContextOK metodu, nesneler yaratıldığı zaman ilk çalışan metod.
        //Bu metodun sonucuna göre GetPropertiesForNewContext çalışıyor.
        public override bool IsContextOK(Context ctx, System.Runtime.Remoting.Activation.IConstructionCallMessage ctorMsg)
        {
            ControllerProperty property = ctx.GetProperty("Kontrolcu") as ControllerProperty;
            if (property == null)
                return false;
            return true;
        }

        //GetPropertiesForNewContext metodunu yeniden tanımlayarak,
        //içeriğimize özellikler ekliyoruz.
        //Bu özellikler içeriğe bağlanan nesnelerin uygulaması gereken kurallar
        //ve kontrolleri temsil ediyor.
        public override void GetPropertiesForNewContext(System.Runtime.Remoting.Activation.IConstructionCallMessage ctorMsg)
        {
            //Burada eklediğimiz ControllerProperty'si kendi yarattığımız,
            //IContextProperty arayüzünden yaratılan bir özellik.
            //Bunun gibi bir çok özellik yaratıp,içeriğimize ekleyebiliriz.
            ctorMsg.ContextProperties.Add(new ControllerProperty());
        }
}

Bu Attribute’u yaratırken dikkat ederseniz ControllerProperty şeklinde bir sınıfı özellik olarak ekledik. Bu sınıf, bizim nesnelerimizin içerik dahilinde uygulaması gereken bir özelliği belirtiyor. IContextProperty arayüzünden türeterek istediğimiz gibi yaratabiliriz. Bu arayüzden yarattığımız zaman aşağıdaki gibi tanımlamamız gereken metodlarımız olacak tabi ki…Ben kavram olarak kontrol eden şeklinde açıklamalarda bulunduğum için adını ControllerProperty olarak tanımladım.

public class ControllerProperty : IContextProperty
 {
        //Freeze metodu, özelliğin içeriği dondurabilmesini yönetiyor.
        //İçeriği dondurursak eğer yeni özellik eklemek ya da içerikten
        //özellik çıkarmak mümkün olmayacaktır.
        //Bu içeriklerin sınırlarını belirlemek adına kullanabileceğimiz
        //bir yaklaşım olabilir.Ama şimdiliu bu metod içerisinde
        //herhangi bir işlem yapmıyoruz.
        public void Freeze(Context newContext)
        {

        }

        //IsNewContextOK metodu bu özelliğin içerik için uygun olup olmadığını
        //kontrol eden bir metod. İçeriğe sadece kendi arayüzlerimizden oluşan
        //özellikler eklemek istediğimiz de örneğin, bu metod ile eklenen özelliğin
        // uygun olup olmadığını kontrol edebiliriz.Uygun ise true,değil ise false
        //şeklinde bir geri dönüş, bu özelliğin içeriğe eklenmesinde etki edecektir.
        public bool IsNewContextOK(Context newCtx)
        {
            return true;
        }

        //Özelliğimizin ismi.
        public string Name
        {
            get { return "Kontrolcu"; }
        }
 }

İçerik içerisinde ki özelliğimizi de yukarıda ki gibi tanımladıktan sonra bu özelliğin, içeriğe bağlanan nesneler tarafından uygulanabilir olmasına geldi sıra şimdi. Context’e(içerik) bağlanan nesneleri kullanırken, bu kullanımlardan önce araya girmemiz gerekmekte. Bunun için özelliklerimize mesaj alıcısı diyebileceğimiz alıcılar eklememiz lazım ki, içeriğe bağlanan nesneleri alabilen bir yapımız olsun.

Bunun için IContributeObjectSink arayüzünü ControllerProperty sınıfımıza eklememiz lazım. Bu arayüz .NET Framework içerisinde olan bir arayüz. Bu noktada bu sınıfın isminde geçen Sink kelimesinin lavabo olarak değil de alıcı olarak kullanıldığı hatırlatmak isterim. Çünkü birazdan benzer isimlere sahip olan sınıfları kullanıyor olacağız. (:

IContributeObjectSink arayüzünü sınıfımıza eklediğimiz zaman GetObjectSink() metodunu da tanımlamamız gerekiyor.

public class ControllerProperty : IContextProperty, IContributeObjectSink
{

        //Freeze metodu, özelliğin içeriği dondurabilmesini yönetiyor.
        //İçeriği dondurursak eğer yeni özellik eklemek ya da içerikten
        //özellik çıkarmak mümkün olmayacaktır.
        //Bu içeriklerin sınırlarını belirlemek adına kullanabileceğimiz
        //bir yaklaşım olabilir.Ama şimdiliu bu metod içerisinde
        //herhangi bir işlem yapmıyoruz.
        public void Freeze(Context newContext)
        {

        }

        //IsNewContextOK metodu bu özelliğin içerik için uygun olup olmadığını
        //kontrol eden bir metod. İçeriğe sadece kendi arayüzlerimizden oluşan
        //özellikler eklemek istediğimiz de örneğin, bu metod ile eklenen özelliğin
        // uygun olup olmadığını kontrol edebiliriz.Uygun ise true,değil ise false
        //şeklinde bir geri dönüş, bu özelliğin içeriğe eklenmesinde etki edecektir.
        public bool IsNewContextOK(Context newCtx)
        {
            return true;
        }

        //Özelliğimizin ismi.
        public string Name
        {
            get { return "Kontrolcu"; }
        }

        //IContributeObjectSink arayüzden gelen bu metod ile yeni bir alıcı yaratıyoruz.
        //Bu alıcı içeriğe bağlanan nesnelerin çağırımlarında çalışıyor olacak.
        //Burada Control isminde,IMessageSink(mesaj alıcısı) arayüzünden yaratılan
        //bir sınıfı metodun dönüş değeri olarak tanımlıyoruz.
        public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink)
        {
            return new Control(nextSink);
        }
}

Bu metod eklemesinde dikkatinizi çeken bir sınıf olacaktır. Control sınıfı bu örnek için yarattığım bir sınıf. IMessageSink arayüzünden yaratılan bir sınıf. Bu arayüz ile ilgili ayrıntılı bilgileri MSDN’den bakabilirsiniz. Bu arayüzün zorunlu kıldığı metodları tanımlamamız gerekmekte yine.

public class Control : IMessageSink
{

        private IMessageSink _messageSink;

        //İçeriğe dahil olan nesneler üzerinde kontroller yapabileceğimiz
        //nesneyi yaratmak için kullanacağımız yapıcı metodu,
        //alıcısını alacak şekilde tanımlıyoruz.
        public Control(IMessageSink sink)
        {
            _messageSink = sink;
        }

        //SyncProcessMessage metodu gelen alıcı mesaj aldığı zaman
        //çalışan bir metod. Bu metod ile alıcıya mesaj geldiği zaman
        //çeşitli kontrollerin yapılmasını sağlayabiliriz.
        //Burada mesaj diye tanımladığım operasyon aslında içeriğe dahil olan
        //nesnenin bir metodunun çalışması ya da bir özelliğinin çağrılması.
        //Bu örnekte şimdilik konsola bir mesaj yazdırıyor olacağız.
        public IMessage SyncProcessMessage(IMessage msg)
        {
            Console.WriteLine("Heyyy, önce bir dur bakalım...");
            return _messageSink.SyncProcessMessage(msg);
        }

        //AsyncProcessMessage metodu da SyncProcessMessage metodu ile aynı.
        //Sadece asenkron çağırımlarda çalışan versiyonu
        public IMessageCtrl AsyncProcessMessage(IMessage msg,
           IMessageSink replySink)
        {
            Console.WriteLine("Heyyy, önce bir dur bakalım...");
            return _messageSink.AsyncProcessMessage(msg, replySink);
        }

        //NextSink ile mesaj alıcımızı, içerik içerisinde ki diğer özelliklere
        //iletiyoruz. Bu sayede içerik içersinde bir sonraki özelliğe
        //geçiyoruz.
        public IMessageSink NextSink
        {
            get
            {
                return _messageSink;
            }
        }
}

Şimdi bütün bunları yaptıktan sonra ilk başta yaratmış olduğumuz Person sınıfına hangi içerik dahilinde olacağını belirtmemiz lazım. Bunun içinde ControllerAttribute’unu Person sınıfının hemen üstünde tanımlamamız gerekecek.

[Controller]
public class Person : ContextBoundObject
{
        private int _age = 0;
        public Person():base()
        {

        }
        public int Age
        {

            get
            {
                return _age;
            }

            set
            {
                _age = value;
            }
        }

        public string DoSomething()
        {
            return String.Format("Person sınıfının DoSomething methodu çalıştı");
        }
}

Bu tanımlamayı da yaptığımız zaman artık geriye bu Person sınıfımızı çağırabilecek bir basit test uygulaması yapmak kalıyor. Bunun içinde sanırım aşağıda ki gibi bir konsole uygulaması yeterli olacaktır.

class Program
    {
        static void Main(string[] args)
        {

            Person arda = new Person();
            Console.WriteLine("--Birazdan arda.Age özelliğine değer atanacak");
            arda.Age = 100;
            Console.WriteLine("--arda.Age özelliğine değer atandı");
            Console.WriteLine("--Birazdan arda.Age özelliği konsola yazılacak");
            Console.WriteLine(arda.Age);
            Console.WriteLine("--arda.Age özelliğini konsola yazıldı");
            Console.WriteLine("--Birazdan arda.DoSomething() metodu çalışacak");
            Console.WriteLine(arda.DoSomething());
            Console.WriteLine("--arda.DoSomething() metodu çalıştı");
            Console.ReadLine();

        }
    }

Bu programı çalıştırmadan önce isterseniz kısa bir özet geçelim ve neler yaptık bir bakalım.

• ContextBoundObject sınıfından türeyen belli bir içeriğe bağlanacak bir sınıf yarattık.
• Hangi içeriğe ekleneceğini ControllerAttribute şeklinde, ContextAttribute sınıfından türeyen bir sınıf yaratarak belirledik.
• Bu ControllerAttribute ile içeriğimizin özelliklerini ekledik.
• Özellik olarak ControllerProperty şeklinde, IContextProperty ve IContributeObjectSink arayüzlerinden yaratılan bir sınıf oluşturduk.
• Bu özelliğin mesaj alması(nesneleri çağırma işlemi için) için IMessageSink şeklinde bir alıcı kullanmasını sağladık.
• Control alıcısı ile nesnelerin çağırımları aşamasına müdahale etmek için gerekli metodların içini doldurduk.

Bu kısa özetten sonra isterseniz uygulamamızı çalıştıralım. Çalıştırdığımız zaman aşağıdaki gibi bir çıktımız olacaktır.

Uygulamanın kodları ile çıktımızı karşılaştırdığımızda, bir içeriğe bağlı olan nesnemizin çeşitli özelliklerine bazı operasyonlar yapmadan önce araya girmiş olduğumuza dikkat çekmek isterim. Aynı şekilde metod çalıştırmadan öncede araya girdiğimizi söyleyebilirim.

Bu noktada AOP kavramını daha iyi anlayabilmek adına bir sonraki yazıda oluşturacağımız ilgileri ve “Aspect”leri(görünüş) ayırabilmek adına bir alt yapı oluşturmuş olduk. Bir sonraki yazı da Person sınıfı üzerinde kullanacağımız ilgileri(örnek:loglama,hata yakalama) yaratarak bu yapı dahilinde nasıl kullanabileceğimizi anlatmaya çalışacağım.

Umarım açıklayıcı ve anlaşılır bir yazı olmuştur. Her türlü düşünce ve sorunuzu lütfen paylaşmaktan çekinmeyin. Bir sonraki yazıda görüşmek üzere…

Bir önceki yazımda, AOP’in birbiri ile kesişen ilgileri ayırmak ve basitleştirmek için kullanabileceğimiz bir yaklaşım olduğunu söylemiştim hatırlarsanız. Ve hatırlarsanız bir tane de pseudo kodu ile bir insanın yaşam sürecini örneklendirmeye çalışmıştım. Yaşam döngüsünde birbiri ile kesişen iglileri görmüştük. Biraz daha anlaşılır olması adına daha sık karşımıza çıkan problemleri bu yazıda ele almaya çalışacağım.Bu sayede AOP’ı ve hangi sorunlara çözüm sunduğunu anlamak daha kolay olacaktır. İlk olarak aşağıdaki metod ile başlayalım.

public ResultSet SearchCustomer(string username, string customerName,string customerSurname)
 {
              try
            {
                if (!IsExists(username))
                    throw new DoesNotExistsException();

                if (!HasAccess(username))
                    throw new AccessDeniedException();

                Logger.Write("Search will be done with CustomerName:{0} CustomerSurname:{1}",customerName,customerSurname);

                ResultSet results = Database.Search(customerName, customerSurname);

                Logger.Write("Search is successfully done");

                return results;
            }
            catch (Exception ex)
            {

                Logger.Write(ex.Message, "ERROR");
            }

            return null;
 }

Müşteri adı ve soyadına göre arama yapan, arama yaparken bazı kontrolleri gerçekleştiren bir metod var yukarıda. Arama yapan kullanıcıyı kontrol eden,daha sonra bu kullanıcının durumuna göre başka bir kontrol yapan, kayıt eden ve sonra arama operasyonunu gerçekleştiren ve bir hata olursa yine bunu kayıt altına alan bir metod dikkat ederseniz. Bir çok farklı ilgi aslında iç içe…Daha doğrusu kesişiyor. Bu tarz ilgiler aslında bir çok yazılım projesinde önemli yer kaplıyor. Bu tarz ilgilerin birden fazla metod içerisinde kullanıldığını düşünün…Search() metodunun içerisinde yapılan kontrollerin, aynı gereksinimlerden dolayı SaveCustomer() metodunda da yapılması gerektiğinde birbirini tekrarlayan, bir değişiklikte bir çok yeri etkileyen kod parçaları ortaya çıkacaktır. Bunlar zaman zaman soruna, zaman zaman da karmaşıklığa yol açar bildiğiniz üzere…Ve bu şekilde iç içe girmiş karmaşıklıkları yönetmek oldukça zor olacaktır.

Bu karmaşıklıklar, nesnelerin yazılımın yaşam süresindeki durumlarından dolayı oluşacak karmaşıklık ile iç içe girdimi tam bir çıkmaza dönüşür.Bu tarz problemleri çözmek için, mesela metodları çağırırken, nesneleri yaratırken veya değerlere atama yaparken kendi ilgilerini ayırmak kısmen de olsa yeterli olacaktır. Yukarıdaki Search metodundan önce, yani daha metod çağrımı yapılmadan kullanıcı kontrolleri yapılsa,log işlemi gerçekleşse,sonra metod çağrımı yapılsa bir şekilde ilgiler birbirinden ayrılmış olacak. Bu ilgileri ayırdığımız zaman benzer ihtiyaçları olan metodlarda da bu ilgileri kullanabilmek mümkün olacaktır. Bu ilgileri ayırabildiğimiz zaman, kesişen ilgilerden dolayı oluşabilecek problemleri yok edebiliriz.

Başka bir sorun ise bu ilgilerin yazılımın yaşam süresi içerisinde ortaya çıkması. Mesela aşağıdaki kod parçasına bakalım. Person diye bir sınıfımız var. CanDrive diye bir metodu yaş ve ehliyet değerlerine göre sonuç dönüyor…Person sınıfımızdan yaratılan nesnemiz, uygulama içerisinde Türkiye’de olan bir nesne şeklinde çalışıyorsa CanDrive() metodunda sorun olmayacaktır. Ancak Person sınıfının nesnesi ABD içeriğinde oluştuğunu düşündüğümüzde CanDrive() metodu yanlış çalışacaktır. Çünkü ABD’de araba kullanabilmek için 18 yaşını beklemeye gerek yok bildiğiniz üzere…

    public class Person
    {
        public bool CanDrive()
        {
            if (_age >= 18 && HasLicense)
            {
                return true;
            }

            return false;
        }
    }

Burada sorun bir eylem gerçekleştirmek için kullanılan metodun içerisinde bazı kurallarında metodun içerisinde yer alması. Person sınıfdan bir nesne yaratan kişi, bu kuralları bilemeyeceği için bu nesneyi istediği gibi kullanamayacktır. Bunu çözmek için bu tarz kuralları dışarıya verebiliyor olmak sorunumuzu çözecektir.

Aşağıdaki gibi bir uygulama çözüm yollarından bir tanesine örnek olabilir. Bu şekilde CanDrive bilgisine ulaşmadan önce yaş kontrolünü yapmak mümkün olacaktır. Bu kontrolün nasıl yapıldığı kendi içinde saklandığından CanDrive ilgisi ile bir kesişimi kalmamış oluyor. Asp.Net MVC’de ki Data Annotation Validators kavramını hatırlamak belki sorunu ve çözümünün anlaşılmasında biraz daha yardımcı olur. Oradaki yaklaşımda AOP yaklaşımı ile aynı…

    public class Person
    {
        private bool _canDrive=false;
        public bool CanDrive {

            [Age(Min = 18)]
            get {
                return _canDrive;
            }
        }
    }

Bu yazımda AOP’nın neden ihtiyaç olabileceğini, hangi sorunlara çözüm sunduğunu anlatmaya çalıştım. Biraz sorunlara çözümlerinden çok ağırlık verdiğimi biliyorum…Sorunları anlamanın, çözüm üretmek adına önemli olduğunu düşündüğüm için araya böyle bir yazı daha sıkıştırdım. Ama bir sonra ki yazımda çözümlere çok daha fazla ağırlık vereceğim ve evet kod yazacağım…(:

AOP’nın tam olarak uygulanması için sınıfların,methodların metadata seviyesinde bazı bilgileri dışarıya vermesi ve dışarıdan da bu bilgileri dinamik olarak alabilmesi lazım. Bu bağlamda compiler(derleme) aşamasında bazı değişikliklerin olması da gerekmekte. Compile ve link aşamasına biraz müdahale edebilecek konuma geldiğimizde AOP yaklaşımını daha kolay uygulayabilir ve anlayabilir hale geleceğimizi düşünüyorum. Neyse şimdilik bu kadar…Bu konu ile ilgili bir sonra ki yazıda görüşmek üzere…
Tekrardan hatırlatmak isterim ki her türlü sorunuzu ve düşüncenizi çekinmeden paylaşabilirsiniz…

Peki nedir bu AOP? AOP‘ı basitçe Türkçe’ye çevirirsek bazı şeyleri anlamak adına belki yardımcı olur…Bu bağlamda “Görünüşe Yönelik Programlama” benim en tercih ettiğim bir çeviri oluyor. AOP, yazılımdaki birbiri ile kesişen ilgileri(cross-cutting concerns) ve bu ilgilerin oluşturduğu karmaşıklığı çözmek adına ortaya çıkmış bir method aslında.

Yazılım geliştirken, en zorlayıcı kısım genellikle birbiri ile kesişen ilgileri basitleştirmektir. Neden böyle bir basitleştirme içerisinde olmaya gerek var ki şeklinde bir soru sorabilirsiniz… Geliştirdiğimiz uygulamaların yaşam süresinde oluşabilecek, yeni gereksinimleri, sorunları daha kolay yönetebilmek adına birbiri ile kesişen ilgileri en basit halde ele almamız gerekir…Haa yok ben bir kere yazacağım,çalışacak, sonra bir daha dokunmayacağım şeklinde bir uygulama geliştirmekteyseniz bunlara çok da kafa yormaya gerek yok açıkcası.

AOP, az önce bahsettiğim birbiri ile kesişen ilgileri basitleştirmek ve hatta ayırmak adına kullanılabilecek bir yöntem. Hemen bu noktada da OOP’de de bu tarz şeyleri yapabileceğimiz yöntemler var şeklinde düşünebilirsiniz…Doğrudur,var…Ancak zaman zaman yeterli olamıyor ne yazık ki…Ya da bazı şeyleri daha karmaşıklaştırıyor…Bu noktada “zaman” kelimelerinin altını çizmekte fayda var sanırım. Çünkü bu konuda AOP’ı düşünmeye sebep olan, OOP’den farklı yönlerini ortaya çıkaran kavram “zaman” kavramı…AOP, yazılımın yaşam süresi boyunca oluşabilecek ilgilerin bir biri ile kesişmesini ve karmaşıklığa yol açmasını engellemek adına OOP’den farklılaşıyor. Biraz daha teknik olarak açıklamak gerekirse, bir uygulamanın run-time süresinde ortaya çıkabilecek ilgileri ayırmak açısından farklılaşıyor diyebiliriz. AOP’i yazımın başında “Görünüşe Yönelik Programlama” şeklinde çevirmeyi tercih etmiştim. Görünüş olarak anlamlandırdığım kavram, uygulamanın kendisinin ya da içerisinde ki nesnelerin durumları diyebilirim.

Biraz örnek ile daha net bir şekilde anlaşılacağını düşünmekteyim…Mesela standart bir örnek olarak “İnsan”ı ele alalım yapmaya. Çok tozla gaz bulutu kısmına gitmeden, her insanın ilk başta bir bebek olduğu döneme gidelim. Yani insanın görünümün bir bebek olduğu zamana…Bir bebek yürüme eyleminin yerine emekler, konuşamaz, garip sesler çıkarır…Zamanla insanın durumu değişir…Büyür,konuşmaya başlar, yürür…Görünüşü değişir…Daha sonra biraz daha büyür…Okula başlar,sosyal hayatı oluşur…Lise,üniversite derken iş hayatı…Bütün bu farklı dönemlerde, farklı görünüşlerde olur. Bu görünüşlerin sağladığı ya da sebep olduğu yeni,farklı ama bir biri ile kesişebilen ilgileri ortaya çıkar. Mesela liseye giden bir öğrenci, aynı zamanda basketbol kursuna gider. İş hayatı olduğu döneme geldiğimizde, iş yerinin vermiş olduğu görevlerden sorumluyken aynı zamanda sosyal hayatında ki ilişkilerden sorumludur.Haftada 3 kere arkadaşlarıyla buluşur,3 kere spor yapar falan filan…Biraz daha yaşlanınca, görünümü yine değişir…Farklı ilgiler ortaya çıkar…Ama yine insandır…Ehliyet kimliği ile şöför olur, TC kimliği ile hastanede hasta olur…Ama hep insandır…Şimdi bunun basitçe bir kodunu yazmaya çalışalım…

public class Insan
    {
        int yas = 0;
        public Insan()
        {
            if (yas == 0)
            {
                Emekle();
                Konus(false);
            }

            yas++;
            //Bir sürü başka şey olabilir zamanla...
            //..
            //.
            yas++;
            if (yas > 2)
            {
                Yuru();
                Konus(true);
            }

            yas++;
            if (yas > 6)
            {
                OkulaGit();
                SosyalHayatOlustur();
            }

            yas++;

            if (yas > 25)
            {
                IseGit();
                if (EhliyetVarMi())
                    ArabaSur();
                if (HastaMi() && SigortaVarmi())
                    DoktoraGit();
            }
            ..........
            ....
            ..
            ...
        }
    }

Fark edeceğiniz gibi bu basir pseudo kodunda bile bir çok karışıklık, birbiri içersine geçmiş ilgi mevcut. Bu nesnenin yaşam süresi boyunca bunlar gibi bir şey farklı ilgi ortaya çıkabilir ve birbirlerini etkileyebilir. İşte bu ilgileri ayırabilmek adına AOP methodları karşımıza çıkıyor.

Bu tarz birbiri ile kesişen ilgileri ayırmak mevcut compiler yaklaşımı ile biraz zor aslında. Çünkü zaman içerisinde ortaya çıkabilecek bu ilgileri dinamik olarak birbirleri ile ilişkilendirmek ya da ayırmak biraz zor. Ama gelişen yazılım geliştirme metodları ve derleyiciler ile bu tarz yaklaşımları daha kolay uygulayabilir hale geleceğiz. Bu noktada AOP geliştirmesi yapamıyoruz gibi bir şey anlaşılmasın ama…OOP yaklaşımı ile de AOP’in çözmeye çalıştığı sorunları, AOP yaklaşımı ile çözmek mümkün. .NET tarafında olsun, Java tarafında olsun ve hatta C++ tarafında olsun AOP yöntemlerini uygulamak mümkün. .NET tarafında AOP yaklaşımı uygulayabileceğimiz yöntemler ve çeşitli sınıflar mevcut. Attribute‘ları kullanarak ya da ContextBoundObject sınıfını kullanarak benzer yaklaşımları yapmak mümkün. İlerleyen yazılarımda nasıl yapacağımız konusunda daha geniş örnekler vermeye çalışacağım. Umarım AOP’in ne olduğu ve niçin ihtiyaç duyabileceğimiz sorularına biraz olsun cevap verebilmişimdir. Her türlü soru ve düşüncelerinizi çekinmeden paylaşabilirsiniz…Bir sonraki yazıda görüşmek üzere…

Ayrıca ayrıntılı bilgi ve dökümantasyon için de MSDN sayfasına göz atmanızı tavsiye ederim.

Aslında evet ya da hayır şeklinde cevabı olan bir soru değil bu. Ya da bu şekilde cevaplanması gereken bir soru değil. Bu sorunun cevabını irdelemeden önce, neden böyle bir soru sorup, ortamı geriyoruz önce bunu anlayalım…
Bu soruyu sormamızın amacı, önümüze çıkacak olan karmaşık problemleri çözmek için nasıl bir yol izleyeceğimizi kestirebilmek. Bir yazılımın karmaşıklığını düşünmek, geliştirme sürecinde ortaya çıkabilecek, planda olmayan engelleri ortaya çıkarmak adına oldukça faydalıdır.

Neden bu soruya cevap aradımızı anladıktan sonra, cevabını bulmak daha kolay olacaktır. Yazılım kavramı, yeri geldiğinde oldukça karmaşık, içinden çıkması zor, bir o kadar da sıkıntılı olabilir. Ama aynı şekilde çok kolay da olabilir. Bunların bir kaç nedeni var. Birazdan bu nedenlere geçiyor olacağım.

Yazılımda karmaşıklık dendiğinde genelde, sistemi oluşturan bileşenlerin bir birleri olan ilişkileri ya da bileşenlerin kendi içerisinde çağırdıkları diğer alt bileşenlerin sayısı gibi şeyler hesaplanır. Bunun için çeşitli formüller ve yaklaşımlar var, aslında tamamen ayrı bir başlık altında incelenmesi daha doğrudur. Ama biraz daha yukarıdan bakıp karmaşıklığı daha net görmeye çalışacağız.

Yazılım da karmaşıklığa neden olabilecek faktörler “Gereksinimler”,”Teknoloji” ve “İnsan” olarak 3 ayrı başlıkta toplanabilir.

Gereksinimler

Karmaşıklığa yol açabilecek en büyük etken, yazılıma ihtiyaç duyulan, yazılımın yaşamsal döngüsünü başlatan “Gereksinimler”dir. Gereksinimlerden dolayı, teknik anlamda oldukça kolay bir operasyon, oldukça karmaşık bir hal alabilir. Aslında bu karmaşıklık bazen kaçınılmaz olup, diğer başka faktörler ile minimum seviye indirilebilir.
Mesela bir sisteme kayıt olma işlemini örnek olarak alalım. Sistem için ad,soyad,TC Kimlik No. ve e-mail anlamlı olsun diyelim. Oldukça basit bir şekilde sisteme bu bilgileri alan bir arayüz yapıp, bu bilgileri sistem altına kayıt edebiliriz. Şimdi çeşitli ihtiyaçlardan dolayı, sistemi tekrar ele alalım…Kayıt işlemi sırasında TC Kimlik No. geçerli bir numara olduğundan emin olmamız gerekmekte. Ayrıca e-mail adresinin formatının geçerli bir e-mail adresi olduğunun da kontrolü gerekmekte. Ek olarak, e-mail adresinin gerçekten karşılığının olduğunu kayıt sırasında teyit etmemiz gerekmekte. Görmüş olduğunuz gibi bir kaç basit gereksinimden dolayı, ilk baştaki kayıt işlemi biraz daha karmaşıklaştı. Aynı anda 500.000 kişinin veri girişi yapabileceği bir gereksinim oluştu diyelim sonra da…Bir de farklı arayüz ortamlarında(mobil,web…vs.) giriş işleminin yapılması gerektiğini de düşünelim. İlk baştaki kayıt işlemi, son haline göre oldukça karmaşık bir hal aldı.

Teknoloji

Teknoloji kavramı, yazılımın yaşam sürecinde beyin görevini gören bir kavramdır. İnsanoğlu beynin karmaşıklığını çözememişken, teknoloji de yazılımın karmaşıklığına büyük etken sağlar aslında. Kullanılan teknoloji, yazılımın karmaşıklığına ayrıca yol da verir. Yani X teknolojisi ile başladığınız bir yazılım, gereksinimlerden dolayı Y teknolojisinden de az biraz kullanmanızı gerektirebilir. Bundan dolayı, yazılımınızın karmaşıklığı doğal olarak artmış olur. Yukarıda bahsetmiş olduğum kayıt örneğini bu açıdan yine ele alalım. İlk başta basit bir masaüstü uygulaması ile .NET Framework kullanarak kolayca kayıt işlemini yapabiliyorkan, aynı uygulamayı kiosk tarzı ya da belli bir amaç için çalışan cihaz üzerinde çalıştırmak istediğimizde C++ ile çok daha kolay yapabiliyor olabiliriz. Ya da milyonlarca kişinin sahip olduğu cep telefonlarında Java ile cep telefonlarına uygulama yazmak işimizi daha kolaylaştıracaktır. Bundan dolayı yazılım geliştirme sürecinde kullanılacak teknoloji, karmaşıklık adına oldukça önemlidir.

İnsan

Yazılımı kullanıcak ve geliştirecek kişi yazılımın yaşam sürecine direk olarak etki eder. Bu da zaman içerisinde yazılımın karmaşıklığını etkileri. Önce kullanıcı açısından bakalım. Yazılımı kullanacak olan kullanıcı belli ihtiyaçlarını karşılamak için yazılıma ihtiyaç duymuştur mutlaka. Genellikle bu ihtiyaçlarını önceden bir şekilde karşılayabildiği için, belli alışkanlıkları vardır. İşte bu alışkanlıklar, kullanıcının ne istediğinde önemli etken olabilmektedir. Birden fazla kullanıcı olduğundan dolayı da bu etki oldukça büyük olacaktır. Geliştirici açısından ele aldığımızda, karmaşıklık kat sayısı oldukça artabiliyor. Geliştirme sürecinde yer alacak kişilerin bilgi birikimleri, hakim oldukları teknoloji ve tecrübeleri, yazılımı ister istemez karmaşıklaştıracaktır. Bir yazılımcı, tecrübelerinden dolayı, X işini oldukça kolay yabiliyorken, aynı işi başka bir yazılımcı daha zor ama daha etkili bir şekilde yapabilir. Bu tarz yaklaşım farkları, yazılımın karmaşıklığında büyük etki yapabilir.

Başka faktörler de yazılımın karmaşıklığında etken olabilir tabi ki. Ama bu 3 kavramın en önemli ve etken olduğu kanısındayım. Ayrıca yazılımlar, doğası itibari ile mutlaka karmaşık olacaktır. Önemli olan bu karmaşıklığa yol açabilecek şeylerin farkında olup, karmaşıklığı minimuma indirmek. Neyse çok karıştırmadan,bitiriyorum bende…:) Şimdilik bu kadar…

Bir nesnenin var oluş sebebi…

Her hangi bir kavramın nesne modelini oluştururken, o kavramın ne amaçla var olduğunu asla unutmamak gerekir. Gerçekleştireceği operasyonların, o kavram dahilinde olduğunu kesinleştirmek nesne modelini ve ilgilerini oluşturmakta daha kolaylık sağlayacaktır. Matemetikte ki 4 işlemi soyutlayan bir nesneye, belli bir süre için faiz hesaplayan bir metodu da 4 işlem dahilinde olduğunu düşünerek eklemek o nesnenin karmaşıklığını artıracaktır. Farklı yerlerde farklı şekillerde var olabileceğinden tasarımsal olarak soruna yol açacaktır. Dolayısıyla nesnelerin görevlerinin çok net bir şekilde tanımlanıyor olması gerekmekte.

Bir nesnenin yaşam süresi…

Nesnelerin, bütün içerisinde ki yaşam süresini yönetebiliyor olmak çok önemlidir. Gelişen “geliştirme teknolojileri” bu sürenin yönetimini biraz olsun geliştiriciden alıyor olsa da, en azından nesnelerin yaşam sürelerinin farkında olmak bizim için çok önemli. “Object reference not set to an instance of an object”(sanırım en çok alınan hatadır) hatasını alıyor olmamız, bir bakıma da nesnelerimizin nerede, ne zaman, nasıl yaşadığının farkında olmamamızdan kaynaklanıyor diyebilirim. Nesnelerimizin, nerede, ne şekilde, ne kadar yaşayacağını ya da var olacağını çok iyi belirlememiz gerekiyor.

Bir nesnenin ilişkileri…

Nesnelerin bir birleri ile olan ilişkilerini ortaya net bir şekilde çıkarmak çok önemlidir. Bu noktada “Composition(part-of)”(Bileşim),“Aggregation(has-a)”(Kümelenme,bir araya gelme) ve “Inheritance(is-a)”(Kalıtım) kavramlarını anlıyor olmak çok önemlidir. Teorik olarak kavramlara hakim olsak bile, nesne tasarımlarında bunları uygulama konusunda zaman zaman sıkıntı çekilebiliyor. Nesneler arasında ki ilişikleri, hangi nesnenin hangi nesneye bağlı olduğunu ya da olacağını ilk başlarda kestirebiliyor olmak çok zor olsada,  bu zorluğa katlanıp çözme çabası olumlu sonuçları beraberinde getirecektir. Bu aşamada “Dependency injection”, “Inversion of control” kavramlarını da çok iyi anlıyor olmamız gerekmekte…
Bu üç başlığın yazılım tasarımı konusunda, özellikle nesne modeli oluştururken çok önemli olduğunu düşünüyorum. Şimdilik bu kadar…

Belki benden tecrübeli meslektaşlarım biraz kızacak ve hatta ne saçmalıyorsun falan diyecektir. Ama açıkcası “Design Patterns”(Tasarım kalıplarının) direk olarak mimari yaklaşımlar ile alakalı olduğunu düşünmüyorum, aslında düşünmediğim gibi, kendi tecrübelerimden,okuduklarımdan, öğrendiklerimden görüyorum da…

“Design Patterns”(Tasarım kalıpları) hakkında internette bir çok kaynak var. Çoğunda belli kod parçacıkları ile örnekler ile ne amaçla kullanacağımızı falan anlatılıyor.Süper, mükemmel…Ama erken…Daha kod yazmaya başlamadık ki…

Madem böyle kalıp falan başladık bahsetmeye, bu yazının amaçı olan “Architecture Patterns(Sytles)”’e(Mimari Kalıplara) geçelim.Çeşitli kaynaklarda mimari sitiller, bazılarında da mimari kalıplar şeklinde geçer, ama yazılımcıların bakış açısından daha kolay anlaşılacağını düşündüğüm için bende kalıp olarak kullanacağım. Önceki yazılarda da bahsettiğim ihtiyaçlar doğrultusunda şekillenecek(şekillenmesi gereken) mimarimizi, belli tecrübelerden, teknolojik açılardan ve belli limitlerden dolayı belli kalıplar dahilinde şekillendirmemiz bize yardımcı olabilir. Kurabiye yaparken kullanılan kalıplar ya da kumdan kaleler yaparken kullandığımız kovalar gibi…

Bu bağlamda, ne olduklarının çok farkında olmadığımız ama sık sık kullandığımız kavramlar ortaya çıkıyor. Mimari kalıplar…

Mimari kalıplar, geliştireceğimiz sistemlerin ya da yazılımların ihtiyaçlarımız doğrultusunda çok daha etkili çalışabilmesini sağlayacak ve mimarimizi geliştirirken bize yol gösterecek kalıplardır. Çok daha iyi anlaşılması adına aşağıdaki gibi bir liste yaparsam daha iyi olur sanırım.

• Bileşen tabanlı mimari
• Katmanlı mimari
• P2P mimari
• UI tabalı mimari
• Mesaj bazlı mimari
• Servis tabanlı mimari
• Event tabanlı mimari

Yukarıda bazı popüler mimari kalıplardan örnekler var. Daha çeşitlenebilir tabi ki. Bunları tek tek şuan için açıklamayı düşünmüyorum. Bu noktada mimari kalıpların neden önemli olduğunu anlatmak istiyorum. Mimari kalıplar, ihtiyaçlarımızı daha net bir şekilde karşılamamızda bize yol gösterir. Ayrıca ihtiyaçlarımızı karşılarken, hangi yöntemleri kullanabiliriz bunları sunar. Bu kalıpları ayrı ayrı düşünüyor olmak biraz hatalı olabilir. Direk olarak kesiştirmek de hatalı olur. Mimari tasarımı yaparken, ihtiyaçlarımızı bu kalıplar doğrultusunda çerçeveleyip tasarımımızı yapmak çok daha sağlıklı sonuçlar getirecektir. Ayrıca bu kalıpların kendi içlerindeki kanıtlanmış yöntemler, sizi bir çok şeyden kurtarıyor da olacaktır.

Son olarak tekrardan “Design Patterns”-tasarım kalıplarının, mimari tasarımla direk alakası olmadığını söylemek istiyorum. Bu karıştırmadan dolayı kavramların da karıştığını görüyorum. İlerleyen yazılarda yine bu konulardan bahsediyor olacağım…Şimdilik bu kadar…

“Software Design” ve “Software Architecture Design” iki farklı kavram aslında. Bu iki kavramın karıştırılıyor olması, mimari kavramların kaybolmasına neden oluyor ne yazık ki. Bundan dolayı “Tasarım”(Design) ve “Mimari”(Architecture) kavramlarının arasındaki sınırı çok iyi anlamamız gerekmekte. Tüm mimari yaklaşımlar aslında bir tasarımdır. Ama bu tasarım, “Yazılım Tasarımı”(Software Design) daki tasarım değil. Mimari olarak yaklaştığımız zaman, “tasarım” kavramı çok daha yukarıdan bakmamızı gerektiren bir kelime olarak karşımıza çıkıyor. Bir yazılım ya da sistemdeki bileşenlerin nasıl organize olduğu ve ilişkilendirildiği, o sisteme ya da yazılıma “Mimari” açıdan yaklaşımı gösterir. Bu bileşenlerin nasıl sınıflandırıldığı ve ayrıştığı ise “Tasarımı” olarak açıklanabilir. Biraz daha basite indirgememiz gerekirse, yazılım geliştirirken bileşenlerimizi  “sınıf”(class)’lara ayırmamız, bu “sınıf”lar arasında ilişkileri belirlememiz “tasarım” kavramının konusu. Ama bileşenlerimizin(component) nasıl ilişkilendirileceği de “mimari” kavramının konusu.

Açıkcası kendi geliştirdiğim yazılımlarda, bu iki kavramın ayrımını fark ediyor olmak geliştirme sürecini daha sağlıklı hale getiriyor.Bir yazılım geliştirmeden önce hepimizin yapmış olduğu bir tasarım mutlaka vardır. İşte bu tasarım süreci  mimari tasarıma denk geliyor aslında. Ve yazılım geliştirme sürecinde herkesinde bildiği gibi çok önemli bir yer kaplıyor. Bu süreçte dikkat edilmesi gereken bir çok önemli nokta var.Bunlardan bence en önemlilerini kendimce anlatmaya çalışacağım;

• Sınırlar: Tasarım sürecinde, geliştirmemiz gereken yazılımın ya da sistemin ihtiyaçları ve neden gerekli olduklarını kesinlikle unutmamak lazım. Ve ihtiyaçtan fazlasını düşünmememiz lazım. Açıkcası bunu sürekli yaşıyorum. İster istemez yazılımın olabildiğince geniş bir kapsamı olması, ya da “genişletilebilir” kalite özelliğinin hem tasarım hemde geliştirme sürecinde öne çıkması kötü tasarımlara yol açıyor. İş gereksinimleri dışında, tasarımı karmaşıklaştıracak etkenleri tasarıma sokmamak ve ihtiyaçlarımız doğrultusunda sınırlarımızı aşmamak lazım.
• Bileşenlerin Ayrılması: Tasarımı yaparken, bir birinden farklı tüm fonksiyonel özellikleri belli bileşenler olarak ayırmak tasarımın karmaşıklığını önleyecektir, ayrıca ihtiyaçların gerçekten karşılanabiliyor olmasının gözlemlenmesine ve bileşenlerin tek başlarına ne işe yaradıklarını da anlamaya yardımcı olacaktır.Literatürde “Separation of Concerns” olarak yer alan bu kavram, geliştirme sürecindeki tasarım kalıpları ile ne kadar önemli olduğunu zaten belli edecektir.  Dolayısıyla geliştirme sürecinde sonradan fark etmek yerine, başlangıçta bu yaklaşıma göre yapılacak tasarımlar faydalı olacaktır.
• Bileşim(Composition) ve Kalıtım(Inheritance): Bu iki kavramın çok iyi anlaşılıyor olması gerekmekte. Çünkü geliştirilecek sistemin ya da yazılımın bileşenleri üzerinde bu iki kavramın çok büyük etkisi olacaktır. İhtiyaca göre bu iki yaklaşım doğru çizilmelidir.”Kalıtım”(Inheritance) bileşenler üzerinde bağımlılığı artıracağından, hangi bileşenlerin bir birleri ile alakalı olacağı ilişkisinin çok iyi tanımlanması gerekmekte. Öte yandan “Bileşim”(Composition) bileşen kavramını daha netleştirecektir.
• Katmanlar(Layers): Geliştirilen sistem ya da yazılım da, bileşenler arasındaki ilişikileri görmek ve yönetmek adına sistemi ya da yazılımı katmanlara ayırmak tasarımı kolaylaştıracak ve temelini güçlendirecektir. Bu şekilde katmanlara ayırmak sistemdeki akışın yolunuda görmenize yardımcı olacaktır.

Mimari tasarımı yaparken bu tarz şeylere dikkat ediyor olmak, cidden bazı şeyleri çok daha net ortaya çıkarıyor ve sağlıklı bir geliştirme sürecinin ilk ışıklarını gösteriyor. En azından kendi tecrübelerime dayanarak bunu söyleyebilirim.Kendi tecrübelerim ve bilgilerim dahilinde “Mimari Tasarım” ve “Yazılım Tasarımı” arasındaki farkı anlatmaya çalıştım. Hatta biraz da “Mimari Tasarım”a daldım…Umarım faydalı olmuştur.İlerleyen zamanlarda bu konular hakkında daha çok yazıyor olacağım. Her türlü eleştiriniz ve düşüncenizi lütfen paylaşmaktan çekinmeyin. Bu kavramlar böyle böyle ortaya çıkıyor ve gelişiyor…Haydi görüşmek üzere…