Data Vinci 10 : Seperation of concerns

Yazılım geliştirme disiplini ile ilgili birçok prensip var. Bunlardan bir tanesi de “seperation of concerns”.  Programlar bir dizi klasör, kendine has dosya tiplerinden oluşmakta. En basit anlamda bunların kategorilendirilmesi bile bu prensibin tanımına girebilir. Bir web uygulaması geliştiriyorsanız kabul görmüş bir takım dosya kategorilerini kullanmanız gerekir. Örneğin resim dosyalarını images, javascript dosyalarını js, css dosyalarını da css klasörü altında depolamak gibi. Farklı işleri yapan uzantıları farklı dosyaları bu şekilde ayrıştırarak bir hiyerarşi oluşturmak, aradığımızı bulmak adına faydalı bir davranış biçimidir. “Seperation of concerns” prensibi de bize bunu öğütler. Katmanlı mimaride de böyle değil midir?  Prensentation Layer’dan direk bir Data Access methodu çağırmayız, bunun yerine ara katmanlar oluşturarak katmanların yaptıkları işleri “ayırır” birbirlerinin ne yaptıklarıyla ilgilenmeyen sadece gerekli yerlerde referanslar aracılığı ile haberleşen modüller oluştururuz. Bu da “seperation of concerns” uygulamasıdır aslında.

Yine ilişkili bir takım prensiplerle birlikte “seperation of concerns” yaklaşımı “bağımlılık” düşük ,  “sorumluluk” yüksek bileşenler hedefler. Loosely coupling ve high cohesion gibi terimler de “seperation of concerns” prensibinin yakın ilişkili olduğu diğer terimler. Sadece yazılım dünyasında değil günlük hayatta da bir takım işlerin kategorilendirilmesi ve her kategorideki işin de kendi kapsamında değerlendirilmesi gerekir. Örneğin kişisel plan yapıyorsunuz ve “eğitim” kategorisinde yaptığınız işler var. “Pazara gitmek” bu kategori içerisinde bir kaygı oluşturmamalı, bir aksiyona sebep olmamalı. Ancak zaman yönetimi kısmında, pazara gitmek ile ders çalışmak arasında, birbirlerini kesici etkileri olmadan sıralama ve düzenleme yapılmalı. Aksi halde “bom”. Ne gittiğiniz pazardan, ne çalıştığınız dersten bir şey anlarsınız.

Yazılım tarafından bakıldığında büyük resim içerisine Single Repsonsibility Principle ve Don’t Repeat Yourself Principle dahil olmakta. Nesneye yönelik dillerde objeler vasıtasıyla oluşturulan yapılar sayesinde, farklı kaygılar için oluşturulmuş farklı iş mantıkları ayrılabilmekteyiz, benzer şekilde mimari yaklaşım ile konuya bakacak olursak aklımıza ilk gelen SoC(seperation of concerns) yaklaşımı MV* konsepti karşımıza çıkabilir.

“Katmanlı mimari” iş ilanlarının vazgeçilmez terimlerinden biri. Belki şimdilerde, zamanında fazla kullanılmaktan ötürü anlamını kaybetmiş, yerine başka “cool” prensiplere bırakmış gibi görünse bile aslında katmanlı mimari gelip geçici bir heves, ortamlarda havamızı atacağımız teknik bir jargon olmasının ötesinde doğru şablonlardan birisidir. Katmanların ne olduğu değişir, 3 katman, 5 katman, 26 katmanlı tasarımlar oluşturulabilir. Fakat önemli olan konu bu katmanlarda sorumluluk alan “süreç partikülleri*”nin birbirlerinin rollerine üstlenmemesi, mümkün mertebede uzak katmanlardan referans almamasıdır.

Gerçek hayattan verilebilecek bir örnek, bir web sitesinin kullanıcı tercihleri ve güvenlik ayarları ile ilgili bir takım iş kuralları olduğunu düşünelim. Burada kullanıcının kişisel tercihleri ile güvenlik ayarlarının farklı servisler ile sağlanması basit bir SoC implementasyonudur diyebiliriz.

Seperation of Concerns yaklaşımı için en tanıdık gelen “dividing(katmanlama)” işlemi Horizontal Separation. Her katman kendine atanmış olan işten sorumludur. Presentation katmanı user interface ile ilgili component ve process’leri icra ederken, Business Katmanında application domain ile ilgili component ve process’ler işletilir. Benzer şekilde Resource Access katmanında ise bu kez dışardan erişim yapılan dosyalarla ilgili component ve process’ler işletilir.

  • Vertical Seperation ise uygulamayı modül bazlı olarak ayırmaktadır. Her özellik ayrı bir alt-sistem olarak kurgulanır.
  • Uygulama boyutu büyüdükçe SoC uygulaması dikey ve yatayın bir arada bulunduğu(metroya yürüme mesafesinde, gölet manzaralı) tasarımlar ile de uygulanmaktadır.

  • Bunların dışında Aspect Oriented , Dependency Direction, Data Concerns, Behaviors Concerns, Extending Concerns, Delegation Concerns, Inverting Concerns gibi yöntemler ile de konuya bakış açışı katılabilir. Derin okuma için yukarıdaki grafik objelerini almış olduğum  art of seperation concerns adlı yazıyı okumanızı tavsiye ederim. “Art” geçen her yerde fuların eksik olmayacağı aşikâr…
  • TL;DR

Bu yazıda Seperation of Concerns kavramına değinmeye çalıştım. Teknik implementasyonları olan ve soyut bir bakış açısı da sunan bu kavramı en azından temel olarak bilmek gerekli. Fuları çıkarıp baktığımızda aslında sıklıkla kullandığımız bir yaklaşım. “3 dene proje açacan daaa, ui ,common, dataaccess,”(burada bir saltbae hareketi). Fazla şaapmamak lazım. Akışa ve fulara güvenin dostlar.

Umarım faydalı bir yazı olmuştur.

  • * Teknik terimlerin ifade edilmesi abartıldığında, kolay bir anlatım ile okuyana veya dinleyene geçirilebilecek bir bilginin aktarımı zorlaşıyor diye düşünüyorum. Bazen kendimde de görmüş olduğum bu zaafa dikkat çekmek için “süreç partikülleri” gibi uydurma bir terim ile ifade ettim. Yalın hali : iş modelleri, işleri yapan fonksiyonlar, kodlar vb…

keep_calm

Leave a Reply

Your email address will not be published. Required fields are marked *