Çok fazla örnek değişkenine sahip olmak yinelenen koda nasıl yol açar?

Kalıplara Yeniden Yapılanmaya Göre :

Bir sınıf çok fazla şey yapmaya çalışırken, genellikle çok fazla örnek değişkeni gösterilir. Bir sınıfta çok fazla örnek değişkeni varsa, çoğaltılan kod çok geride olamaz.

Çok fazla örnek değişkenine sahip olmak yinelenen koda nasıl yol açar?

Çok fazla örnek değişkenine sahip olmak, yinelenen kodla doğrudan ilişkili değildir veya tersi de geçerlidir. Bu ifade, bu genellikte yanlıştır. Yinelenen kod içermeyen iki ayrı sınıf, bir sınıfa ayrılabilir - bu, ayrılmamış sorumluluklara ve çok fazla örnek değişkenine sahip yeni bir sınıf üretir, ancak yine de yinelenen kod yoktur.

Ancak, gerçek dünya eski kodunda çok fazla sorumluluk sahibi bir sınıf bulduğunuzda, temiz kod veya SOLID ilkelerine (en azından bu kodu yazdığı zaman değil) önem vermediğini yazan programcı şansı yüksektir, bu yüzden pek olası değil, orada yinelenen kod gibi diğer kod kokularını bulacaksınız.

Örneğin, "kopyala-yapıştır yeniden kullan" anti-paterni genellikle eski bir yöntemin kopyalanması ve uygun yeniden düzenleme yapılmadan küçük değişiklikler yapılmasıyla uygulanır. Bazen, bu çalışmayı yapmak için, bir üye değişkeni çoğaltmalı ve bu değişkeni biraz değiştirmelidir. Bu olabilir (: çok fazla çok benzer görünümlü örnek değişkenler daha hassas) çok fazla örnek değişkenleri bir sınıfa sonuçlanabilir. Böyle bir durumda, benzer örnek değişkenleri sınıfın başka bir yerinde tekrarlanan kod için bir gösterge olabilir. Ancak, belirttiğiniz gibi, bu yapay bir örnektir ve bundan genel bir kural çıkarmam.

Çok fazla örnek değişkeni çok fazla durum anlamına gelir. Çok fazla durum, her bir durum için yalnızca biraz farklı olan çoğaltılmış koda yol açar.

Bu, alt sınıflar veya kompozisyonlar olması gereken çok şey yapan klasik tek somut sınıftır.

Çok fazla örnek değişkeni olan birkaç sınıf bulun, çok fazla durumu koruduklarını ve her durum için sadece biraz uzmanlaşmış, ancak yeniden kullanılabilir yöntemlere ayrılamayacak kadar kıvrık çok sayıda yinelenen kod yoluna sahip olduklarını göreceksiniz. Bu aynı zamanda en büyük kaynaklardan biridir side effects.

Bu kategoriye girmeyen ve bunu düzeltmenin kolay bir yolu olan en az bir istisna vardır. Immutablenesnelerin bu sorunu yoktur, çünkü bunlar sabit bir durumdur, kıvrık durum yönetimi veya yan etkiler için herhangi bir şans yoktur.

Alıntı yaptığınız ifadenin belirli bir bağlamda görülmesi amaçlanmıştır.

Deneyimlerime göre, "genel olarak birçok örnek değişkeninin yinelenen kodu gösterdiğini" doğrulayamıyorum. Ayrıca, bunun "kod kokularına" ait olduğunu ve çelişkili olduğu iddia edilen kokular olduğunu unutmayın. Buraya bir göz atın:

http://c2.com/cgi/wiki?CodeSmell

Eğlenceli bir şekilde, "çok fazla örnek değişkeni" nin "çok az örnek değişkeni" kadar iyi bir kod kokusu olduğunu göreceksiniz.

Ancak örnek değişkenlerle ilgili sorunlar var, çok az veya çok fazla olsun:

1. Her örnek değişkeni, nesnenin bir tür durumu anlamına gelebilir. Stati her zaman dikkatli bir tedaviye ihtiyaç duyar. Beklenmedik davranışlardan kaçınmak için olası tüm stati kombinasyonlarını kapsadığınızdan emin olmalısınız. Her zaman net bir şekilde açık olmalısınız: Nesnemin şu anda hangi durumu var? Bu açıdan, birçok örnek değişkeni sınıfın sürdürülemez hale geldiğini gösterebilir. Ayrıca bir sınıfın çok fazla statü gerektirdiğinden çok fazla iş yaptığını da gösterebilir.

2. Her örnek değişkeni, hangi yöntemleri değişkeni değiştirdiğini gözetlemenizi gerektirir. Böylece, aniden, yemek pişiren tüm aşçıları artık bilmiyorsunuz. Gece geç saatlerde yorgun bir şekilde programlanmış olanlardan biri, çorbanızı bozacak. Yine: bu değişkenlerin çok fazla içeri girilmesi zor kodlara yol açacaktır.

3. Diğer taraf: çok az örnek değişkeni, birçok yöntemin bilgilerini çok fazla çalışma ve çok fazla parametre ile ele almasına neden olabilir. Bunu, yöntemlerinizin çoğuna belirli bir eşit parametre veriyorsanız hissedersiniz ve tüm yöntemler bu parametre ile bir şekilde çok benzer bir şey yapar. Bu durumda, kodunuz şişmeye başlar. Bazı basit şeyleri bir araya getirmek için birçok ekranı yukarı ve aşağı kaydırırsınız. Burada, bir yeniden düzenleme yardımcı olabilir: bir örnek değişkeni ve bir açık girişi. Ardından, tüm yöntemleri serbest bırakın.

4. Son fakat en az değil: Bir sınıfın birçok örnek değişkeninin her biri kendi ayarlayıcısına ve alıcısına sahipse, diğer sınıfların bu birinci sınıfı doğru şekilde kullanmadığını gösterebilir. " Getters ve setters neden kötü " hakkında bir tartışma var . Kısacası fikir, eğer bir sınıf Rectanglebazı teklifler sunuyorsa getX()ve düzinelerce diğer sınıflar kullanıyorsa rectangle.getX(), o zaman "dalgalanma etkisine" karşı sağlam olmayan bir kod yazıyorsunuz (diğer kodu etkileyen bir kod değişikliğinin ne kadar uzak olduğu). Basitçe gelen türünü değiştirmek ne olur sormak intiçin double? Bu tartışmaya göre, rectangle.getX()çağrıların birçoğu aslındarectanlge.calculateThisThingForMe(). Bu nedenle, dolaylı olarak, çoğaltılmış kod birçok örnek değişkeninden ortaya çıkabilir, çünkü etrafındaki birçok sınıf, sınıf içinde daha iyi taşınması gereken çok benzer şeyler, yani kopyalanmış şeyler yapan birçok alıcı ve ayarlayıcı kullanır.

Birçok veya daha az örnek değişkeni, yazılım büyürken her iki yolu da değiştirerek kalıcı bir değiş tokuş olarak kalır.

Basitçe söylemek gerekirse, kod içindeki endişelerin zayıf bir şekilde ayrılması, modüler olmayan koda, zayıf yeniden kullanıma, çoğaltılmış koda yol açar.

Asla işlevselliği tekrar etmeye çalışmazsanız, yinelenen kod elde edemezsiniz ve birçok örnek değişkeni sorun olmaz.

İşlevselliği tekrarlamaya çalışırsanız, modüler olmayan monolitik kod tekrar kullanılamaz. Çok fazla şey yapar ve sadece yaptıklarını yapabilir. Benzer bir şey yapmak, ancak aynı şeyi yapmak için, yekpare kodu kırmak yerine kesmek ve yapıştırmak "daha kolay". Deneyimler programcılar yinelenen kodun cehenneme giden yol olduğunu bilir.

Dolayısıyla, birçok örnek değişkeninin kendisi sorunun temel nedeni olmasa da, sorunun gelmesi güçlü bir "koku" dur.

"Çok geride kalamaz" dili, "mutlaka takip etmeli" demekten daha zayıftır, bu yüzden yazar bunun olması gerektiğini iddia etmez, ancak sonunda olur; işlevselliği yeniden kullanmanız gerekiyor ancak kod modüler olmadığından kullanamıyorsanız.