SoC (Separation Of Concerns) Prensibi
Artık işleri basit tutuyor, gereken işin planlanan şekilde ve en yalın hali ile ortaya çıkarılmasını sağlıyoruz. Şahane. Artık “davranış” bağlamının biraz daha ötesine geçebilir ve edindiğimiz prensipleri herkes tarafından görülebilir, uygulamanın ürünün işleyişine etkiyebilir bir hale getirebileceğimize bakabiliriz.
Özellikle yazılımcılar tarafından sıklıkla değinilen SoC (Separation Of Concerns) prensibinden bahsetmek istiyorum. İleri okumalar bölümünde de yazılımcıların tecrübeleri çerçevesinde bazı anlatılara yer vermeye çalıştım. Mutlaka göz atmalısınız.
SoC (Separation Of Concerns)
SoC (Separation Of Concerns), yazılımda işlev ve özelliklerine göre programlama kodlarının (class, fonksiyon vb.) birbirinden ayrılması / soyutlanması gerektiğini belirten bir tasarım prensibidir ve günümüzde tercih edilen pek çok yazılım tasarım şablonunun (design pattern) da temelini oluşturur. Her eleman (modül) diğerinden bağımsızdır ve kendi sorumluluğuna (single responsibility) sahiptir1. Bu kapsamlar sınırlarla belirlenir. Yazılımın geliştirme sürecine dair kullanılan “sınır” kavramı esasında oldukça net bir çizgi (layer / tier) çizer, sorumluluklar sınırlarla tanımlanır ve diğerinden ayrıştırılır. Tüm bu kavramlar içerisinde SoC süreci mümkün olan en küçük parçaya (işlev ve sorumluluk kümesi bağlamında) bölmeyi ve ortaya çıkan sorumlulukları bağımsız kılmayı öğütler2. Bu sayede diğer elemanların işleyişi aksamadan geliştirme yapmak mümkün hale gelecek, olası bir sorunda diğer elemanlar sorundan tanımlanan sınırlar çerçevesinde etkilenecektir. KISS prensibine oldukça benzer bir söylem, değil mi?
Elbette konuyu sadece yazılım geliştirme bağlamında da düşünmemek gerekir. En temel yaklaşımla, CSS dosyalarının css, JavaScript dosyalarının js, görsellerin img isimli klasörlerde tutulması, HTML, CSS ve JavaScript işlemlerinin farklı yapılar olarak ele alınması, SMTP gibi protokolleri dahi SoC yaklaşımına örnek olarak gösterilebilir.
SoC Yaklaşımı
SoC prensibi için önemli iki kavramdan bahsetmek gerekir. Sınıf / nesne gibi yazılım bileşenleri arasındaki ilişki (coupling) ve bileşenler içerisindeki birliktelik (cohesion). Düşük bağlılık (low-coupling) ve yüksek sorumluluk (high-cohesion) bu anlamda tercih edilen bir yapıdır. Bu daha kontrollü bir sistem inşaası anlamına gelmektedir. Bu anlayış yazılımların esnek ve genişletilebilir olması için de bir anahtar görevi görür3.
MV* bağlamında örnek olarak, Vue.js yazılarında da sıklıkla bahsi geçen Model-View-View Model (MVVM) pattern’i düşünebiliriz. Model, veritabanı / data’ya denk gelirken View UI Presentation’a odaklanır. View Model ise iş katmanıdır (layer) ve View Model ilişkisini yönetir.