2011-03-26 14 views
7

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

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

  1. समझ में नहीं आता, कैसे सार कक्षाएं अमूर्त की इस अवधारणा है, जहां सार वर्ग मुझे पूछता पृथक विधि लागू करने के लिए है, जहां जावा में सार वर्गों का उपयोग करने में अमूर्त है में फिट।
  2. मुझे लगता है कि, एक तरीका जिसमें अमूर्त कार्यान्वित किया जा सकता है, निजी कन्स्ट्रक्टर के माध्यम से और कक्षा के उपयोगकर्ता को कक्षा के उस वस्तु को प्राप्त करने के लिए कारखाने विधि का उपयोग करने के लिए कहता है जहां आप कार्यान्वयन विवरण लागू कर सकते हैं और छुपा सकते हैं।

कृपया मुझे सही करें, अगर मैं कहीं भी गलत हूं।

+0

आंतरिक विवरण छुपाकर, इसे encapsulation कहा जाता है। – Alexan

+0

मुझे लगता है कि, encapsulation का मतलब डेटा और संचालन को उस डेटा पर एक साथ बांधने के लिए किया जाता है, जो उच्च समेकन और कम युग्मन से संबंधित है ... – Vishwanath

+0

encapsulation की दो परिभाषाएं हैं: en.wikipedia।संगठन/विकी/Encapsulation_ (ऑब्जेक्ट उन्मुख_प्रोग्रामिंग) एक प्रोग्रामिंग भाषा encapsulation में दो संबंधित लेकिन अलग धारणाओं में से एक को संदर्भित करने के लिए प्रयोग किया जाता है, और कभी-कभी इसके संयोजन के लिए: किसी ऑब्जेक्ट के घटकों तक पहुंच प्रतिबंधित करने के लिए एक भाषा तंत्र। एक भाषा निर्माण जो उस डेटा पर चल रहे तरीकों (या अन्य कार्यों) के साथ डेटा के बंडल की सुविधा प्रदान करता है। – Alexan

उत्तर

8

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

लेकिन यह सार वर्गों के साथ भी फिट बैठता है - वे ठोस नहीं हैं (उन्हें तत्काल नहीं किया जा सकता है,) और वे कार्यान्वयन निर्दिष्ट नहीं करते हैं। वे अमूर्त विचार निर्दिष्ट करते हैं कि उप-वर्गों का ख्याल रखना है।

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

+0

उत्तर के लिए धन्यवाद। 'अलग-अलग दृष्टिकोण' के बिंदु ने इसे मेरे लिए कम भ्रमित कर दिया .... – Vishwanath

0
  1. सार कक्षाएं एक अंतरफलक जो वर्ग के उपयोगकर्ताओं का उपयोग करेगा परिभाषित करता है। एक अमूर्त वर्ग एक इंटरफ़ेस के समान होता है सिवाय इसके कि कुछ विधि लागू की जा सकती हैं और सभी सार तत्वों को ठोस वर्गों द्वारा कार्यान्वित किया जाएगा जो इसे विस्तारित करते हैं। संक्षेप में लाभ यह है कि आप एक ही अमूर्त वर्ग के कई कार्यान्वयन कर सकते हैं जो पूरी तरह से अदलाबदल योग्य हैं क्योंकि उपयोगकर्ता द्वारा संचालित कक्षा, विशिष्ट कार्यान्वयन प्रकार के बजाय अमूर्त प्रकार का है।

  2. कारखाने के तरीकों का उपयोग अमूर्तता के लिए एक आम दृष्टिकोण है लेकिन आप अपने कन्स्ट्रक्टर के साथ ठोस वर्ग को भी चालू कर सकते हैं। महत्वपूर्ण बात वेरिएबल का प्रकार है जिसे सार प्रकार के रूप में परिभाषित किया जाना चाहिए। ऐसा करने से ऑब्जेक्ट वैरिएबल को केवल सार वर्ग द्वारा परिभाषित इंटरफेस के साथ ही पहुंचा जा सकता है।

संबंधित मुद्दे