रूबी

Question

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

मेरी चिंता यह

1 कैसे लागू करने के लिए) यह है है एक साधारण समारोह सिर्फ इस

# function to sort array 
# @params array[Array] to be sort 

def my_sort(array) 
    return array if array.size <= 1 

    swapped = false 
    while !swapped 
    swapped = false 
    0.upto(array.size-2) do |i| 
     if array[i] > array[i+1] 
     array[i], array[i+1] = array[i+1], array[i] 
     swapped = true 
     end 
    end 
    end 

    array 
end 

तरह बुला और इस

sorted_array = my_sort([12,34,123,43,90,1]) 

2 की तरह बुला) कैसे डेटा एब्सट्रैक्शन करता है Encapsulation

से अलग है जैसा कि मैंने समझा है डेटा एब्स्ट्रक्शन केवल हिडी है अन्य वर्गों से कुछ सदस्य डेटा।

Answer 1

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

Answer 2

डाटा अमूर्त सबसे वस्तु उन्मुख भाषा के लिए मौलिक है।

रुबी का ऐरे क्लास डाटा एब्स्ट्रक्शन का एक उदाहरण है। यह ऑब्जेक्ट्स की एक सरणी को प्रबंधित करने के लिए एक तंत्र प्रदान करता है, और संचालन प्रदान करता है जिसे उस सरणी पर किया जा सकता है, बिना किसी देखभाल के कि यह आंतरिक रूप से कैसे व्यवस्थित किया जाता है।

arr = [1,3,4,5,2,10] 
p arr.class # Prints Array 
p arr.sort # Prints [1,2,3,4,5,10] 

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

उसी समय, रुबी को पता नहीं हो सकता कि Array में मौजूद दो वस्तुओं की तुलना कैसे करें। उदाहरण के लिए, नीचे कोड नहीं चलाया जाएगा क्योंकि रुबी को स्ट्रिंग्स और संख्याओं की तुलना करने के बारे में पता नहीं है।

[1,3,4,5,"a","c","b", 2,10].sort 
#=> `sort': comparison of Fixnum with String failed (ArgumentError) 

यह हमें (के रूप में यह उपयोगकर्ता से निकाला जाता है) कार्यान्वयन में हुक और तुलना के साथ मदद, भले ही अंतर्निहित छँटाई एल्गोरिथ्म एक ही रहता है के लिए अनुमति देता

[1,3,4,5,"a","c","b", 2,10].sort { |i,j| 
    if i.class == String and j.class == String 
     i <=> j 
    elsif i.class == Fixnum and j.class == Fixnum 
     i <=> j 
    else 
     0 
    end 
} 
#=> [1, 3, 4, 5, 2, 10, "a", "b", "c"] 

जब अपनी खुद की समस्याओं के लिए कोड लिखने, प्रक्रियात्मक अबास्ट्रक्शन का उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि एक प्रक्रिया अक्सर उप-समस्याओं में अपनी समस्या को तोड़ देती है, और अलग-अलग प्रक्रिया का उपयोग करके प्रत्येक उप-समस्या हल करती है। यह कुछ पहलुओं को बाद में विस्तारित करने की अनुमति देता है (जैसा कि उपरोक्त मामले में, तुलना बढ़ाया जा सकता है - रुबी blocks के लिए धन्यवाद, यह बहुत आसान था)। Template method pattern इसे प्राप्त करने के लिए अच्छी तकनीक है।

Answer 3

'एब्स्ट्रक्शन' की परिभाषा: घटनाओं के बजाय विचारों से निपटने की गुणवत्ता।

इस जवाब difference between abstraction and encapsulation? का जिक्र करते हुए और मेरी समझ मैंने पाया कि अपने कोड में विधि my_sort पूरी तरह से Encapsulation को सही ठहराते हैं के रूप में यह behavior किसी भी single dimension सरणी की छंटाई से संबंधित समाहित। हालांकि इसमें abstraction की कमी है क्योंकि विधि my_sort जानता है कि किस प्रकार के डेटा पर प्रक्रिया होगी।

यह Abstraction को उचित ठहराया गया होगा अगर यह पैराम्स के माध्यम से आने वाले डेटा के प्रकार की देखभाल/देखभाल नहीं करता था। दूसरे शब्दों में, यह किसी ऑब्जेक्ट को सॉर्ट करना चाहिए था, चाहे वह Fixnum या String या अन्य sortable datatypes की सूची हो।

Encapsulation:

हम आम तौर पर डेटा/व्यवहार है कि clients को उजागर किया है और internally प्रयोग की जाने वाली हैं कि अंतर करने के लिए पहुँच संशोधक (public, private, ..) का उपयोग करें। सार्वजनिक इंटरफेस (ग्राहकों के लिए उजागर) जहां तक ​​संभव हो सके परिवर्तन के अधीन नहीं हैं। हालांकि, private ऐसे व्यवहार हैं जो किसी भी मामले में बदल सकते हैं और किसी भी मामले में clients पर भरोसा करने वाले कोड के अपेक्षित व्यवहार को प्रभावित नहीं कर सकते हैं।
हम आकस्मिक संशोधन/दुरुपयोग को रोकने के लिए संवेदनशील डेटा/व्यवहार को निजी/संरक्षित भी अलग करते हैं। यह ग्राहक को कोड के उस हिस्से पर भरोसा नहीं करता है जो अक्सर बदल सकता है।

• तो एक हमेशा core logicprivate के दायरे को अलग करने की जरूरत है।

अमूर्त:

उदाहरण: चर्च के मामले में वहाँ confessor और father/priest के बीच एक abstraction है। कन्फेस्टर को priest के नाम या किसी भी विवरण के बारे में कोई जानकारी नहीं होनी चाहिए और इसके विपरीत। कोई भी कबूल कर सकता है और फिर भी अपनी पहचान छुपा सकता है इससे कोई फर्क नहीं पड़ता कि उसने कितनी बड़ी गलतियों/अपराध किए हैं।