Coupling ve cohesion: yazılım modüllerinde bağımlılık ve tutarlılık

Coupling ve cohesion nedir?

Coupling, yazılım modüllerinin, sınıflarının ya da servislerinin birbirine ne kadar bağımlı olduğunu anlatır. Cohesion ise bir modülün içindeki öğelerin ne kadar birbiriyle ilgili ve ortak bir amaca hizmet ettiğini gösterir. Türkçede coupling çoğunlukla bağımlılık ya da bağlaşım, cohesion ise bağlılık ya da tutarlılık diye çevrilir; çeviriler kaynağa göre değişir.

İyi bir tasarımda düşük coupling ve yüksek cohesion hedeflenir: modüller birbirinden olabildiğince bağımsızdır ve her biri tek bir konuda uzmandır.

Sıkı ve gevşek bağlılık

Sıkı coupling, bir modülün başka bir modülün iç ayrıntılarına doğrudan bağlı olduğu durumdur. Alttaki değiştiğinde üstteki de bozulur. Gevşek coupling ise modüllerin yalnızca tanımlı arayüzler üzerinden konuştuğu ve birbirinin içini bilmediği durumdur.

Örnek:

class SiparisServisi { constructor() { this.odeme = new KrediKartiOdeme(); } }

Burada SiparisServisi doğrudan belirli bir ödeme sınıfına bağlıdır. Ödeme yöntemi değişirse sipariş servisinin kodu da değişmek zorundadır. Gevşek biçimde, ödeme arayüzü dışarıdan verilir:

class SiparisServisi { constructor(odeme) { this.odeme = odeme; } }

Bu yaklaşım bağımlılık enjeksiyonu olarak bilinir.

Coupling'in farklı türleri de vardır: veri aracılığıyla bağlanma, ortak durum üzerinden bağlanma ve bir modülün diğerinin iç yapısını bilmesi. Genellikle ortak durum ve iç yapı bağımlılığı en riskli olanlardır, çünkü değişiklik etkisi görünmez biçimde yayılır.

Düşük ve yüksek cohesion

Yüksek cohesion, bir modülün tek bir sorumluluğa odaklanmasıdır. Örneğin bir fatura modülü yalnızca fatura oluşturma ve hesaplama işlerini içerir. Düşük cohesion ise ilgisiz işlerin aynı yerde toplanmasıdır: aynı sınıf hem kullanıcı doğrulama, hem e-posta gönderimi, hem raporlama yapıyorsa modülün amacı bulanıklaşır.

Düşük cohesion, modülün neden değiştiğini anlamayı zorlaştırır ve her değişiklikte başka işlevleri bozma riskini artırır. Tek sorumluluk ilkesi bu dengeyi sağlamak için yaygın kullanılan bir rehberdir.

Neden önemlidir?

Kavramlar birlikte değişimin maliyetini belirler:

• Düşük coupling: Bir modülün değişimi diğerlerini etkilemez, test ederken bağımlılıklar kolayca taklit edilebilir.
• Yüksek cohesion: Modül kolay anlaşılır, yeniden kullanılır ve bakımı kolaydır.
• Takım çalışması: Farklı ekipler birbirini beklemeden modüller üzerinde çalışabilir.
• Mimari esneklik: Teknoloji veya servis değişiminde etkilenen alan küçük kalır.

Mikroservis gibi dağıtık mimarilerde bu ilişki servis sınırlarının nerede çizileceğini de belirler.

Pratikte nasıl iyileştirilir?

Önce bağımlılıklar görünür kılınır: hangi modül hangisini çağırıyor, çevrimsel bağımlılık var mı. Ardından arayüzlere dayalı iletişim, bağımlılık enjeksiyonu ve olay tabanlı iletişim gibi yöntemlerle bağlar gevşetilir.

Cohesion için sorumluluklar ayrıştırılır; bir sınıf ya da modül birden fazla nedenle değişiyorsa bölünür. Refactoring ve kod incelemesi bu iyileştirmeyi sürekli yapmanın yollarıdır. Katmanlı veya temiz mimari gibi yaklaşımlar, bağımlılık yönünü kurallı hale getirerek düşük coupling'i yapısal olarak destekler.

Bu konu Mindset programlarında nerede geçer?

Yazılım Mimarisi ve Tasarım Desenleri programındaki SOLID ve tasarım prensipleri ile mimari değerlendirme modülleri bu kavramları mimari karar düzeyinde işler. Clean Coding Uzmanlığı Eğitimi kod düzeyinde modülerlik ve refactoring üzerine çalışır.

Android Uygulama Mimarisi programı ise modül yapısı, bağımlılık enjeksiyonu ve katmanlar arası ayrım üzerinden kavramı mobil uygulama bağlamında uygular.