DRY Prensibi C#: Kod Yinelemesi Kod Tabanınıza Zarar Veriyor - Derek Comartin Tarafından Açıklanıyor

Derek Comartin

C#'ta sürdürülebilir kod yazmaktan bahsettiğimizde, sıkça ortaya çıkan temel kavramlardan biri DRY prensibidir — Don't Repeat Yourself. Yazılım geliştirmede kod tekrarını ortadan kaldırmayı, kod çoğaltımını azaltmayı ve kod sürdürülebilirliğini artırmayı hedefleyen bir sütundur.

Ancak birçok tasarım ilkesi gibi, DRY yanlış anlaşılabilir ve hatta yanlış uygulanabilir. DRY ilkesi neden kod tabanınızı berbat mı ediyor? videosunda, CodeOpinion.com'dan Derek Comartin, DRY ilkesinin nasıl kullanılması ve kullanılmaması gerektiğine dair açık ve gerçekçi bir bakış sunar — özellikle .NET Core veya benzer ekosistemlerde geliştirme yaparken.

Bu makalede Derek'in açıklamalarına derinlemesine dalacağız, videodan geçen örneklerini ve yorumlarını adım adım inceleyerek. Visual Studio'da yeni bir projeye başlamış olun, mevcut bir kod tabanını sürdürüyor olun, ya da daha iyi kod tekrar kullanılabilirliği için yeniden düzenleme yapıyor olun, Derek'in içgörüleri pratik ve alakalıdır.

DRY Prensibi Tanımlandı

Derek, videonun başlangıcında birçok geliştiricinin karşılaştığı durumu çerçeveler: değiştirilmesi zor olan bir sistemle uğraşma — tekrarlanan kod ve gereksiz mantık yığını karmaşık bir hale gelir.

C#'ta DRY ilkesini kod tekrarını azaltmak için bir strateji olarak tanıtır, ancak bunun sıkça yanlış yorumlandığını belirtir. Derek, 0:28'de şöyle açıklar:

"DRY başarıyla uygulandığında, sistemin herhangi bir tek unsurunda yapılan değişiklik, mantıksal olarak ilgisiz unsurlarda değişiklik yapılmasını gerektirmez."

Bu ayrım kritiktir. DRY prensibi, sadece kod tekrarlığını önlemeyi değil, aynı zamanda endişelerin ayrılması ve uygun kod tekrar kullanılabilirliğini teşvik etmeyi hedefler — sürdürülebilir, kuru kodlar test edilmesi ve yeniden düzenlenmesi daha kolaydır.

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

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

• ShipDistance

• TollDistance

Her biri mil cinsinden mesafeleri hesaplar, ardından bu mesafeleri kilometreye çevirir — her iki yöntemde de aynı mantığı kullanarak. Bu, klasik bir kod tekrarıdır.

Derek, aynı kod parçasının birden fazla yerde yer almak yerine, dönüştürme mantığını özel bir metot olan — MilesToKilometers() — içine çıkarmayı gösterir; kodu tekrar kullanılabilirlik için yeniden düzenlemenin temel ama etkili bir yolu olarak.

Bunu, tipik bir konsol uygulaması yapısını kullanarak gösterir: bir sınıf Program ile bir static void Main. Bu, tüketiciden girdi alma senaryolarını test etmek veya bir gösterim yapmak gibi geliştirme yaparken birçok geliştiricinin kullandığı bir yapı türüdür.

DRY ve Aşırı Bağlanma

Mantığı tekrar kullanılabilir bir metoda veya ayrı bir sınıfa soyutlamak ideal görünebilir, ancak Derek dikkatli olunmasını önerir. DRY'ın aşırı kullanılması, özellikle tüm uygulama boyunca, tehlikeli seviyelerde bağlanma ile sonuçlanabilir.

Örneğin, birden fazla proje tarafından kullanılan bir paylaşılan araç kutusu içine dönüştürme mantığını yerleştirdiniz ve daha sonra yuvarlama davranışını veya ondalık hassasiyetini değiştirirseniz, bu değişiklik birçok alanı beklenmedik bir şekilde etkileyebilir. Derek, 2:31'de şöyle der:

"Müşteriler iki ondalık basamak bekliyor mu? Bunu sıfır olarak değiştirsek ne olur?"

Bu, çeşitli alanlarda kullanılan kesişen bir endişedir — birçok sistemi tarafından tekrar kullanılan mantık — ve bu, erken veya net sınırlar olmadan merkezi hale getirmenin riskini gösterir.

Gevşek Bağlantı İlkesi

Yanlış Giden DRY'dan Kod Dağılımı

DRY kötü kullanıldığında ortaya çıkan başka bir sorun, kod yığınıdır — her şeyi soyutlamaya çalışmanın şişkin araç sınıflarına veya aşırı generik yöntemlere yol açtığı durumlar. Derek, mantığının aşırı DRY hale getirilmesinin yarardan çok zarar getirebileceğini, özellikle büyük sistemlerde bir alanındaki hata düzeltmelerinin paylaşılan bağımlılıklar nedeniyle diğerlerini bozabileceğini uyarır.

Derek'e göre anahtar, ne zaman kod paylaşılmaması gerektiğini bilmektir — özellikle sıkı bağlı modüllerle sonuçlanıyorsa. DRY bir kural değil; bir kılavuzdur ve bağlamla kullanılmalıdır.

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

Derek, geliştiricinin ortak bir eğilimini tanımlar: sistemleri tamamen Truck, Order, Driver, ve Shipment gibi varlıklar etrafında organize etme. Farklı yöntemler arasında aynı sınıfı veya nesneyi tekrar kullanmak cazip olabilir, ancak bu genellikle kavramları tekrarlamaya ve istenmeyen bağlanmaya yol açar.

Veri yapılarının değil, iş yeteneklerinin mimariyi yönlendirmesi gerektiğini savunur. Örneğin, "bir siparişi yönlendirmek" "bir treyler'ı sökmek" ile ilgili olsa da farklı bir endişedir.

4:45'te Derek şöyle açıklar:

"Sisteminizdeki tek bir varlık, birden fazla kavramın temsilcisi olmamalıdır."

Bu, daha derin bir mimari içgörünün altını çizer: aynı adı taşıyan varlıklar (Vasıta, Treyler) farklı iş akışlarında farklı sorumlulukları temsil edebilir. Onları birbirinin yerine kullanmak, kafa karışıklığı yaratır ve ilişkisiz iş mantığını sıkı bir şekilde bağlar.

DRY ve İş Yetenekleri

Bunu çözmek için Derek, iş yetenekleri etrafında uygulamaları yapılandıran bir model olan Dikey Dilim Mimarisini (VSA) tanıtır. Her "dilim", belirli bir eylem veya kullanım durumu için gereken her şeyi içerir — istekten veri tabanına kadar — kapsüllenmiş ve kendine yeten biçimde.

Derek, bir dilim içinde DRY kodunun iyi olduğunu, ancak dilimler arasında DRY uygulamanın dolanmış bağımlılıklara yol açabileceğini vurgular. 6:44'te ekler:

"Sadece bağlanmayı azalmak, uyumu artırmakla ilgili... ve bunu yapmanın bir yolu şu şekildedir: sınır içinde kavramları tekrarlamamak." Bu sınır temelli düşünce size esneklik verir.

Bir dilimde tam bir alan modeli olabilir, diğerinde ise sadece hafif bir veri modeli olabilir. Bu, dilimin ihtiyaçlarına bağlıdır — Pragmatik Programcı felsefesi ile uyumlu pragmatik bir yaklaşımdır. Derek, DRY'ı bir araç, bir yasa olarak değil, yeniden çerçevelerken kapanır.

Son Düşünceler

7:00'de şöyle der: "Sadece nasıl uyguladığınızı anlamakla ilgili.

Yoğun bir şekilde uygularsanız, potansiyel olarak daha fazla bağlanmanız olur." O doğrulama mantığını, bağlantı dizisini veya tekrarlayan kodu ayrı bir metoda dönüştürmeden önce, bunu yapmanın tüm kod tabanınızı daha sürdürülebilir hale mi getireceğini — yoksa sadece değiştirmenin zor mu hale getireceğini düşünün.

Derek Comartin'in C#'ta DRY ilkesini ele alışı, dikkatle ele alınmazsa basit bir kuralın nasıl geri tepebileceğini gösterir.

Sonuç

Kod örnekleriyle, pratik senaryoları tartışarak ve yazılım tasarım ilkelerini vurgulayarak, yeniden kullanılabilirlik ve modülerlik arasında ihtiyaç duyulan dengeyi ortaya koyar. Geliştirme sürecinizi önemli ölçüde geliştirmek için, unutmayın:

• DRY'ı, belirgin bir sınır içinde tekrarlayan kodu yeniden düzenlemek için kullanın.

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

• Mantığı merkezi hale getirirken bağlamı göz önünde bulundurun — özellikle birden fazla yer veya proje üzerinden.

• Birim testi düşünün ve bağımlılık enjeksiyonunun paylaşılan kodu nasıl etkileyebileceğini göz önünde bulundurun.

Bu dersleri uygulayarak, daha verimli, modüler ve sürdürülebilir C# kodu yazarsınız — kod tabanınızı tekrarlayıcı mantık ve dolanmış bağımlılıklarla dolu bir fare yuvasına dönüştürmekten kaçınırsınız.

Derek Martin'in tam videosu için CodeOpinion'ın YouTube kanalında daha fazla içgörü bulabilirsiniz.

[{academy-video-youtube({"vid": "QoK7jSZ-viw", "start_time": "0", "title": "Enums kötü değil.