जवाबों:
इसके साथ एकमात्र समस्या यह है कि यह आपके स्थानीय नामस्थान को बंद कर देता है। उदाहरण के लिए, मान लें कि आप एक स्विंग ऐप लिख रहे हैं, और इसलिए आवश्यकता है java.awt.Event, और कंपनी के कैलेंडरिंग सिस्टम के साथ भी हस्तक्षेप कर रहे हैं, जिसमें है com.mycompany.calendar.Event। यदि आप वाइल्डकार्ड विधि का उपयोग करके दोनों को आयात करते हैं, तो इन तीन चीजों में से एक होता है:
java.awt.Eventऔर com.mycompany.calendar.Event, इसलिए आपको यह भी संकलन नहीं कर सकते।.*), लेकिन यह गलत है, और आप यह पता लगाने के लिए संघर्ष करते हैं कि आपका कोड क्यों दावा कर रहा है कि यह गलत है।com.mycompany.calendar.Event, लेकिन जब वे बाद में एक जोड़ते हैं तो आपका पहले वाला वैध कोड अचानक संकलन बंद हो जाता है।सभी आयातों को स्पष्ट रूप से सूचीबद्ध करने का लाभ यह है कि मैं एक नज़र में बता सकता हूं कि आप किस वर्ग का उपयोग करना चाहते हैं, जो कोड को पढ़ना आसान बनाता है। यदि आप बस एक त्वरित कार्य कर रहे हैं, तो स्पष्ट रूप से कुछ भी गलत नहीं है , लेकिन भविष्य के अनुचर आपकी स्पष्टता के लिए धन्यवाद करेंगे अन्यथा।
यहाँ स्टार आयात के लिए एक वोट है । एक आयात स्टेटमेंट का उद्देश्य पैकेज को आयात करना है , न कि क्लास को। पूरे पैकेज को आयात करने के लिए यह बहुत साफ है; यहाँ पहचाने गए मुद्दे (जैसे java.sql.Dateबनाम java.util.Date) को अन्य माध्यमों द्वारा आसानी से हटा दिया जाता है, वास्तव में विशिष्ट आयातों द्वारा संबोधित नहीं किया जाता है और निश्चित रूप से सभी वर्गों पर पागलपन भरे आयात को उचित नहीं ठहराता है। स्रोत फ़ाइल खोलने और 100 आयात विवरणों के माध्यम से पृष्ठ पर आने से अधिक निराशाजनक कुछ भी नहीं है।
विशिष्ट आयात करने से रिफैक्टरिंग अधिक कठिन हो जाता है; यदि आप किसी वर्ग को हटाते हैं / उसका नाम बदलते हैं, तो आपको उसके सभी विशिष्ट आयातों को हटाने की आवश्यकता है । यदि आप एक कार्यान्वयन को एक ही पैकेज में एक अलग वर्ग में बदलते हैं, तो आपको आयात ठीक करना होगा। हालांकि इन अतिरिक्त चरणों को स्वचालित किया जा सकता है, वे वास्तव में बिना किसी वास्तविक लाभ के उत्पादकता हिट हैं।
भले ही ग्रहण डिफ़ॉल्ट रूप से वर्ग आयात नहीं करता था, फिर भी हर कोई स्टार आयात कर रहा होगा। मुझे खेद है, लेकिन विशिष्ट आयात करने के लिए वास्तव में कोई तर्कसंगत औचित्य नहीं है।
यहाँ वर्ग संघर्षों से निपटने के तरीके दिए गए हैं:
import java.sql.*;
import java.util.*;
import java.sql.Date;Foo, और अगर मैं बिना आईडीई का उपयोग किए बिना आपका कोड पढ़ता हूं (चूंकि आपका तर्क है कि मुझे एक का उपयोग नहीं करना चाहिए), तो मुझे कैसे पता चलेगा कि कौन सा पैकेज Fooआया ? निश्चित रूप से, एक आईडीई का उपयोग करते हुए, आईडीई मुझे बताएगा, लेकिन आपका पूरा तर्क यह है कि मुझे एक के बिना कोड पढ़ने में सक्षम होना चाहिए । स्पष्ट आयात करने से कोड (वाइल्डकार्ड से बचने का बहुत बड़ा कारण) को दस्तावेज़ में मदद मिलती है , और यह बहुत अधिक संभावना है कि मैं आईडीई का उपयोग किए बिना कोड पढ़ रहा हूं, इससे अधिक मैं आईडीई का उपयोग किए बिना कोड लिख रहा हूं ।
कृपया मेरे लेख देखें डिमांड पर आयात बुराई है
संक्षेप में, सबसे बड़ी समस्या यह है कि आपका कोड तब टूट सकता है जब कोई वर्ग आपके द्वारा आयात किए गए पैकेज में जोड़ा जाता है। उदाहरण के लिए:
import java.awt.*;
import java.util.*;
// ...
List list;जावा 1.1 में, यह ठीक था; Java.awt में सूची मिली और कोई विरोध नहीं हुआ।
अब मान लीजिए कि आप अपने पूरी तरह से काम कर रहे कोड में जांच करते हैं, और एक साल बाद कोई और इसे संपादित करने के लिए बाहर लाता है, और जावा 1.2 का उपयोग कर रहा है।
जावा 1.2 ने java.util के लिए सूची नाम का एक इंटरफ़ेस जोड़ा। बूम! संघर्ष। पूरी तरह से काम करने वाला कोड अब काम नहीं करता है।
यह एक EVIL लैंग्वेज फीचर है। नहीं है कोई कारण यह है कि कोड संकलन सिर्फ इसलिए कि एक प्रकार है बंद कर देना चाहिए जोड़ा एक पैकेज के लिए ...
इसके अलावा, यह एक पाठक के लिए यह निर्धारित करना मुश्किल बनाता है कि आप किस "फू" का उपयोग कर रहे हैं।
java.util.Listबनाम java.awt.Listयह पता लगाने के लिए बहुत बुरा नहीं है, लेकिन इसे तब आजमाएं जब वर्ग का नाम हो Configurationऔर कई निर्भरता पुस्तकालयों ने इसे अपने नवीनतम मावेन रेपो संस्करण में जोड़ा हो।
यह नहीं एक जावा आयात बयान के साथ वाइल्ड कार्ड का उपयोग करने के बुरा।
में स्वच्छ कोड , रॉबर्ट सी मार्टिन वास्तव में उन्हें उपयोग करने की सलाह लंबे आयात सूचियों से बचने के लिए।
यहाँ सिफारिश है:
J1: वाइल्डकार्ड का उपयोग करके लंबी आयात सूची से बचें
यदि आप पैकेज से दो या अधिक वर्गों का उपयोग करते हैं, तो पूरे पैकेज को आयात करें
आयात पैकेज। *;
आयात की लंबी सूची पाठक के लिए कठिन होती है। हम आयात की 80 लाइनों के साथ अपने मॉड्यूल के शीर्ष को अव्यवस्थित करना नहीं चाहते हैं। इसके बजाय हम चाहते हैं कि आयात एक संक्षिप्त विवरण हो कि हम किन पैकेजों के साथ सहयोग करते हैं।
विशिष्ट आयात कठिन निर्भरताएं हैं, जबकि वाइल्डकार्ड आयात नहीं हैं। यदि आप विशेष रूप से एक वर्ग आयात करते हैं, तो उस वर्ग का अस्तित्व होना चाहिए। लेकिन यदि आप वाइल्डकार्ड के साथ पैकेज आयात करते हैं, तो किसी विशेष वर्ग के अस्तित्व में नहीं है। आयात विवरण केवल पैकेज को खोज पथ पर जोड़ता है जब नामों के लिए शिकार करते हैं। इसलिए इस तरह के आयातों से कोई सच्ची निर्भरता नहीं बनती है, और इसलिए वे हमारे मॉड्यूल को कम रखने के लिए काम करते हैं।
ऐसे समय होते हैं जब विशिष्ट आयात की लंबी सूची उपयोगी हो सकती है। उदाहरण के लिए, यदि आप विरासत कोड के साथ काम कर रहे हैं और आप यह पता लगाना चाहते हैं कि आपको किन वर्गों के लिए मोक्स और स्टब्स बनाने की आवश्यकता है, तो आप उन सभी वर्गों के असली योग्य नामों का पता लगाने के लिए विशिष्ट आयातों की सूची नीचे चला सकते हैं और फिर डाल सकते हैं। जगह में उपयुक्त स्टब्स। हालांकि, विशिष्ट आयात के लिए यह उपयोग बहुत दुर्लभ है। इसके अलावा, अधिकांश आधुनिक IDE आपको वाइल्डकार्ड आयात को एकल कमांड के साथ विशिष्ट आयातों की सूची में बदलने की अनुमति देंगे। इसलिए विरासत के मामले में भी वाइल्डकार्ड आयात करना बेहतर है।
वाइल्डकार्ड आयात कभी-कभी नाम संघर्ष और अस्पष्टता का कारण बन सकता है। एक ही नाम वाली दो कक्षाएं, लेकिन विभिन्न पैकेजों में, विशेष रूप से आयात किए जाने की आवश्यकता होती है, या कम से कम विशेष रूप से योग्य होने पर उपयोग किया जाता है। यह एक उपद्रव हो सकता है लेकिन यह काफी दुर्लभ है कि वाइल्डकार्ड आयात का उपयोग आम तौर पर विशिष्ट आयात की तुलना में बेहतर है।
प्रदर्शन : बाइट कोड के रूप में प्रदर्शन पर कोई प्रभाव नहीं है। हालांकि यह कुछ संकलन ओवरहेड्स को जन्म देगा।
संकलन : मेरी निजी मशीन पर, बिना किसी आयात के किसी रिक्त वर्ग को संकलित करने पर जावा को आयात करते समय 100 मि।
import java.*आयात कुछ नहीं। इससे फर्क क्यों पड़ेगा?
यह आपके नामस्थान को बंद कर देता है, जिससे आपको अस्पष्ट रूप से किसी भी वर्गनाम को पूरी तरह से निर्दिष्ट करने की आवश्यकता होती है। इसके साथ सबसे आम घटना है:
import java.util.*;
import java.awt.*;
...
List blah; // Ambiguous, needs to be qualified.यह आपकी निर्भरता को ठोस बनाने में भी मदद करता है, क्योंकि आपकी सभी निर्भरताएं फ़ाइल के शीर्ष पर सूचीबद्ध हैं।
अधिकांश स्थानों पर मैंने काम किया है जो जावा की किसी भी महत्वपूर्ण राशि का उपयोग करते हैं, कोडिंग मानक का स्पष्ट आयात करते हैं। मैं कभी-कभी त्वरित प्रोटोटाइप के लिए * का उपयोग करता हूं और फिर कोड का उपयोग करते समय आयात सूचियों का विस्तार करता हूं (कुछ आईडीई आपके लिए भी ऐसा करेंगे)।
पिछले प्रोजेक्ट में मैंने पाया कि * -मपोर्ट्स से विशिष्ट आयातों में बदलाव ने संकलन समय को आधे से कम कर दिया (लगभग 10 मिनट से लगभग 5 मिनट तक)। * -Import कंपाइलर को आपके द्वारा उपयोग किए जाने वाले वर्ग से मेल खाते प्रत्येक वर्ग के लिए सूचीबद्ध बनाता है। जबकि यह समय छोटा हो सकता है, यह बड़ी परियोजनाओं के लिए जोड़ता है।
* -पोर्ट का एक पक्ष प्रभाव यह था कि डेवलपर्स आम आयात लाइनों को कॉपी और पेस्ट करते थे, बजाय इसके कि वे क्या सोचते हैं।
में DDD किताब
जिस भी विकास तकनीक में कार्यान्वयन आधारित होगा, वह MODULES को फिर से भरने के काम को कम करने के तरीकों की तलाश करेगा। जावा में, व्यक्तिगत वर्गों में आयात करने से कोई बच नहीं सकता है, लेकिन आप एक समय में पूरे पैकेज को कम से कम आयात कर सकते हैं, इस इरादे को दर्शाते हैं कि पैकेज नाम बदलने के प्रयास को कम करते हुए पैकेज अत्यधिक एकजुट इकाइयां हैं।
और अगर यह स्थानीय नाम स्थान को बंद कर देता है तो यह आपकी गलती नहीं है - पैकेज के आकार को दोष दें।
कोई रनटाइम प्रभाव नहीं है, क्योंकि संकलक स्वचालित रूप से * को ठोस वर्ग नामों के साथ बदल देता है। यदि आप .class फ़ाइल को विघटित करते हैं, तो आप कभी नहीं देखेंगे import ...*।
C # हमेशा उपयोग करता है (स्पष्ट रूप से) क्योंकि आप केवल usingनाम का पैकेज कर सकते हैं । आप कभी भी कक्षा का नाम निर्दिष्ट नहीं कर सकते। जावा c # के बाद फीचर का परिचय देता है। (जावा कई पहलुओं में इतना पेचीदा है लेकिन यह इस विषय से परे है)।
Intellij Idea में जब आप "import Organize" करते हैं, तो यह अपने आप एक ही पैकेज के कई आयात * की जगह ले लेता है। यह एक अनिवार्य विशेषता है क्योंकि आप इसे बंद नहीं कर सकते (हालांकि आप सीमा बढ़ा सकते हैं)।
स्वीकृत उत्तर द्वारा सूचीबद्ध मामला मान्य नहीं है। बिना * आप अभी भी एक ही मुद्दा है। आपको अपने कोड में pakcage का नाम निर्दिष्ट करने की आवश्यकता है, चाहे आप * या नहीं का उपयोग करें।
रिकॉर्ड के लिए: जब आप एक आयात जोड़ते हैं, तो आप अपनी निर्भरता का भी संकेत दे रहे हैं।
आप जल्दी से देख सकते हैं कि फ़ाइलों की निर्भरता क्या है (समान नामस्थान की कक्षाओं को छोड़कर)।
सबसे महत्वपूर्ण यह है कि आयात java.awt.*आपके प्रोग्राम को भविष्य के जावा संस्करण के साथ असंगत बना सकता है:
मान लीजिए कि आपके पास "एबीसी" नामक एक वर्ग है, आप जेडडीके 8 का उपयोग कर रहे हैं और आप आयात करते हैं java.util.*। अब, मान लीजिए कि जावा 9 बाहर आता है, और इसमें एक नया वर्ग है java.utilजो संयोग से "एबीसी" कहलाता है। आपका प्रोग्राम अब जावा 9 पर संकलित नहीं होगा, क्योंकि संकलक को यह नहीं पता है कि "एबीसी" नाम के साथ आपका मतलब है कि आपकी अपनी कक्षा या नई कक्षा है java.awt।
जब आप केवल उन वर्गों को स्पष्ट रूप से आयात करते हैं java.awtजिनसे आपको वास्तव में उपयोग होता है, तो आपको वह समस्या नहीं होगी ।
संसाधन:
Streamजावा में जावा में जोड़े गए एक नए वर्ग के उदाहरण के रूप में इस्तेमाल कर सकते हैं। 8 जावा में ...
दोनों पक्षों पर किए गए सभी मान्य बिंदुओं के बीच मुझे वाइल्डकार्ड से बचने का मेरा मुख्य कारण नहीं मिला है: मुझे कोड पढ़ना और सीधे यह जानना पसंद है कि हर वर्ग क्या है, या अगर इसकी परिभाषा भाषा में नहीं है या फ़ाइल, जहां इसे खोजने के लिए। यदि एक से अधिक पैकेज * के साथ आयात किया जाता है, तो मुझे उन सभी में से एक को खोजना होगा जो मुझे नहीं पहचानता है। पठनीयता सर्वोच्च है, और मैं मानता हूं कि कोड को इसे पढ़ने के लिए आईडीई की आवश्यकता नहीं होनी चाहिए ।