Deneyiminize göre, Java'da bir sınıf için kaç kod satırının çok fazla olduğuna dair yararlı bir kural nedir?
Açık olmak gerekirse, satır sayısının belirli bir sınıfta neyin olması ve neyin olmaması gerektiği için kullanılacak gerçek standarda yakın olmadığını biliyorum. Sınıflar, uygun OOP felsefelerine (kapsülleme, vb.) Göre tasarlanmalıdır.Yani, bir kural, yeniden düzenleme hususları için faydalı bir başlangıç noktası sağlayabilir (örn. "Hmmm, bu sınıf >> kod satırları var; muhtemelen okunamıyor ve kapsüllemenin berbat bir işini yapıyor, bu yüzden bir noktada yeniden düzenlenmesi gerekip gerekmediğini görmek isteyebilirim ").
Flip tarafında, belki de hala OOP tasarım iyi itaat ve uzunluklarına rağmen okunabilir ve bakımı yapılabilir çok büyük sınıf örnekleri ile karşılaştınız mı?
İlgili, yinelenmeyen işlev başına satırlarla ilgili sor .
Bazı ilginç metrikler:
junit uygunluk testiNG tam jdepend karınca Tomcat ----- -------- ------ --- ------- --- - ----- max 500 498 1450 355 668 2168 5457 [.____. ortalama 64.0 77.6 62.7 95.3 128.8 215.9 261.6 min 4 6 4 10 20 3 12 [.____. sigma 75 76110 78 129261369 Dosyalar 90632 1152 69 55 954 1468 [.____. Toplam satırlar 5756 49063 72273 6575 7085 206001 384026 [.____]
Ben bir kriter olarak FitNesse kullanıyorum çünkü yazmakla ilgim vardı. FitNesse'de ortalama sınıf 77 satır uzunluğundadır. Hiçbiri 498 satırdan uzun değildir. Ve standart sapma 76 çizgidir. Bu, sınıfların büyük çoğunluğunun 150 satırdan az olduğu anlamına gelir. 5000 çizgiyi aşan bir sınıfı olan Tomcat'in bile çoğu sınıfı 500 çizgiden azdır.
Bu göz önüne alındığında, aşağıda kalmak için muhtemelen 200 satırı iyi bir kılavuz olarak kullanabiliriz.
Benim için kod satırları bu bağlamda önemsizdir. Her şey bu sınıfa değiştirmek için gelmemizin farklı nedenlerinin sayısıyla ilgili.
Bir Kişiyi onaylamak için kuralları değiştirmek istediğimde bu sınıfa gelirsem, bir Emri onaylama kurallarını değiştirmek için aynı sınıfa gelmek istemiyorum, ya da buraya nerede olduğumu değiştirmek istemiyorum Kişiyi ısrar etmek.
Bununla birlikte, eğer bunu hedeflerseniz, nadiren 200 satırdan fazla sınıf bulacaksınız. Geçerli nedenlerle olacaklar, ancak nadir olacaklar. Kırmızı bayraklı bir metrik arıyorsanız, o zaman bu başlamak için kötü bir yer değildir; ama bir kural değil, bir rehber yapın.
Özür dilerim ama birçok cevabın "gerçekten önemli olmadığını" belirttiğine çok şaşırdım. Bir sınıfta kaç satır olduğu çok ÇOK önemlidir. Neden? Bu ilkeleri good Java kodu yazarken düşünün ...
İçinde çok satır bulunan sınıflar büyük olasılıkla tüm bu ilkeleri ihlal edecektir.
"Gerçekten önemli değil" diyenlere ... 5000'den fazla çizgisi olan bir sınıfı anlamaya çalışmak sizin için ne kadar eğlenceli oldu? Veya, değiştirmek için? Bunun eğlenceli olduğunu söylüyorsanız, acıya karşı garip bir yakınlığınız var ...
İçinde 1000'den fazla satır olan herhangi bir sınıfın en azından yukarıdaki ilkeleri nasıl ihlal ettikleri ve muhtemelen birkaç "off-shot" sınıfına ayrıldıkları konusunda sorgulanabilir.
Yorumlarım Martin Fowler, Joshua Bloch ve Misko Hevery gibi yazarları okumak ve incelemek üzerine kurulu. Onlar iyi Java kodu yazmak için danışmak için mükemmel kaynaklardır.
Bir sonraki adamı (birkaç yıl içinde siz olabilirsiniz) bir iyilik yapın ve içinde daha fazla satırdan daha az olan sınıflar yazmaya çalışın.
Çizgi sayısına değil, karmaşıklığa bağlıdır. Anlaması kolay ve tam olarak bir şey yapan ve iyi yapan büyük aptal rutinleri yazdım, ancak yüzlerce satır devam etti. Anlaması zor (ve hata ayıklama) oldukça kısa fonksiyonlar yazdım.
Bakabileceğiniz bir diğer şey, bir sınıftaki genel işlevlerin sayısıdır. Bu bir uyarı işareti de olabilir.
İyi sayım yok, ama dükkanınızda yararlı şeyler yapan bazı iyi kodlara bakmanızı ve bunu temel almanızı öneririm. Kesinlikle en uzun sınıflara ve en büyük API'lara bakmalısınız.
Doğru cevap 42. Şaka yapıyorum.
Aslında, sınıf başına önerilen maksimum satır sayısı 2000 çizgiler.
1999'dan beri "Java Kod Kuralları" bunu şöyle ifade etmiştir:
2000 satırdan uzun dosyalar hantaldır ve kaçınılmalıdır.
Java icat edildiğinden beri Sun/Oracle Kodlama kurallarına uyulduktan sonra, sınıf başına satırlardaki bu kuralın makul olduğunu gördüm. Java = Kod uygun olmalı ... Ve eğer 2000'in üzerine çıkarsa, sınıfın işe ihtiyacı olduğunu söyleyerek en üste bir TODO koyun.
En kötü şey, programcıların her sınıfta neredeyse hiçbir gerçek işlevsellik olmadan çok fazla küçük küçük sınıf oluşturmasıdır. "Kompozisyonu İyileştirme" tavsiyesini göz ardı eden programcılar, büyük sınıf probleminden çok daha kötü olan karmaşık nesne modelleri yaratan yüzlerce miras sınıfı yaratırlar (en azından genellikle ilgili bir sınıf adıyla işlevselliği korurlar).
Sınıf çok farklı şeyler yapıyorsa çok fazla kod satırı vardır. Esasen, sınıflar için Tek Sorumluluk ilkesini izlerseniz, sınıfın ne kadar büyüyeceğinin bir sınırı vardır.
Fiziksel sınırlamalara gelince (kaynak: Sınıf dosya biçimi Java5 ):
Kısacası, sınıf dosyası herkes boyutundan çok daha büyük olabilir. Tek sorumluluk ilkesine bağlı kalırsanız, sınıf dosyalarınız doğru boyutta olacaktır.
Temiz Kod:
Sınıflar Küçük Olmalı!
Sınıfların ilk kuralı küçük olmalarıdır. Sınıfların ikinci kuralı, bundan daha küçük olmalarıdır. Hayır, aynı metni İşlevler bölümünden tekrarlamayacağız. Ancak fonksiyonlarda olduğu gibi, sınıf tasarlama söz konusu olduğunda birincil kural daha küçüktür. Fonksiyonlarda olduğu gibi, acil sorumuz her zaman “Ne kadar küçük?”
** Fonksiyonlarla fiziksel çizgileri sayarak boyutu ölçtük. Sınıflarda farklı bir ölçü kullanıyoruz. Sorumlulukları sayıyoruz. **
Bir sınıfın adı, hangi sorumlulukları yerine getirdiğini açıklamalıdır. Aslında, adlandırma muhtemelen sınıf büyüklüğünü belirlemenin ilk yoludur. Bir sınıf için kısa bir isim çıkaramazsak, muhtemelen çok büyüktür. Sınıf adı ne kadar belirsiz olursa, çok fazla sorumluluğa sahip olma olasılığı o kadar yüksektir. Örneğin, İşlemci veya Yönetici veya Süper gibi gelecekteki kelimeleri içeren sınıf isimleri genellikle sorumlulukların talihsiz bir şekilde toplanmasını ima eder.
Sonra:
Sonunda yönetilebilir boyutta bir sınıfla karşılaşacaksınız.
Daha iyi bir metrik kullanmayı deneyin.
Bunun bir örneği ABC Metrik. Bu, kod tarafından ne kadar iş yapıldığının bir ölçüsüdür.
Satır sayısı sınıf kalitesi için oldukça zayıf bir metriktir. Benim için, (diğerlerinin de belirttiği gibi) herkese açık yöntemlere ve halka açık tüm özelliklere (Java'daki kamu alıcıları/belirleyicileri) bakmayı seviyorum. Dikkatimi çekebileceği zaman için havadan bir numara çıkarmak zorunda kalsaydım, her biri 10'dan fazla olduğunda söyleyebilirim. Gerçekten, eğer özellikleri veya yöntemleri yaklaşık 5 daha fazla, ben bir göz atın ve sık sık refactor için yollar bulmak, ama 10 üzerinde bir şey genellikle bir şey kötü maruz kalma olasılığı bir uyarı işaretidir.
Bu tamamen başka bir konuşma, ama özel yöntemler ve alanlar benim için daha az koku, bu yüzden satır sayısına çok katkıda bulunuyorlarsa, o kadar endişeli olmayabilirim. En azından, nesneyi uzaktan manipüle eden bazı Tanrı denetleyicilerinin olmadığını, bu da oldukça sorunlu bir tasarım problemi olduğunu gösteriyor.
Sınıfınızın sınıf dışında yazılan sorun alanına giren herhangi bir satır, bir satır çok az ve yaşadığı sınıfta çok fazladır. Bir sınıfı bir konu olarak düşünün. Onu örtmelisin. Mümkün olduğunca kısaca idealdir, ancak 500 satır alırsa, 500 satır alır. Bu satırların 100'ü başka bir konuyu kapsıyorsa, başka bir yere aittirler. İç sınıflar olarak sınıf içinde daha küçük alt alanlara ayrılmak mantıklıdır, ancak sadece sınıfın dışındakileri başka yerlerde kullanmışlarsa tanımlarım.