Cephe yönelimli programlama

Vikipedi, özgür ansiklopedi
Atla: kullan, ara

Cephe yönelimli programlama veya görünüm yönelimli programlama, bir programlama yaklaşımıdır. Bütün programlama yaklaşımlarında kodlar uzadıkça, kodların anlaşılabilirliği çok düşmekte, bazen de içinden çıkılmaz bir hal almaktadır. Programlamanın varlığıyla birlikte bu sorun da hep varolmuştur. Bu sorunla savaşabilmek için sürekli çalışmalar devam etmektedir, bu süreçte ortaya çıkan önemli bir programlama yaklaşımı da Cephe Yönelimli Programlamadır.

Cephe yönelimli programlama ve cephe yönelimli yazılım geliştirmeye ait olan programlama paradigmaları, yazılım mühendisliğinde, programcılara, özellikle, çapraz kesim olmak üzere, modülarite programlama (modülarizasyon) konusunda yardımcı olmaya çalışmaktadır.Cephe yönelimli yazılım geliştirme, bileşik dil, çevre ve yöntem kullanıyor iken, cephe yönelimli programlama, herşeyden önce, dil değişikliklerini kullanarak bunu gerçekleştirmektedir.

Sorunların ayrılması, bir programın, işlevsellikte, olabildiğince çakışma yapan farklı kısımlara ayrılmasını gerektirmektedir. Tüm programlama teknikleri - (işlemsel programlama) ve (nesne yönelimli programlama)dahil- işlerin (ya da herhangi ilgi ya da odak noktası), küçük varlıklara ayrılması ya da giydirilmesini desteklemektedir. Örneğin, işlemler, paketler, sınıflar ve yöntemlerin hepsi, programcılara, küçük varlıklar biçiminde yardımcı olurlar. Ama bazı işler, bu tarz giydirmeye karşı çıkmaktadırlar. Yazılım mühendisleri, bunları, çapraz kesim işleri olarak adlandırmaktadır, çünkü, program içerisindeki pek çok modülü, çapraz olarak kesmektedirler.

Temel Kavramlar[değiştir | kaynağı değiştir]

Kimi kod, anlamayı ve akılda tutmayı zorlaştıracak şekilde "dağınık" ve karmaşıktır. Tek bir iş (kaydetmek gibi) pek çok modül (örn.. sınıflar ve yöntemler)üzerinden dağılım gösterdiğinde dağınıktır. Bu, kaydı değiştirmek için, değişen, etkilenmiş olan tüm modülleri değiştirmek anlamına gelmektedir. Modüller, çoklu işlerle (örn.: hesap işlemi, kayıt ve güvenlik) karmaşık şekilde biter. Bu, tek bir modül değişiminin, tüm karmaşık işleri anlamayı gerektirdiği anlamını taşımaktadır. Örneğin, bir bankacılık uygulamasının bir hesaptan diğerine para transferi yapılan metodunu ele alalım:

void transfer(Account fromAccount, Account toAccount, int amount) {
  if (fromAccount.getBalance() < amount) {
    throw new InsufficientFundsException();
  }
 
  fromAccount.withdraw(amount);
  toAccount.deposit(amount);
}

(örnekler Java-benzeri sözdizimde verilmiştir, çünkü cephe yönelimli programlamaya ilişkin çalışmalarda Java veya Java benzeri sözdizimler kullanılmaktadır)

Bununla birlikte, bu transfer metodu gerçek dünyada bir bankacılık uygulamasına uygun görünmemektedir. İşlemi yapan kullanıcının, olması gereken kullanıcı olup olmadığına ilişkin güvenlik kontrolleri yapılmalıdır, veri kaybını önlemek için etkileşim içinde gerçekleşmelidir, loglama yapılmalıdır vs. Tüm bunların basitçe yapılmış hali şuna benzer :

void transfer(Account fromAccount, Account toAccount, int amount) {
  if (!getCurrentUser().canPerform(OP_TRANSFER)) {
    throw new SecurityException();
  }
 
  if (amount < 0) {
    throw new NegativeTransferException();
  }
  if (fromAccount.getBalance() < amount) {
    throw new InsufficientFundsException();
  }
 
  Transaction tx = database.newTransaction();
 
  try {
     fromAccount.withdraw(amount);
     toAccount.deposit(amount);
     tx.commit();
     systemLog.logOperation(OP_TRANSFER, fromAccount, toAccount, amount);
  }
  catch(Exception e) {
     tx.rollback();
  }
}

Yapılan basit işlemin içine başka çeşitli işler girdiği için kod şıklığını ve basitliğini yitirdi. Transaction'lar, güvenlik, loglama; bunlar hep araya giren işler oldular.

Aynı zamanda, uygulamanın güvenlik işlerini (örneğin) hemen değiştirmek ihtiyacı duyarsak, ne olacağını düşününüz. Programın güncel versiyonunda, sayısız yönteme karşın, güvenlik ile ilgili operasyonların, "dağınık" gibi görünmektedir ve bu tür bir değişiklik, temel bir çaba gerektirmektedir. İşte bu yüzden, çapraz kesim işlerinin, kendi modülleri içerisinde, uygun şekilde kuşatılmadığını farkediyoruz. Bu, sistem karmaşasını artırmakta ve gelişimi, önemli ölçüde zor hale getirmektedir. n before, after, and around join points.

Ayrıca bakınız[değiştir | kaynağı değiştir]

Kaynak[değiştir | kaynağı değiştir]

İngilizce Vikipedi'deki 17 Nisan 2007 tarihli Aspect-oriented programming maddesi