C#'ta DRY Prensibi: Kod Çoğaltmanın Kod Tabanınıza Zarar Verdiği Nedenleri – Derek Comartin Tarafından Açıklandı

DRY İlkesi Tanımlandı

Videonun başında, Derek birçok geliştiricinin karşılaştığı durumu çerçevelendirir: değiştirmesi zor bir sistemle uğraşmak—tekrarlanan kod ve fazlalık mantık karmaşası.

DRY ilkesini C#'ta kod tekrarını azaltmaya yönelik bir strateji olarak tanıtır; ancak yanlış anlaşılabileceğine dair uyarır. Derek, 0:28'de açıkladığı gibi:

"DRY başarılı bir şekilde uygulandığında, sistemin herhangi bir tek unsurunda yapılan bir değişiklik mantıksal olarak ilişkisiz diğer unsurlara bir değişiklik gerektirmez."

Bu ayrım kritik. DRY ilkesi sadece yinelenen kodu önlemekle kalmaz, ama endişelerin ayrılmasını ve doğru kod yeniden kullanımını teşvik eder—bakımı yapılabilir, kuru kodu test etmeyi ve yeniden düzenlemeyi kolaylaştırır.

Pratik Örnek: Mesafe Dönüşümü

Konuları somut hale getirmek için Derek, C#'ta basit bir örnek sunar. İki yöntem yazar:

• ShipDistance

• TollDistance

Her biri mesafeleri mil cinsinden hesaplar, sonra bunları kilometrelere çevirir—her iki yöntemde de aynı mantığı kullanır. Bu klasik bir kod tekrarıdır.

Aynı kod parçasını birden fazla yerde bulundurmak yerine, Derek dönüşüm mantığını özel bir yönteme—MilesToKilometers()—nasıl çıkartabileceğinizi gösterir—yeniden kullanılabilirlik için kodu yeniden düzenlemenin basit ama etkili bir yolu.

Bunu tipik konsol uygulama yapısını kullanarak gösterir: bir Class Program içeren bir static void Main. Bu, birçok geliştiricinin mantığını test etmek veya benzeri yeni bir kullanıcı girişi senaryosuyla denemeler yaparken yaş gibi public int değerini, kullanıcı adı, şifre gibi string değer yapılar kullanır.

DRY vs. Aşırı Birleşim

Mantığı yeniden kullanılabilir bir metoda veya ayrı bir sınıfa soyutlamak ideal gibi görünse de, Derek dikkatli olunması gerektiğini vurgular. Özellikle tüm bir uygulama üzerinde DRY aşırı kullanım, tehlikeli birleşim seviyelerine yol açabilir.

Örneğin, dönüşüm mantığını birden fazla proje tarafından kullanılacak ortak bir araca koyarsanız ve daha sonra yuvarlama davranışını veya ondalık hassasiyetini değiştirirseniz, bu değişiklik birçok alanı beklenmedik şekilde etkileyebilir. Derek'in 2:31'de dediği gibi:

"İstemciler iki ondalık basamak bekliyorlar mı? Eğer bunu sıfıra değiştirirsek ne olur?"

Bu bir çapraz kesim kaygısıdır — sistemin birçok parçası tarafından yeniden kullanılan mantık — ve erken ya da net sınırlar olmaksızın merkezileştirmenin riskini gösterir.

Derek'in burada verdiği tavsiyeler, kodunuzu uyarlanabilir ve modüler tutmak için kritik olan Tek Sorumluluk İlkesi ile Gevşek Bağlantı İlkesini yineler.

DRY Yanlış Uygulandığında Oluşan Kod Şişmesi

DRY yanlış kullanımının bir diğer sorunu kod şişmesi — her şeyi soyutlamaya çalışmanın abartılmış araç sınıflarına veya fazla jenerik yöntemlere yol açması. Derek, fazla DRY mantığı dikkat edilmezse yanlış yardımdan daha fazla zarara sebep olabileceğini uyarır, özellikle bir alandaki hata düzeltmelerinin, ortak bağımlılıklar nedeniyle diğerlerini bozabileceği büyük sistemlerde.

Derek'e göre anahtar, kodu paylaşmamanın ne zaman gerektiğini bilmek—özellikle döğmeye bağlanmış modüllerle sonuçlanıyorsa. DRY bir kural değildir; bağlamla beraber kullanılacak bir kılavuzdur.

Varlıklara Uygulanan DRY: Karmaşıklık için Bir Tarif

Derek, geliştiricilerin yaygın bir eğilimini tanımlar: sistemleri tamamen Kamyon, Sipariş, Sürücü ve Nakliye gibi varlıklar etrafında organize etmek. Farklı yöntemler arasında aynı sınıf veya nesneyi tekrar kullanmak cazip gelse de, bu genellikle tekrarlayan kavramlara ve istenmeyen bağlılıklara yol açar.

Veri yapılarından daha fazlası olan iş yeteneklerinin mimariyi yönlendirmesi gerektiğini savunur. Örneğin, 'bir siparişi gönderme', 'bir römorku çözme' den farklı bir meseledir, aynı varlıkları içerseler bile.

4:45'te, Derek açıklar:

'Sisteminizdeki tekil bir varlık, birden fazla kavramın temsili olmak zorunda değil.'

Bu, daha derin bir mimari içgörü vurgular: Aynı ada sahip varlıklar (Araç, Römork), farklı iş akışlarında farklı sorumlulukları temsil edebilir. Onları birbirinin yerine kullanmak kafa karışıklığı yaratır ve alakasız iş mantığını sıkıca bağlar.

DRY ve İş Yeteneği

Bunu çözmek için Derek, dikey dilim mimarisi (VSA) — katmanlar yerine iş yetenekleri etrafında uygulamaları yapılandıran bir desen — tanıtır. Her 'dilim', belirli bir eylem veya kullanım durumu için — istekten veritabanına kadar — her şeyi kapsayıcı ve kendine yeterli bir şekilde içerir.

İçeride DRY'nin iyi olduğu vurgulanıyor — tek bir konum içinde — ama dilimler arasında DRY'yi uygulamak dolaşık bağımlılıklara yol açabilir. 6:44'te, ekler:

'Sadece bağımlılığı azaltmak ve uyumu artırmak... ve bunu yapmanın yollarından biri iç sınırlar içinde kavramları tekrar etmemek.'

Bu sınır odaklı düşünce size esneklik sağlar. Bir dilimde tam bir etki alanı modeli, diğerinde ise sadece hafif bir veri modeli olabilir. Dilim ihtiyaçlarına bağlı — Pragmatik Programcı felsefesiyle uyumlu pragmatik bir yaklaşım.

Son Düşünceler

Derek DRY'yi bir araç, bir yasa olarak yeniden şekillendirerek kapatır. 7:00'de şöyle ifade eder:

'Onu nasıl uyguladığınızı anlamak meselesi. Ağır bir şekilde uyguluyorsanız, potansiyel olarak daha fazla bağımlılık oluşturuyorsunuz.'

Yani, o doğrulama mantığını, bağlantı stringini veya tekrarlayan kodu ayrı bir yönteme dönüştürmeden önce, bunu yapmanın aslında tüm kod tabanınızı daha sürdürülebilir hâle getirip getirmeyeceğini düşünün — ya da sadece değiştirmeyi zorlaştıracak mı?

Sonuç

Derek Comartin'in C#'daki DRY ilkesinin analizi, görünüşte basit bir kuralın, özenle uygulanmadığında nasıl ters tepebileceğini gösteriyor. Kod örnekleriyle gezip, pratik senaryoları tartışarak ve yazılım tasarımı ilkelerini vurgulayarak, yeniden kullanılabilirlik ve modülerlik arasında gerekli dengeyi ortaya koyuyor.

Geliştirme sürecinizi önemli ölçüde geliştirmek için, unutmayın:

• Belirgin bir sınır içinde redundant kodu yeniden yapılandırmak için DRY'yi kullanın.

• Farklı iş amaçlarına hizmet eden varlıkları DRY yapmayın.

• Mantığı merkezileştirirken bağlamı dikkate alın — özellikle birden fazla yer veya projede.

• Birim testleri ve bağımlılık enjeksiyonunun paylaşılan kodu nasıl etkileyebileceğini düşünün.

Bu dersleri uygulayarak, daha verimli, modüler ve sürdürülebilir C# kodu yazacaksınız — ve kod tabanınızı çoğaltılmış mantık ve karışık bağımlılıkların bir fare yuvasına dönüştürmekten kaçınacaksınız.

Derek Comartin'in tam videosunu daha fazla bilgi için CodeOpinion YouTube kanalından izleyebilirsiniz.