C# Statik Değişken ve Yöntemler Kötü mü? Derek Comartin Açıklıyor (Video Açıklaması)

Bir Statik Metodu Sorunlu Yapan Nedir?

Videonun başında Derek, Is18YearsOrOlder adında bir statik metoda dalıyor. Bu metot bir DateTime doğum tarihini alır ve birinin en az 18 yaşında olup olmadığını denetler. Mevcut tarihi karşılaştırmak için DateTime.UtcNow kullanılır. Yeterince basit, değil mi?

Ancak Derek'in işaret ettiği gibi, bu metot determinizm dışıdır. 0:50'de, DateTime.UtcNow kullanmanın, metodu ne zaman çalıştırdığınıza bağlı olarak farklı sonuçlar vereceğini vurguluyor. Bu, birim testlerinde büyük bir sorun ve kodda beklenmeyen davranışlara neden oluyor.

Bu durumda, metod saf bir işlev gibi görünse de, aslında değildir. Derek, saf bir metodun, her seferinde aynı parametrelerle çağrıldığında aynı değeri döndürmesi gerektiğini açıklar. Ancak burada, mevcut tarih sürekli değişiyor, dolayısıyla dönüş değeri de öyle.

Bu, gerçek zamanlı verilere veya uygulama alanı durumuna dayanan bir public statik metodun her ne kadar kullanışlı olsa da yan etkiler getirebileceğini gösterir.

Statik Metotları Test Edilebilir ve Öngörülebilir Yapma

Derek'in bir sonraki noktası çok önemlidir: Determinizmi düzeltebilmek için DateTime.UtcNow bağımlılığını kaldırabiliriz. Bunun yerine, Derek bir statik sınıf veya bir arabirim uygulaması kullanarak bir zaman sağlayıcıyı nasıl ekleyeceğini gösteriyor. Bu, fonksiyonu deterministik yapar — aynı girdiyi geçtiğinizde her zaman aynı çıktıyı alırsınız.

Onun PlaceOrder sınıfında, Cuma günlerinde işlenen siparişlerin %50 indirim aldığı bir sahte tarih sağlayıcı tanıtıyor. Bu, sistem zamanına bağlı olan mantıklıları sert kodlamak yerine metodu daha güvenilir ve test edilebilir hale getirir.

Derek, davranışı izole ederek ve iş mantığı içinde doğrudan statik metotlara başvurmaktan kaçınarak, temiz kodu nasıl koruyacağını ve test edebilirliği nasıl muhafaza edeceğini gösteriyor.

Sıkı Bağlılık ve Statik Metotlar

Derek bu noktada, statik metotlara güvenmenin genellikle sıkı bağlılık getirdiği konusunda uyarıyor. Eğer doğrudan DateTime.UtcNow kullanıyorsanız, bu uygulamaya bağlı kalıyorsunuz — onu değiştirmeniz veya taklit etmeniz mümkün değil.

Bu bir problemdir çünkü bu tür statik üyeler, uygulamanızda küreseldir. Kod tabanınız yoğun şekilde statik alanlar veya statik özellikler kullanıyorsa, davranışı değiştirmek veya bağımlılıkları eklemek zorlaşır, nesne yönelimli programlamanın temel prensiplerini ihlal eder.

Ayrıca esneklik kaybedersiniz çünkü statik alanı, bir örnek değişken veya enjekte edilen hizmetle değiştiremezsiniz.

Statik Değişkenlerle Küresel Durum Sorunu

Şimdi Derek dikkatini statik değişkenlere çeviriyor ve bu noktada konuşma ciddileşiyor.

Küresel bir sınıfta bir statik önbellek kullandığı bir örnek sunuyor. Statik değişkenlerle ilgili en büyük sorunun bilinmeyen durum olduğunu açıklar. Çalışma zamanında, statik alanınızın başlatılıp başlatılmadığını bilemezsiniz. Bu belirsizlik, özellikle değişken bir statik int veya string adı olduğunda oldukça risklidir.

Geliştiricilerin yalnızca değişkenin bir kopyası olduğunu ve bu değişkenin farklı iş parçacıkları arasında paylaşıldığını varsaydığı ve iş parçacığı güvenliğini hesaba katmayı unuttuğu durumlar daha da kötüleşir.

İş Parçacığı Güvenliği ve Çok İş Parçacıklı Kodda Statik Alanlar

Derek başka bir sorun getiriyor: çok iş parçacıklı ortamlarda statik değişkenlerin kullanımı. Static bir List'ın Parallel.For ile eşzamanlı kullanıldığı bir örnek veriyor. Kod çöküyor çünkü statik alan iş parçacığına karşı güvenli değil.

Bunu çözmek için, .NET'te kullanılabilir bir iş parçacığına karşı güvenli koleksiyon olan ConcurrentBag'a geçiyor. Bu, çoklu iş parçacığı boyunca statik verilere güvenli erişim sağlıyor.

Mesajı açık: İş parçacıkları arasında statik değişkenler kullanıyorsanız, bunların iş parçacığına karşı güvenli olduğundan emin olun. Aksi halde, programınız beklenmedik şekilde işlev görebilir ya da hatta çökebilir.

Statik Metotların Güvenli Kullanımı

Derek daha sonra bir statik metodun güvenli ve etkili bir kullanımını paylaşıyor: basit bir yardımcı metot olan MilesToKilometers. Bir int mil alır ve dönüşümden sonra bir double değeri döndürür. Bu metot deterministik — aynı int değeri için her zaman aynı sonucu alırsınız.

Bu tür bir metot, statik olmayan alanlara dayanmaz, paylaşılan verileri değiştirmez ve bilinmeyen bir duruma karışmaz. C#'da statik anahtar kelimenin doğru kullanımına harika bir örnektir.

.NET Bağlamında Statiği Anlamak

C#'da, statik anahtar kelimesi sınıflara, alanlara, metotlara, yapıcılara ve özelliklere uygulanabilir. Derek dolaylı olarak aşağıdaki kavrama değinir:

• Statik sınıf: Örneklenemeyen ve yalnızca statik üyeler içerebilen bir sınıf.

• Statik alanlar: statik anahtar kelime ile beyan edilen — uygulama alanı başına yalnızca bir kopya vardır.

• Sabit kurucu: Sınıf ilk erişildiğinde yalnızca bir kez çalışır.

• Static void Main: Çoğu C# uygulamasının giriş noktası, sabit yöntemlerin neden önemli olabileceğini göstermektedir.

• Static int, static string: Sınıfın tüm örneklerine ortak veri saklayan statik alanlar örnekleri veya aslında hiç örnek gerektirmez.

Her nesne oluşturduğunuzda çalışan örnek kurucuların aksine, statik kurucu sınıf seviyesindeki kaynakları yalnızca bir kez başlatır.

Bu ayrım, geliştiricilerin ne zaman örnek değişken veya statik değişken kullanacağını veya paylaşılan üye değişkenlerini kapsüllemek için ne zaman özellik erişicilerini kullanacağını belirlemelerine yardımcı olur.

Derek'ten Son Çıkarımlar

Derek, geliştiricilerin statik üyelere karşı neden temkinli davrandıklarını özetliyor:

• Sıkı bağ — o statik yöntem veya alanın davranışına bağlı kalırsınız.

• Nondeterministik davranış — test edilmesi zor, kolayca bozulabilir.

• Global değişken durum — değerin ne olduğunu veya kimin değiştirdiğini bilmiyorsunuz.

• Eşzamanlılık sorunları — çoklu iş parçacıklı kodda paylaşılan verilere güvensiz erişim.

Yine de, Derek'in dediği gibi, statik kötü değildir. Doğru kullanıldığında güçlüdür—özellikle yardımcı fonksiyonlar, paylaşılan sabitler veya gerçekten global ayarlarda. Yalnızca durumu dikkatli bir şekilde yönetmeli ve değişken veya sistem spesifik davranışa bağımlı olmaktan kaçınmalısınız.

Sonuç

C# 'da statik değişkenler ve yöntemler iki ucu keskin kılıçtır. Derek Comartin açıkça açıkladığı gibi, doğası gereği kötü değillerdir — ancak düşünceli bir kullanım gerektirirler. Paylaşılan verilere veya nesne durumuna bağlı olmayan işlevselliğe ihtiyaç duyduğunuzda statik alanları ve statik sınıfları kullanın. Ancak, zamana, sistem durumuna bağlı şeyler veya esneklik gerektiren şeyler için kullanmaktan kaçının.

Bu yüzden bir nesne oluşturmadan veya bir statik alana erişmeden önce, kapsam, test edilebilirlik, iş parçacığı güvenliği ve kodun bir kopyaya mı yoksa birden fazla örneğe mi ihtiyaç duyduğunu düşünün.

Derek Comartin'in tam videosunu onun CodeOpinion YouTube kanalında izleyin. Temiz mimari, yazılım tasarımı ve gerçek dünya C# uygulamaları hakkında daha fazla bilgi bulacaksınız.