Endişelerin Ayrılması (Separation of Concerns) tasarım ilkesi düşük bağlılığa ve benzer sorumluluklara (cohesion) sahip bileşenler ile kümeler/kapsüller oluşturmamıza, sorumluluk sınırlarının net bir şekilde belirlenerek ayrılmasına odaklanır.
SoC ile sürdürülebilir, geliştirilebilir ve tekrar kullanılabilir bilşenlerimiz ve bu bileşenler sayesinde projeler olur.
SoC ile temelde soyutlama (abstraction) yapılır. Soyutlama yaparken dikkat etmemiz gereken nokta ise birbirleri ile benzer bileşenleri gruplayarak (bunlar; dosyalar, sınıflar, fonksiyonlar ve kod blokları olabilir) bu kümeleri yakın şekilde konumlandırmaktır.
Bu sayede hem yönetimi daha kolay olacak hemde çok daha düzenli bir mimarimiz olacaktır. Geliştirme yaparken olası bir sorun oluşması halinde ya da mevcut projede bir sorun oluşması durumunda sorumlu tek bir nokta olacağından problemlerin çözümü ve problemden etkilenen noktalar olabildiğince kısıtlı olacaktır. Yani negatif bir senaryoda yan etkileri sadece bağlantılı modüllerini etkileyecektir.
Tekrar kullanılabilir olması durumu ise sorumlulukları kısıtlı tutmamız ile mümkün olur. Sadece bir işten sorumlu (Bkz: halilsafakkilic.com/single-responsibility) olan bileşeni başka bir projede kolayca kullanabiliriz. İşte tam olarak bu kolaylıktan faydalanabilmek için düşük bağımlılığa (loose coupling) ve yüksek bağlılığa (high cohesion) sahip olmasına dikkat etmeliyiz.
Gerçek hayattan bazı örnekler ile konuyu daha anlamlı hale getirelim;
Örnek #1: FrontEnd için dosyaların konumlandırılması
UI için CSS/JS/Görsel/Yazı Tipleri gibi dosyalarımız olur ve bu dosyaları gruplarken; css/ dizini altına CSS dosyalarımızı, js/ dizini altına JavaScript dosya ve kütüphanelerimizi, images/ dizini altına görsel dosyalarımızı, fonts/ dosyaları altına yazı tiplerimizi konumlandırız.
Bu sayede sorumluluklar ayrılmış ve ayrılan sorumluluklar doğrultusunda bir dizin sistemi ortaya çıkmıştır.
Örnek #2: MVC (Model/View/Controller)
MVC tasarım örüntüsü (design pattern) SoC uygulanmış bir örüntüdür. Veritabanı sorgularımız Models/ dizini (ya da namespace) altında, UI için kullanılan şablonlarımız/sınıflarımız Views/ içerisinde, gelen istekleri karşılama (routing) sonrasında orkestrasyonu sağlayacak olan Controller’lar ise Controllers/ dizini (ya da namespace) altında konumlandırılır.
Örnek #3: Altyapı (Infrastructure)
Projelerimizde statik metodlarımızı içermesi için Helpers/ dizini (ya da namespace) oluştururuz ve tüm helper niteliğindeki bileşenlerimizi burada konumlandırırız. Aynı şekilde servis referansları için ServiceReferences/ oluşturup buranın altında ihtiyaç duyduğumuz servislerin istemci bileşenleri konumlandırız.
Sorumlulukları ayırırken “bunu acaba nereye koysam” diye düşünmediğiniz, mantıklı ve anlaşılabilir şekilde SoC uygulanmış projelerde buluşmak dileğiyle…
