Data Vinci 13 : High Cohesion

Tahmini Okuma Süresi: 6 dakika

“Object oriented programming” içerisinde geçen diğer bir terim “High Cohesion”. “Cohesion” kelimesinin anlamına baktığımızda “tutarlılık, yapışıklık” gibi anlamları var ki bize bu kadarı yeterli. Zira “high cohesion” tanımlanan objenin operasyonlarının birbirleriyle alâkalı, yakın olmasını ister. Bir class’ınız var ise bu class’ın “üstü şam, altı şişhane” olmamalıdır. “üstü şam, altı bir gece ansızın kerkük” olmalıdır. Bu high cohesion nasıl bilinir, boşa üfürüp duruyorsun, kim nasıl anlayacak methodlar veya objeler arasındaki ilişkiyi diyebilirsiniz fakat bunlar bir takım metrikler ile hesaplanmakta. LCOM mesela “Lack of Cohesion” metriğidir. Kullandığınız geliştirme ortamında “build” esnasında bir takım metrikler çalışır ve kod analizi çalışması yapar. Sonuç olarak bin bir türlü “warning” çıkabilir. Bunlardan birisi de “low cohesion” olabilir. Warning’ler göz ardı edilebilir ancak bu sıkıntıların geçtiği anlamına gelmez. Bu tarz kod yazım standartları özellikle çok yazılımcının ortak projeler yaptığı iş yerlerinde, önüne geçilmediği takdirde baş ağrıtıcı şeylere dönüşür.

Daha öncede belirttiğim gibi bir objenin “high cohesive, low coupled” olması yeğdir. Bunu en azından kulak dolgunluğu olması bakımından tekrarlamak gerekir. High cohesion konsepti bizlere bir sınıfın belirli bir operasyonu yapmasını ve bu operasyonun tüm gerekliliklerini de içermesini öğütler. High cohesion bir sınıfın isimlendirilmesinden başlar. Vergi hesaplayan bir sınıfın adı “VergiHesaplayıcı” gibi olmalıdır “Ananzaxd”gibi alakasız bir isimlendirme olmamalıdır. Yaptığı için içeriği ile ilgili bilgi vermesi iyi olacaktır.


 

High Cohesion, programlama yapılırken istenen bir yaklaşım dedik, cohesion başlığı altında ise birkaç çeşit yaklaşımdan söz etmek mümkün.

Bunlar Coincidental Cohesion ( Sen High seversin, cenazene Coincidental gelir),

Logical Cohesion (aynı kategoride yer alan parçaların bir araya gruplandırılması),

Temporal Cohesion ( Aynı esnada çalışmakta olan process’lerin belli süre boyunca oluşturdukları “Cohesion. Log atılırken, kullanıcıya mesaj gösterirken gibi anlarda oluşan geçiçi bir bağımlılığı işaret eder),

Procedural Cohesion ( Edi ile Büdü, Tango ile Cash gibi sürekli birlikte takılan process’lerin oluşturduğu “cohesion”, dosya kayıt edilirken yetkinin kontrol edilmesi gibi…),

Sequential Cohesion ( Birinin girdisi diğerinin çıktısı olan işlemler bir veriyi oku ve üzerinde işlem yap…),

Communicational Cohesion (Aynı veriyi işleyen süreçler),

Functional Cohesion ( Tek bir process’i icra etmek için oluşturulmuş her bir fonksiyonun oluşturduğu cohesion).

Cohesion konusundan bahsederken coupling ve decoupling gibi kavramlarda karşımıza çıkacaktır. Cohesion’ın High olması istenirken coupling’in low olması beklenir. Teorik olarak söylenince kolay bir iş gibi görünse de fuları takmadan tam olarak bu yapıların kurulması, özellikle de büyük uygulamalar için derinlemesine analiz gerektirir.

İdeal olarak bir uygulamadaki bağımlılıklar modüller arasında bir obje ile oluşturulurken, God Object anti-pattern’inde tüm modüllerin birbirleriyle bağımlılıkları da tek bir objeyi işaret etmektedir. Böyle bir sistem için High Cohesive, high coupled denilebilir. Single Responsibility kuralına uymayan domain modelleri ise modüllerinin sınırlarının belirlenememesinden ötürü gereksiz bağımlılıklar içerir. Tek noktadan birbirine bağlı fakat her bir modül de istenmediği halde birbirine bağlı olan modellerde ise destrucive decoupling anti-pattern’i oluşur. Görüldüğü üzere high cohesion ve low coupling sağlamaya çalışılırken başka anti-pattern’lere sebebiyet verilebilir.

Karmaşıklık seviyesi bir takım yazılım metrikleri ile hesaplanmaktadır. Varoşlarda “Neyse halim, çıksın falim” şeklinde vücut bulan bu hesaplama yöntemi, yüksek sosyetede “Cyclomatic complexity” olarak anılır. Bu hesaplama biçimi tüm bağımlılıkların bir graph olduğu,  her bir modülü de node kabul eder isek, graph üzerindeki kenarlardan çıkarılması ve bağlı component’lerin 2 ile çarpılması ile hesaplanır: Cyclomatic Complexity. Bu tarz bir analiz sonucunda kodun bağımlılık seviyesine bir matematiksel değer ile ifade edindirmiş oluyoruz. Bu değerin düşük olması tabii ki istenendir.

TL;DR

Bu yazıda High Cohesion ana başlığı ile başlayarak, coupling, decoupling, cohesion gibi konulara değinmeye ve cohesion çeşitlerini açıklayıp, örneklemeye çalıştım. Bu noktada yeri gelmişken bahsedeceğim coincidental cohesion en leş yaklaşım iken functional cohesion elittir. Yani biz yazılımcıların functional cohesion’ı sağlamaya çalışmamız gerekiyor. Camiada konusu açılırsa bu kıstası göz ardı etmeyelim.

 

Umarım faydalı olur.

 

keep_calm

Leave a Reply

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