Sınıf üyelerini mi tercih ediyorsunuz yoksa içsel yöntemler arasında tartışmalar mı?

Bir sınıfın özel bölümünde, birden fazla özel yöntem tarafından kullanılan bir değer olduğunu varsayalım. İnsanlar bunu sınıf için bir üye değişkeni olarak tanımlamayı mı yoksa her bir yönteme argüman olarak geçirmeyi mi tercih ediyorlar - ve neden?

Bir yandan, bir sınıftaki indirgeme durumunun (yani üye değişkenleri) genellikle iyi bir şey olduğuna dair bir argüman görebildim, ancak aynı değer bir sınıf boyunca tekrar tekrar kullanılıyorsa, bu bir yöntem gibi görünüyor. Başka bir şey değilse, kodu gözle görülür şekilde daha temiz hale getirmek için sınıfın durumu olarak temsil edilmek üzere aday.

Düzenle:

Ortaya çıkan yorumların / soruların netleşmesi için, sabitlerden bahsetmiyorum ve bu, başkalarıyla konuştuğum bir varsayımdan ziyade, belirli bir durumla ilgili değil.

OOP açısını bir anlığına görmezden geldiğimde, aklımdaki özel kullanım durumu şuydu (yalnızca sözde kodu daha temiz hale getirmek için referansla geçildiğini varsayalım)

int x
doSomething(x)
doAnotherThing(x)
doYetAnotherThing(x)
doSomethingElse(x)

Yani demek istediğim, çoklu fonksiyonlar arasında ortak olan bazı değişkenler olduğu anlamına geliyor - aklımdayken bunun daha küçük fonksiyonların zincirlenmesi olmasından kaynaklanıyordu. Bir OOP sisteminde, bunların tümü bir sınıfın yöntemleri ise (örneğin büyük bir yöntemden çıkarma yöntemleriyle yeniden yapılanma nedeniyle), bu değişken hepsinin etrafından geçirilebilir veya bir sınıf üyesi olabilir.

Değer, sınıfın bir özelliği ise sınıfta tutun, aksi takdirde dışarıda tutun. Önce sınıf yöntemlerinizi tasarlamazsınız, önce özelliklerini tasarlarsınız. Bu özelliği sınıf içine ilk etapta koymayı düşünmediyseniz, bunun muhtemelen bir nedeni vardır.

Ölçeklenebilirlik açısından yapabileceğiniz en kötü şey, kolaylık sağlamak için kodunuzu değiştirmektir. Er ya da geç, kodunuzun şişirilmiş ve kopyalandığını göreceksiniz. Ancak bazen kabul etmeliyim ki bu kuralı çiğniyorum ... Kolaylık çok çekiciydi.

Devleti aslında çağrılar arasında tutmanız gerekmiyorsa (ve görünüşe göre sormazsınız veya soruyu sormazsınız), o zaman değerin bir üye değişkeni yerine bir argüman olmasını tercih ederim, çünkü hızlı bir bakış yöntemin imzasında, argümanı kullandığını söylerken, yöntem tarafından hangi üye değişkenlerin kullanıldığını hemen söylemek biraz zor. Özel üye değişkenlerin ne için olduğunu belirlemek de her zaman hızlı değildir.

Bu yüzden normalde üye değişkenleri kullanan kodun daha temiz olduğunu kabul etmem, ama yöntem imzaları elinden çıkarsa, bir istisna yapabilirim. Bu değerli bir soru, ancak her durumda projenin destekleyeceği bir şey değil.

Soruyu sorduğunuz için teşekkürler, bunu da sormak istedim.

Bunu düşündüğümde, neden argüman olarak iletmenin bazı avantajları var

• test edilmesi daha kolay -> bakımı daha kolaydır (son noktayla ilgili)
• yan etkisi yok
• anlamak daha kolay

Örneğin, noktanızı açıkça görüyorum - biri Excel belgesini ayrıştırıyor (örneğin POI kütüphanesini kullanıyor) ve satır örneğini bu satırla çalışması gereken her yönteme aktarmak yerine, yazarın üye değişkeni var currentRowve onunla çalışıyor.

Bu anti-patern için bir isim olmalı derdim, değil mi? ( burada listelenmemiş )

Belki de bu değeri paylaşan tüm yöntemleri içeren yeni bir sınıf çıkarmalısınız. Elbette en üst düzey yöntem yeni sınıfta herkese açık olacak. Test için bu yöntemi ortaya çıkarmak yararlı olabilir.

Her zaman birlikte geçirilen iki veya daha fazla geçici seçeneğiniz varsa, o zaman neredeyse kesinlikle yeni bir sınıf çıkarmalısınız.

İnsanlar bunu sınıf için bir üye değişkeni olarak tanımlamayı mı yoksa her bir yönteme argüman olarak geçirmeyi mi tercih ediyorlar - ve neden?

Ne sorduğunuzu anlarsam: Bir sınıftaki yöntemler, tanımlamanın özelliğine göre uygulama ayrıntılarına göredir, bu nedenle herhangi bir üyeyi doğrudan herhangi bir yöntemle kullanma konusunda hiçbir yeteneğim yoktur.

Bir yandan, bir sınıftaki azaltma durumunu (yani üye değişkenleri) genellikle iyi bir şey olduğu konusunda bir argüman görebiliyordum ...

Bir private static finalsabit tanımlamak için bir ilan hiçbir yanlış yoktur . Derleyici, bazı optimizasyonları göz önünde bulundurarak değeri kullanabilecek ve sabit olduğu için, sınıfa gerçekten durum eklemeyeceklerdir.

Her ne kadar aynı değer bir sınıf boyunca tekrar tekrar kullanılıyorsa da ... yöntemler

Sembolik olarak (örn. BLRFL_DURATION) Başvurabilmek ve metotlarınıza ekstra argümanlar eklemek zorunda kalmamak kodunuzu daha okunaklı ve dolayısıyla daha da korunabilir hale getirecektir.

Eğer değer değişmezse, tanım gereği bir sabittir ve sınıf içinde kapsüllenmelidir. Bu durumda, bir nesnenin durumunu etkilediği düşünülmez. Durumunuzu bilmiyorum ama trigonometride PI gibi bir şey düşünüyorum. Böyle bir sabitin argümanını iletmeye çalışırsanız, müşteri yanlış bir değeri veya yöntem (ler) in beklediği gibi aynı doğrulukta olmayan bir değeri geçerse sonucu hataya maruz bırakıyor olabilirsiniz.