प्रति पैकेज कितने वर्ग? प्रति कक्षा के तरीके? प्रति विधि लाइनें?

Question

मैं जिसके लिए मैं कुछ बड़ा जावा परियोजना लेकिन बहुत कम दृश्यता के लिए एक सामान्य टिप्पणी देना है और अगर वहाँ निर्धारित करने के लिए किसी भी दिशा-निर्देश थे मैं सोच रहा था:

• पैकेज प्रति कक्षाओं की क्या संख्या सही माना जा सकता है, कम, या उच्च (इस प्रोजेक्ट में प्रति पैकेज 3.89 वर्ग हैं, जो मेरे लिए थोड़ा छोटा लगता है),
• प्रति कक्षा के तरीकों की संख्या? (इस परियोजना वर्ग प्रति 6.54 तरीकों ...
• विधि के अनुसार लाइनों की संख्या? (इस परियोजना विधि के अनुसार के बारे में 7 लाइनों है है (सुंदर मेरे लिए बहुत अच्छा लगता है, शायद थोड़ा कम))

मैं चाहिए ध्यान दें कि यह प्रश्न केवल वॉल्यूमेट्री से निपट रहा है। मेरे पास गुणवत्ता उपकरण (चेकस्टाइल, जेडपेन्ड, सीपीडी, पीएमडी, एनसीएसएस) से रिपोर्ट का एक समूह है जो मुझे कोड रिडंडेंसी, कक्षाओं के उपयोग, बग इत्यादि के बारे में अधिक दृष्टि देता है।

Answer 1

स्टीव मैककनेल अपनी पुस्तक कोड पूर्ण में प्रति कक्षा के बारे में 7 विधियों की सिफारिश करता है और किसी विधि में और लाइन नहीं स्क्रॉल किए बिना एक स्क्रीन में देखा जा सकता है।

मुझे प्रति पैकेज कक्षाओं के बारे में निश्चित नहीं है।

मैं इस तरह के विषयों पर अधिक जानकारी के लिए कोड पूर्ण पढ़ने की अत्यधिक अनुशंसा करता हूं।

Answer 2

मुझे लगता है कि इस तरह के आंकड़े बहुत बेकार हैं, प्रति विधि लाइनों को जानना कैसे दिखाता है कि यह परियोजना के लिए कोई उपयोग है या नहीं; मुझे लगता है कि आपको इसके साथ और अधिक दिखना चाहिए:

1. क्या आपके पैकेज कक्षाओं जैसे शामिल हैं?
2. क्या आपकी कक्षाएं इकाई के रूप में स्वयं काम करती हैं?
3. कक्षाओं कक्षाओं के भीतर विधियों को सही और कुशलता से करें?

निश्चित रूप से स्मृति उपयोग के अलावा, इससे कोई फ़र्क नहीं पड़ता कि विधि बड़ी है या नहीं? बहुत ही लंबी विधियों में देखने के लिए दूसरी चीज यह है कि स्टैक्ट ट्रेस उस कार्यक्षमता को पैरेंट विधि में जोड़ने से बड़ा होगा। मैं कोड की लाइनों के आधार पर परियोजनाओं की सफलता को मापने से सावधान रहूंगा।

Answer 3

दुर्भाग्यवश, सॉफ़्टवेयर में गुणवत्ता की कोई पूर्ण (उद्देश्य) धारणा नहीं है। इस प्रकार, इनके लिए कोई "सही" मूल्य नहीं है। हालांकि, यहां दो (व्यक्तिगत) obsevations हैं:

3.89 कक्षाएं/पैकेज बहुत कम है। इसका मतलब है कि आप संकुल के जटिल पेड़ से जूझ रहे होंगे।

7 विधि प्रति पंक्ति: वास्तव में अच्छा लगता है। हालांकि, यदि ये संख्या विधियों की लाइन गिनती को कम करने के जानबूझकर प्रयास के परिणामस्वरूप पहुंची तो आप कई निजी तरीकों के आसपास फैले एक तार्किक कार्य के साथ समाप्त हो गए हैं जो कक्षा को समझना और अधिक कठिन बना देगा (कुछ मामलों में)। वास्तव में CodeComplete-2 में, लेखक एक शोध का हवाला देते हैं जिसने पाया कि विधि चक्र इसकी चक्रवात जटिलता और इसके घोंसले के स्तर से बहुत कम महत्व है।

Answer 4

रॉबर्ट सी मार्टिन, जिन्होंने हाल ही में "क्लीन कोड" पुस्तक जारी की है, बताती है कि प्रति विधि लाइनों की संख्या बिल्कुल छोटी संभव होनी चाहिए। 1-7 लाइनों के बीच अंगूठे का एक अच्छा नियम है।

जेफ बे द्वारा निबंध "ऑब्जेक्ट कैलिस्टेनिक्स" में, द थॉटवर्क्स एंथोलॉजी पुस्तक में भी एक अच्छा बिंदु बनाया जा रहा है। वह 9 सुंदर कट्टर बाधाओं का सुझाव देता है जो आपको लंबे समय तक बेहतर ओओ डेवलपर बना देगा। Read more about them here.

अपने विशिष्ट सवालों के जवाब देने के लिए, इन बाधाओं आप के लिए विशेष रूप से कर रहे हैं: - पैकेज प्रति कोई 10 से अधिक वर्गों - वर्ग

प्रति 50 लाइनों की अधिकतम इन बाधाओं के सभी के लिए आदर्श नहीं हो सकता है आपकी असली परियोजनाएं, लेकिन उन्हें एक छोटी (शौक?) परियोजना में उपयोग करने से आपको एक बेहतर अभ्यास में मजबूर किया जाएगा।

Answer 5

एक उपयोगी डिजाइन दिशानिर्देश कहता है कि प्रत्येक वर्ग को केवल एक चीज करना चाहिए और इसे अच्छी तरह से करना चाहिए। यह आपको प्रति वर्ग की एक निश्चित संख्या नहीं देगा, लेकिन यह संख्या को सीमित करेगा और वर्ग को समझने और बनाए रखने में आसान बना देगा।

विधियों के लिए आप एक समान दृष्टिकोण को अपना सकते हैं और जितना संभव हो सके छोटे तरीकों के लिए लक्ष्य कर सकते हैं, लेकिन कोई छोटा नहीं। इस बारे में सोचें: यदि आप विधि को दो या दो से अधिक विशिष्ट हिस्सों में विभाजित कर सकते हैं तो यह स्पष्ट रूप से उतना छोटा नहीं जितना हो सकता है। छोटे तरीकों को समझना आसान है और इस तरह के कोड को विभाजित करके आपको उच्च स्तरीय तरीकों में बेहतर अवलोकन मिलेगा और निम्न स्तर के तरीकों को विवरण धक्का देंगे।

Answer 6

(ध्यान दें: tl; मेरा असली राय के लिए बहुत नीचे स्थित डॉ उपलब्ध है)

मैं किसी भी बड़े नाम बोली और हमेशा है, क्योंकि यह बहुत ही मामले निर्भर है कि कैसे आप सभी करते हैं कि सही जवाब है कहने के लिए नहीं जा रहा हूँ यह चीज़। उदाहरण के लिए विधियों की संख्या: यदि आप आधुनिक एचडी एलसीडी टीवी के रिमोट कंट्रोलर के लिए एक नियंत्रण सॉफ्टवेयर बना रहे हैं जिसमें लगभग 40-50 बटन हैं, तो आप इसे कक्षाओं में में कैसे तोड़ सकते हैं ताकि आप केवल इतना कह सकें, कक्षा प्रति 7 तरीके?

व्यक्तिगत तौर पर मैं एक वर्ग कुछ उपयोगिता वर्गों के तरीकों के सैकड़ों होने तक खत्म हो सकता है, लेकिन मेरी राय में यह StringUtil.XML.escapeSpecialCharacters(someString) या XMLUtil.escapeSpecialCharacters(someString) से StringUtil.escapeXMLspecialCharacters(someString) की तरह कुछ करने के लिए आसान है, जिसका मतलब है में एक एक्सेसर स्तर के सभी तरीकों को रखने के लिए पसंद करते हैं। हालांकि ये सब ठीक प्रतीत होते हैं, पहला पहला उगता है (कम से कम मेरे दिमाग में, वह है!) क्योंकि यह उस विधि तक पहुंचने का सरल और बहुत आसान तरीका है: आपको यह सोचने की ज़रूरत नहीं है कि आप जिस स्ट्रिंग को संभालने में हैं एक्सएमएल या एक्सएचटीएमएल या जेएसओएन या जो भी हो, आप बस सामान्य तरीकों से एक विधि चुन लेंगे और यही वह है।

पिछले टीवी रिमोट समानता को ध्यान में रखते हुए, मान लीजिए कि आप उन्हें विभिन्न वर्गों में विभाजित करते हैं। यदि हम प्रति वर्ष औसतन इस तरह की विधियों में से 7 विधियों की अनुमति देते हैं और MenuButtons, AdjustmentButtons और 'संख्या चयनकर्ता बटन' जैसे संवेदनात्मक समूहों को रिमोट पर बटन समूहित करने का प्रबंधन करते हैं, तो हम 8 या उससे अधिक कक्षाओं के साथ समाप्त होते हैं। यह वास्तव में एक बुरी चीज नहीं है, लेकिन यह आसानी से थोड़ा भ्रमित हो जाता है, खासकर अगर वे बहुत सावधानी से सनसनीखेज समूहों में विभाजित नहीं होते हैं। बस अपने टीवी रिमोट्स 'आरयूएस इंक कार्यालय के आस-पास की रानों की कल्पना करें: "कौन कहता है कि चालू/बंद बटन एक नियंत्रण बटन है?" "जोकर है जो वॉल्यूम +/- मेनू बटन पर रखता है? PRE/CH (बटन जो वर्तमान और पिछले चैनल और/या छवि स्रोत के बीच स्विच करता है) बटन एक संख्या बटन नहीं है!" "मार्गदर्शिका बटन संदर्भ के आधार पर टीवी गाइड और नेविगेशन मेनू दोनों को खोलता है, हम इसके साथ क्या करने जा रहे हैं !?"

इसलिए आप उम्मीद कर सकते हैं कि इस उदाहरण से कुछ मनमानी संख्या का उपयोग करके स्वयं को सीमित करने के लिए कुछ अनियंत्रित जटिलता लागू हो सकती है और एप्लिकेशन के तार्किक प्रवाह को तोड़ दिया जा सकता है।

इससे पहले कि मैं अपने पिछले दो सेंट में फेंकूं, प्रति विधि लाइनों की संख्या के बारे में एक बात: ब्लॉक को ब्लॉक के रूप में सोचें।प्रत्येक पाश एक ब्लॉक है, प्रत्येक सशर्त एक ब्लॉक है और इतने पर और आगे। कोड की एक इकाई के लिए आवश्यक इन ब्लॉकों की न्यूनतम राशि क्या है, जिसमें एक ही जिम्मेदारी है? यह आपका limiter होना चाहिए, "हर जगह सात" होने की इच्छा नहीं है। पैकेज में कक्षाओं की संख्या, कक्षाओं में विधियों और तरीकों से कोड की रेखाओं से।

तो, मेरा असली राय वास्तव में यह है:: पैकेज में वर्गों की संख्या काफी कम किया जाना चाहिए डॉ;

और यहाँ टीएल है। मैं हाल ही में निम्न कार्य शुरू किया गया है, लेकिन मुझे यकीन है कि अगर मैं इसे करने के लिए रखेंगे नहीं कर रहा हूँ:

• पैकेज foo कार्यान्वयन के लिए इंटरफेस और अन्य आम कक्षाओं में शामिल है।
• पैकेज foo.bar समारोह के लिए कहा इंटरफेस के कार्यान्वयन में शामिल है bar
• पैकेज foo.baz समारोह के लिए कहा इंटरफेस के कार्यान्वयन में शामिल है baz

आमतौर पर इसका तात्पर्य मेरी पूरी संरचना एक सुसंगत है (और सबसे अधिक संभावना कम) वर्गों की संख्या और शीर्ष स्तरीय वर्ग इंटरफेस (और उनकी टिप्पणियां) पढ़कर मुझे अन्य पैकेजों को भी समझने में सक्षम होना चाहिए।

प्रति वर्ग के तरीके: जैसा कि मैंने ऊपर बताया है, सभी की आवश्यकता है। यदि आपकी कक्षा 170 विधियों के बिना नहीं रह सकती है, तो इसे अपने पास दें। रिफैक्टरिंग एक पुण्य है, ऐसा कुछ नहीं जिसे हर समय लागू किया जा सकता है।

प्रति विधि पंक्तियां: जितनी कम हो सके, मैं आम तौर पर प्रति विधि 10 से 25 लाइनों के साथ समाप्त होता हूं और 25 मेरे लिए थोड़ा अधिक होता है, इसलिए मैं कहूंगा कि 10 इसके लिए एक अच्छा संतुलन बिंदु है।