मैंने हाल ही में एक जावा एप्लिकेशन को देखा जिसकी बहुत अच्छी तरह से तैयार पैकेज संरचना थी। कई पैकेजों में केवल एक या दो वर्ग और कई उप-पैकेज होते हैं। इसके अलावा कई पैकेजों में वास्तविक वर्गों की तुलना में अधिक उप पैकेज शामिल थे।क्या एक अच्छी तरह से तैयार पैकेज संरचना अच्छी या बुरी चीज है?
क्या यह एक अच्छी या बुरी चीज है?
आईएमओ, यह एक बुरी बात है, हालांकि रखरखाव के मामले में असली शो-स्टॉपर नहीं है।
नुकसान यह है कि यह कक्षाओं को खोजने में कठोर बनाता है, और यह पैकेज नामों को अधिक वर्बोज़ बनाता है। जब आप आईडीई का उपयोग नहीं कर रहे हों तो पूर्व अधिक लागू होता है।
यह तर्क दिया जा सकता है कि यह "पैकेज निजी" स्कोपिंग के संयोजन के साथ मॉड्यूलरलाइजेशन में मदद करता है। लेकिन इसके विपरीत, आप यह भी तर्क दे सकते हैं कि अति-पैकेजिंग वास्तव में विपरीत है; यानी आप public का उपयोग करने के लिए मजबूर कर रहे हैं, जहां आपको कम अनाज/पैडेंटिक नहीं होना पड़ेगा।
यह निश्चित रूप से व्यक्तिपरक है, लेकिन मैं आम तौर पर अपने पैकेजों को कम से कम 3-4 कक्षाओं में शामिल करने के लिए पसंद करता हूं, लेकिन लगभग 13-15 से अधिक नहीं। यह परियोजना को अव्यवस्थित करते समय बेहतर समझ में आता है। हालांकि, दूसरों के लिए यह अलग हो सकता है। यदि पैकेज 13-15 से अधिक वर्गों में बढ़ता है, तो एक उप-पैकेज उभरने के लिए कह रहा है।
मुझे लगता है कि बेहतर अनाज पैकेज संरचना एक अच्छी बात है। मुख्य कारण यह है कि यह आपकी निर्भरताओं को कम करने में मदद कर सकता है। लेकिन सावधान रहें ... यदि आप चीजों को तोड़ते हैं जो वास्तव में एक साथ हैं, तो आप परिपत्र निर्भरताओं के साथ समाप्त हो जाएंगे!
अंगूठे के नियम के रूप में, मेरे पास आमतौर पर एक पैकेज में एक इंटरफेस (या संबंधित इंटरफेस का समूह) होता है। और उप-पैकेज में मेरे पास उन इंटरफेस के कार्यान्वयन होंगे (उसी पैकेज में सभी कार्यान्वयन के बजाय)। इस तरह से एक ग्राहक केवल इंटरफेस और ब्याज के कार्यान्वयन पर निर्भर कर सकता है ... और अन्य सभी चीजें जिनकी उन्हें आवश्यकता नहीं है।
उम्मीद है कि इससे मदद मिलती है।
एक विशेष पैकेज में समाप्त होने वाले प्रकारों की वास्तविक संख्या यह महत्वपूर्ण नहीं है। यह है कि आप अपने पैकेज संरचना पर कैसे पहुंचते हैं।
अमूर्तता ("कैसे", अनिवार्य रूप से "सार्वजनिक" एपीआई) के बजाय "क्या" (युग्मित "की एक डिग्री अन्य पैकेजों पर निर्भर करता है) और समेकन (एक पैकेज में कार्यक्षमता कितनी पारस्परिक है) अधिक महत्वपूर्ण हैं।
पैकेज डिजाइन (ज्यादातर Uncle Bob से) के लिए कुछ दिशा-निर्देश उदाहरण के लिए:
स्क्रैच से पूरी पैकेज संरचना को निकालने का प्रयास न करें (आपको इसकी आवश्यकता नहीं है)। इसके बजाए इसे अक्सर विकसित और पुन: प्रतिक्रिया दें। आसपास के चलते प्रकारों पर प्रेरणा के लिए अपने जावा स्रोतों के import अनुभाग को देखें।संकुल से विचलित न हों जिसमें केवल एक या कुछ प्रकार हों।
स्क्रैच से लिखते समय मेरा तरीका रूट पैकेज (com.example.app1) में सभी वर्गों को शुरू करना है। जब एक निश्चित मात्रा में पारस्परिक वर्ग होते हैं जो "पूरी चीज करते हैं" पैकेज बनाने का समय होता है। कुछ समय बाद सहायक वर्ग विकसित करने के लिए जेनेरिक पैकेज (उदा। Com.example.app1.misc, com.example.app1.utils) रूट पैकेज को अनलोड करने के लिए जा सकता है।
तो मैं रूट पैकेज को साफ रखने की कोशिश करता हूं।
फाइन-अनाज खराब नहीं है, लेकिन जैसा कि अन्य ने कहा है कि अक्सर एक कॉम्पैक्ट पैकेज संरचना का उत्पादन करता है।
एक पैकेज encapsulation की एक इकाई है।
आदर्श रूप में, यह इंटरफेस (रों) के माध्यम से एक सार्वजनिक एपीआई को उजागर करता है और पैकेज निजी कक्षाओं में कार्यान्वयन विस्तार छुपाता है।
इसलिए पैकेज का आकार सार्वजनिक एपीआई को लागू करने के लिए आवश्यक कक्षाओं की संख्या है।
वहाँ भी जादुई संख्या 7 +/- 2. शारीरिक हलकों के भीतर यह दिखाया गया है कि इस जैसी दी गई सेट समझ करने की क्षमता पर एक बुनियादी सीमा है। हमारे मस्तिष्क को स्वैपिंग शुरू करने से पहले हम एक ही समय में अल्पकालिक स्मृति और प्रक्रिया में कितना रख सकते हैं। यह कोडिंग के दौरान पाया गया अंगूठा का एक बुरा नियम नहीं है, यानी एक बार जब पैकेज 10 वर्गों से बड़ा हो जाता है तो इसे विभाजित करने के बारे में गंभीरता से सोचने का समय होता है, लेकिन 5 पैकेज से नीचे यह वास्तव में इसके लायक नहीं है। मेनू संगठन जैसी चीजों पर भी अच्छा लगा। Millers paper, या Google देखें।