“SoC” Prensibi (Separation Of Concerns)

Bu yazımızda, kısaca “SoC prensibi” olarak bilinen “Separation of Concerns” hakkında derinlemesine bir inceleme yapacağız.

“SoC” Prensibi Nedir?

“SoC prensibi” ilk olarak 1970‘lerde Edsger W. Dijkstra tarafından karmaşık yazılım projelerini daha basit ve anlaşılır parçalara bölmek amacıyla geliştirilmiştir. Günümüzde, bu prensip modern yazılım tasarım ve mimari yaklaşımlarının temelini oluşturmaktadır. Özellikle MVC, MVP ve MVVM gibi yazılım tasarım desenleri, yazılımın farklı bileşenlerini ayrı ayrı ele alarak, bu prensipe dayanarak geliştirilmiştir.

Türkçeye “Sorumlulukların Ayrılması” ya da “Endişelerin Ayrılması” olarak çevirebileceğimiz “SoC” prensibi, her bir modül veya bileşenin sadece tek bir işlevi veya sorumluluğu olması gerektiğini vurgular. Ne demek istediğimi bir örnek üzerinden anlatırsam anlaşılacaktır diye düşünüyorum.

Bir fatura oluşturma uygulaması tasarladığımızı hayal edelim. Bu uygulamada, müşteri bilgileri alınacak, fatura kalemleri eklenecek ve sonrasında da ilgili faturanın PDF olarak kaydedilmesi sağlanacak diyelim.

İlk olarak tüm bu yaptığımız işlemleri tek bir fonksiyon içinde gerçekleştirdiğimizi varsayalım. Yani, “kullanıcı bilgilerini almak”, “fatura kalemlerini eklemek” ve “PDF olarak kaydetmek” için tüm yazdığımız kodun tek bir yerde olduğunu hayal edelim.

Böylesi bir kod yığını sizce nasıl olurdu? Keşmekeş olurdu değil mi? Hele de sadece PDF oluşturma kısmında bir değişiklik yapmak istediğimizde, tüm fonksiyonu incelememiz gerektiğini düşündüğümüzde baya zamanımızı alacak ve hata yapma riski yüksek stresli bir süreç olacaktı.

İşte “SoC” prensibi tam da böyle durumlarda imdadımıza yetişir. Aynı uygulamayı SoC prensibi kullanarak ele aldığımızda işe aşağıdaki adımları uygulayarak başlarız:

  1. Müşteri bilgilerini işleyen bir modül.
  2. Fatura kalemlerini ekleyen ve düzenleyen bir modül.
  3. Faturayı PDF olarak kaydeden bir modül.

Böyle bir durumda PDF oluşturma kısmında bir değişiklik yapmak istediğimizde sadece ilgili modüle, yani 3. maddeye odaklanabiliriz. Haliyle diğer modüllerle ilgilenmemize gerek kalmadığı için optimizasyon işlemini diğer yönteme nazaran bariz bir şekilde sağlıklı bir şekilde gerçekleştiririz.

Böylece bileşenler arasındaki bağımlılıklar minimize olacak, her bileşenin bağımsız bir şekilde geliştirilmesi, test edilmesi ve bakımının yapılması kolaylaşacaktır.

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu