Uyum
- İngilizcesi
- Cohesion
- Türkçe karşılığı
- bağdaşıklık
- Okunuşu
- kohijın
Günlük kullanımda çoğunlukla İngilizcesi tercih edilir.
Kısaca
Uyum, bir modül, sınıf ya da servis içindeki sorumlulukların birbirine ne kadar ait olduğunun ölçüsüdür ve yüksek uyum iyi tasarımın işaretidir.
Yazılım tasarımında uyum (cohesion) nedir?
Uyum (cohesion), tek bir modülün parçalarının birbiriyle ne kadar güçlü ilişkili olduğunu anlatır. Yüksek uyumlu bir sınıf tek ve iyi tanımlanmış bir işi yapar ve tüm metotları ile verisi bu işe hizmet eder; yalnızca toplamları, vergileri ve indirimleri hesaplayan bir InvoiceCalculator gibi. Düşük uyumlu bir sınıf ise tarihleri biçimlendiren, e-posta gönderen ve görselleri yeniden boyutlandıran bir Utils sınıfı gibi ilgisiz görevlerden oluşan bir karışımdır.
Fikir, uyum türlerini en zayıftan en güçlüye sıralayan 1970'lerin yapısal tasarımından gelir. Şeylerin gerçek bir neden olmadan gruplandığı tesadüfi uyum (coincidental cohesion) en kötüsüdür; her şeyin tek bir göreve katkıda bulunduğu işlevsel uyum (functional cohesion) ise en iyisidir. Düşük uyumun uyarı işaretleri arasında Manager ya da Helper gibi belirsiz adlar, tamamen farklı alanları kullanan metotlar ve birçok ilgisiz nedenle değişmesi gereken bir sınıf bulunur; SOLID'deki tek sorumluluk ilkesi aslında yüksek uyum için bir kuraldır.
İyi düzenlenmiş bir mutfak bir benzetmedir: bir çekmecede yalnızca çatal bıçak, diğerinde yalnızca fırın aletleri vardır, böylece nereye bakacağınızı tam olarak bilirsiniz. Piller, lastik bantlar ve eski anahtarlarla dolu hurda çekmecesi düşük uyumdur. Aynı fikir servisler için de geçerlidir; kodu faturalama ya da nakliye gibi iş yeteneğine göre gruplamak her servise net bir amaç verir.
Uyum sıklıkla bağlılıkla (coupling) karıştırılır ve ikisi genellikle birlikte tartışılır. Uyum, tek bir modülün içindeki şeylerin ne kadar birbirine ait olduğuyla ilgilidir; bağlılık ise ayrı modüllerin birbirine ne kadar bağımlı olduğuyla ilgilidir ve hedef, gevşek bağlılıkla birlikte yüksek uyumdur. Yüksek uyum ayrıca sadece küçük demek değildir: uyumlu bir sınıfı çok sayıda küçücük sınıfa bölmek tek bir sorumluluğu dosyalara dağıtabilir ve bağlılığı artırabilir.
Önemli noktalar
- Uyum, bir modülün içeriğinin birbirine ne kadar ait olduğunu ölçer.
- Yüksek uyum tek net sorumluluk demektir; düşük uyum karmakarışık bir yığındır.
- Tek sorumluluk ilkesi yüksek uyuma ulaşmanın bir kuralıdır.
- Modüllerin içinde yüksek uyum, aralarında gevşek bağlılık hedefleyin.
- Uyumlu olmak küçük olmak demek değildir; boyuta göre değil, sorumluluğa göre bölün.
Örnek
// Low cohesion: unrelated jobs living in one class
class AppHelper {
formatDate(d: Date) { /* ... */ }
sendWelcomeEmail(to: string) { /* ... */ }
resizeImage(file: Blob) { /* ... */ }
}
// High cohesion: each class has one clear purpose
class DateFormatter { format(d: Date) { /* ... */ } }
class WelcomeMailer { send(to: string) { /* ... */ } }
class ImageResizer { resize(file: Blob) { /* ... */ } }Sık sorulan sorular
Bağlılık (coupling) ile uyum (cohesion) arasındaki fark nedir?
Uyum, tek bir modülün içindeki sorumlulukların birbirine ne kadar yakından ilişkili olduğunu; bağlılık ise farklı modüllerin birbirine ne kadar bağımlı olduğunu anlatır. İyi tasarımlar, modüller içinde yüksek uyumu, aralarında gevşek bağlılığı bir araya getirir.
Uyum nasıl ölçülür?
Resmî olmayan yolla, bir modülün bir cümleyle anlatabileceğiniz tek bir net amacı olup olmadığına ve metotlarının aynı veriyle çalışıp çalışmadığına bakın. Statik analiz araçları ayrıca, metotları çok az alan paylaşan sınıfları işaretleyen LCOM (lack of cohesion of methods) gibi metrikleri hesaplayabilir.
Uyum, tek sorumluluk ilkesiyle nasıl ilişkilidir?
Tek sorumluluk ilkesi, bir sınıfın değişmesi için yalnızca tek bir neden olması gerektiğini söyler. Onu izlemek doğal olarak yüksek uyum üretir, çünkü sınıftaki her şey aynı sorumluluğa hizmet eder.
İlgili sayfalar
- Gevşek BağlılıkYazılım Mimarisi, s. 16Gevşek bağlılık, bileşenlerin birbirine olabildiğince az bağımlı olduğu, böylece birinin diğerlerini bozmadan değişebildiği bir tasarım ilkesidir.
- SOLIDYazılım Mimarisi, s. 39SOLID, geliştiricilerin daha anlaşılır, genişletilebilir, test edilebilir ve bakımı kolay kod yazmasına yardım eden beş nesne yönelimli tasarım ilkesidir.
- İlgilerin AyrılmasıYazılım Mimarisi, s. 19İlgilerin ayrılması, bir programı her biri davranışının açıkça tanımlanmış tek bir yönünden sorumlu ayrı parçalara bölen bir tasarım ilkesidir.
- RefactoringYazılım Mimarisi, s. 32Refactoring, mevcut kodun dışarıdan görünen davranışını değiştirmeden daha temiz ve bakımı kolay hâle getirmek için yeniden yapılandırılması sürecidir.
- Domain-Driven DesignYazılım Mimarisi, s. 12Domain-driven design, kodu iş alanına yakından modelleyen ve alan uzmanlarıyla aynı dili kullanan bir yazılım geliştirme yaklaşımıdır.
- MikroservislerYazılım Mimarisi, s. 24Mikroservisler, bir uygulamanın ağ üzerinden iletişim kuran, küçük ve bağımsız olarak dağıtılabilen servislere bölündüğü bir mimari tarzdır.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin