2012-06-27 30 views
13

मान लें कि मेरे पास एक CSV फ़ाइल है और मैं CsvFile नामक एक क्लास बनाता हूं जो java.io.File से फैली हुई है। यह वर्ग एक CSV फ़ाइल को पार्स कर सकता है और फ़ाइल में कितने कॉलम हैं जैसे कुछ डेटा लौटा सकता है। इसका उपयोग उन कार्यों के लिए भी किया जा सकता है जो इनपुट के रूप में java.io.File लेते हैं। एफ ileUtils.copyFile(File from, File to) की तरह।विरासत ब्रेक encapsulation होगा?

मेरे सहयोगी को लगता है कि मैं विरासत से बहुत अधिक खुलासा करता हूं। उनका विचार java.io.File को इसे निजी संपत्ति में रखने के बजाय इसे विरासत में रखने के लिए लपेटना है। वह फ़ाइल ब्रेक इंकापुलेशन से सभी सार्वजनिक विधि/संपत्ति को उजागर करने के बारे में सोचते हैं, लेकिन मैं इसे लाभ के रूप में लेता हूं क्योंकि हम सभी कार्यों को java.io.File में मुफ्त में प्राप्त करते हैं।

आपको क्या लगता है?

+0

या तो मुझे लगता है या नहीं, लेकिन दोनों संयोजन संयोजन है। पहली विरासत ताकि पहिया को दोहराने वाले पैटर्न की तुलना में पुनर्निर्मित नहीं किया जा सके ताकि पहिया अपने उद्देश्य को पूरा कर सके। उत्तर में जोड़ने के लिए –

उत्तर

15

मैं नहीं बल्कि अपने सहयोगी के साथ सहमत होंगे: इनहेरिट java.util.File तरीकों कि CsvFile वस्तुओं के लिए लागू नहीं कर रहे हैं, इस तरह के रूप list(), listFiles(), setExecutable(), और इतने पर बेनकाब करेंगे।

java.util.File बनाना गेटटर के पीछे एक संपत्ति बेहतर विकल्प की तरह लगता है: यह आपकी कक्षा के उपयोगकर्ताओं को अप्रासंगिक संचालन प्रकट नहीं करता है, और आपको अपनी पसंद के आधार वर्ग से प्राप्त करने देता है।

+1

: हां, इस मामले में विरासत कार्यान्वयन विस्तार को लीक करके encapsulation तोड़ देगा कि एक सीवीएस फ़ाइल java.io.File – Soronthar

+1

का उपयोग करके लागू की गई है, यह शायद या तो कोई मामला नहीं हो सकता है। उन विधियों को संकीर्ण करने के लिए लपेटने के बजाय, अनुकूलित करने के लिए प्रयास करें, जिन्हें आप बेनकाब करना चाहते हैं। –

+0

या तो मुझे नहीं लगता है, लेकिन दोनों संयोजन संयोजन है। पहली विरासत ताकि पहिया को दोहराने वाले पैटर्न की तुलना में पुनर्निर्मित नहीं किया जा सके ताकि पहिया अपने उद्देश्य को पूरा कर सके। –

5

मुझे लगता है कि यह सब कक्षा के उद्देश्य पर निर्भर करता है। यदि आप वास्तव में व्यवहार का विस्तार करने की कोशिश कर रहे हैं तो मैं कहूंगा कि यह समझ में आता है। यदि आप फ़ाइल के व्यवहार को विस्तारित नहीं कर रहे हैं लेकिन केवल एक सीएसवी ऑब्जेक्ट बना रहे हैं तो encapsulation इसके व्यवहार को केवल वही करने के लिए सीमित करेगा।

1

आप इसे अधिक सामान्य बनाने पर भी विचार कर सकते हैं ताकि यह विभिन्न प्रकार के स्रोतों से सीएसवी-स्वरूपित इनपुटस्ट्रीम या रीडर को स्वीकार कर सके जो फाइल सिस्टम को छोड़ नहीं सकते (या आसानी से नहीं) कर सकते हैं। सुविधा के लिए अभी भी एक java.io.File setter/constructor हो सकता है।

1

यह वास्तव में एक महान बहस है। आपका सहयोगी इस पर इतिहास के दाहिने तरफ है। आम तौर पर विरासत का सवाल यह है कि एक बनाम है-ए। आम तौर पर विरासत की तुलना में संरचना का उपयोग करने के लिए यह अधिक लचीला है। आपके मामले में यह एक करीबी कॉल है। एक सीएसवी फ़ाइल आईएसए फ़ाइल के बाद। कह रहा है कि csvfile है-एक फ़ाइल भी सही ध्वनि नहीं है। विरासत को करने के लिए भी माना जा सकता है लेकिन विरासत फ़ाइल को लपेटने के बजाय ताकि केवल उन सीएसवी फ़ाइल विधियों को आप उजागर कर सकें। मैं इसके आस-पास कुछ डिज़ाइन पैटर्न भी देखूंगा जहां आप ए से उत्तराधिकारी बनना चाहते हैं लेकिन दुनिया के लिए एक सीमित सीमित इंटरफ़ेस का पर्दाफाश करना चाहते हैं। मुझे यकीन है कि इसके लिए एक डिजाइन पैटर्न है। बस नाम याद नहीं कर सकता ....

"या तो मुझे लगता है कि नहीं, लेकिन दोनों संयोजनों का संयोजन है। पहला विरासत ताकि पहिया को दोहराने वाले पैटर्न की तुलना में पुनर्निर्मित नहीं किया जा सके ताकि पहिया इसकी सेवा कर सके उद्देश्य। "

0

शायद मेरा दृष्टिकोण बहुत उदार है लेकिन ... एक कारण के लिए Encapsulation और विरासत हैं। (असेंबलरों से उच्च स्तर की भाषाओं में 'विकास' देखें।) यही कारण प्रोग्रामर है। उच्च स्तरीय abstractions/प्रतिमान के साथ आप बेहतर कोड लिख सकते हैं। यह चाल निश्चित रूप से 'बेहतर' परिभाषित करना है। मेरे लिए यह रखरखाव, स्वयं दस्तावेज और कोड पुन: उपयोग है। यही कारण है कि मैं आपके विशेष मामले में विरासत पर encapsulation चुनना होगा। शायद यह एक बार लिखने के लिए थोड़ा और काम है, लेकिन भविष्य में बनाए रखने के लिए बहुत आसान है। (इस सीएसवी सामग्री को मानना ​​निश्चित रूप से एक बड़ी परियोजना का हिस्सा है।)

0

आपके सहयोगी के दृष्टिकोण का दृष्टिकोण भी लाभ है कि आपकी एपीआई केवल उन्हीं तरीकों को उजागर करके बहुत छोटा हो जाता है जो आपको वास्तव में चाहिए - जो यह स्पष्ट करता है कि उपयोगकर्ता को कैसे अपनी कक्षा का उपयोग कैसे करें (आप अपने सार्वजनिक एपीआई के बारे में कुछ प्रकार के दस्तावेज के रूप में सोच सकते हैं)।

0

अपने प्रश्न

तोड़ कैप्सूलीकरण विरासत होगा करने के लिए के रूप में?

विधि मंगलाचरण के विपरीत, विरासत [Snyder86] कैप्सूलीकरण उल्लंघन करती है:

फिर, यहोशू बलोच के प्रभावी जावा के अनुसार, विरासत हमेशा कैप्सूलीकरण टूट जाता है। दूसरे शब्दों में, उप-वर्ग अपने उचित कार्य के लिए अपने सुपरक्लास के कार्यान्वयन के कार्यान्वयन पर निर्भर करता है।

के बारे में है कि क्या आप, विरासत या रचना का उपयोग करना चाहिए के रूप में कई लोगों को पहले ही कहा था, उस पर निर्भर करता है, तो अपने CsvFile फ़ाइल-एक है, java.util.File के तौर पर।