Stable Dependencies Principle

Mimari tasarımların tamamen statik olması beklenemez. Proje maintain edildiği sürece bazı componentler değişime uğraması bazılarının da durağan kalması gerekir. Stable Dependency Principle’ın bize söylediği, sistem tasarlarken statik componentler ile sıkça değişen componentler arasındaki bağımlılıkların nasıl tasarlanacağıdır. Stable Dependencies Principle’ın detaylarına inmeden önce prensibin etrafında dönen tanımları kafamızda netleştirmeye çalışalım.

STABILITY

Bir demir parayı dik bir şekilde masanın üzerine koydunuz ve o şekilde konumunu muhafaza ediyor. Bu para stabil midir? Para dışarıdan kuvvet uygulanmadığı sürece duruşunu bozmaz. Yani konumu ve  durumu değişmiyordur ama bu paraya stabil demek için yeterli bir durum değildir. Webster’s dictionary’nin tanımına göre stabillik bir şeyin kolayca hareket ettirilememesi demektir. Yani onu hareket ettirmek için ne kadar miktarda efor harcadığımızla ilişkilidir. Bu durumda dik duran demir bir para stabil değilken büyük bir masa için stable diyebiliriz. Çünkü masanın mevcut durumunu değiştirmek için harcanan efor fazladır.

Peki bunu yazılımla nasıl ilişkilendirebiliriz. Yazılımda değişimi zorlaştıran bir çok madde vardır. Projenin boyutu, kod karmaşıklığı, clarity’si vs. Ancak, Stable Dependencies Principle adına konuşursak bunların hepsini bir kenara bırakıp odaklanmamız gereken başka bir nokta var. Bir componenti stable ya da unstable yapan şey ona ne kadar fazla componentin bağımlı olduğu ve o componentin ne kadar fazla componente bağımlı olduğudur.

STABILITY / RESPONSIBILITY / DEPEDENCY KAVRAMLARI
  • Bir componente  başka componentler bağımlıysa o component için yukarıdaki tanıma bakarak stable diyebiliriz. Çünkü componentteki değişikliklerin diğer tüm componenteki etkileri üzerine detaylıca düşünmek gerekir ve değişimi maliyetli olur.
  • Bir componente başka componentler bağımlıysa bu component için responsible da diyebiliriz. Çünkü kendisindeki bir değişikliğin diğer componentlerdeki etkisini de göz önünde bulundurmalı yani o componentlere karşı sorumlu olmalıdır. Eğer componente bağımlı hiç bir component yoksa da irresponsible diyebiliriz.
  • Bir component başka componentlere bağımlıysa dependent, hiç bir componente bağlı değilse de independent  component olarak adlandırılır.

Aşağıda X componentine bağımlı 3 component mevcut. Bu durumda X componentinde yapılacak her değişiklik 3 component üzerinde de etkiye sahiptir. X için değişimi maliyetli yani stable diyebiliriz. Bununla beraber X componenti bu 3 componente karşı responsible‘dır. Bunun dışında, X componenti hiç bir componente bağımlı değildir. Yani X componenti independenttır.

Aşağıda Y componenti 3 farklı componente bağımlıdır. Bu durumda Y dependent‘tır. Ancak Y’e bağımlı olan hiç bir component yoktur. Bu durumda Y’deki değişimin etki kapsamı dar ve kolay olacaktır. Yani Y unstable bir componenttir ve hiç bir componente karşı responsible değildir.

 

Static Dependency Prensibinin bize söylediğine tekrar dönecek olursak, “biz sıkça değişecek compenetleri(unstable), nadiren değişecek componentlere bağımlı kılmalıyız”dır. Çok fazla componentin bağımlı olduğu main componentleri olabildiğince stable olarak tasarlamalıyız. Yoksa bu componentteki bir değişikliğin etkisi diğer componentler üzerinde de çokça efor ortaya çıkaracaktır. Bir diğer ifadeyle, bağımlılıkların yönü stable tarafa olmalıdır.

Basit bir örnek vermek gerekirse klasik three layered architecture (Presentation-Business-DAL)’ı düşünebiliriz. Burada presentation katmanının sadece business katmanının metotlarını çağırdığını düşünürsek, business layer daha sık değişen unstable bir component iken Repositorylerin bulunduğu DAL katmanı daha az değişime uğrayan stable bir componenttir. Yukarıda tanımlandığı ve aşağıda görüldüğü üzere bağımlılığın yönü stable tarafa doğrudur. Eğer DAL katmanı çok sık değişen unstable bir component durumuna gelirse bağımlı olduğu business layerın da sıkça değişmesi gerekecektir.

STABILITY METRIKLERI

Bir componentin stabilitysini ölçmek için bazı metrikler belirlenmiştir. Bu metriklerin hesaplanması için componente olan bağımlılıkların ve componentin dışa bağımlılıklarının sayılması gerekir.

Fan-in : Bir componentin içerisindeki classlara dışarıdan bağımlı olan class sayısı.

Fan-out : Bir componentin içerisinden dışarıdaki component classlarına bağımlı class sayısı.

I : Instability   olarak düşünürsek

I = Fan-out / (Fan-n + Fan-out) olarak belirlenen bir metrik formulu var. I [0,1] arası değer alır. Eğer ki I = 0 ise maximally stable yani değişimi zor bir component I =1 için ise maximally unstable yani değişimi kolay component denilebilir.

Aşağıda CC componenti için metriği hesaplarsak,

Fan-in : 3

Fan-out : 1

I = 1/4 tür.

 

SDP’nin söylediği şey componentin I metriği bağlımlı olduğu coomponenlerden büyük olmalı. Yani I metriği bağımlılık yönünde azalmalı.

TÜM COMPONENTLER STABLE OLMALI MI?

Eğer tüm komponentler stabil olursa, system değişime tamamen kapalı olur. Bu da bizim istemediğimiz bir durum. Bu sebeple biz bazı componentlerin stable bazılarını ise unstable olarak tasarlarız.

Flexible component bizim değişimi kolay olarak tasarladığımız esnek componenttir. Ancak bazen developerlar stable componenti flexible componente bağımlı kılabilir ve flexibledaki tüm değişiklikler stable componente de etki edebilir. Bu problemin çözümü için Stable ve flexible arasındaki bağımlılıkları kırmamız gerekir. Bunu da Dependency Injection Prensibini kullanarak yapabiliriz.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         

Stable ve unstable componentler arası bağımlılık kırılması konusu içinde aşağıdaki yazıdan devam edebilirsiniz.

Tightly coupled-Loosely coupled Sistemler ve Dependency Injection

You may also like...

1 Response

  1. 7 Haziran 2020

    […]      Stable Dependencies Principle […]

Bir yanıt yazın

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