बदमाशों के लिए गणित

परिष्कार (परिष्कार) पर चर्चा में और ओ.ओ.पी.

चूँकि रीड-ओनली मोड में टिप्पणी लिखने की अनुमति नहीं है, इसलिए मैं सैंडबॉक्स में फिर से लिखने का जोखिम उठाऊंगा।

प्रविष्टि

एक हबल को पढ़ते हुए, मैं टिप्पणियों में से एक पर ठोकर खाई। या बल्कि, इस टिप्पणी में एक उद्धरण पर ठोकर खाई:

"मुझे यकीन है कि OOP पद्धतिगत रूप से गलत है। वह कक्षाओं के निर्माण से शुरू होता है। यह वैसा ही है जैसे गणितज्ञ स्वयंसिद्धों से शुरू करेंगे। लेकिन कोई भी वास्तव में स्वयंसिद्ध से शुरू नहीं होता है, हर कोई सबूत के साथ शुरू होता है। केवल जब उपयुक्त साक्ष्य का एक सेट पाया जाता है, तभी इस आधार पर स्वयंसिद्ध व्युत्पन्न होता है। यानी गणित में आप एक स्वयंसिद्ध शब्द के साथ समाप्त होते हैं।
यही प्रोग्रामिंग के साथ है: पहले आपको एल्गोरिदम विकसित करना शुरू करना होगा, और केवल इस काम के अंत में इस बिंदु पर आना चाहिए कि आप स्पष्ट और सुसंगत इंटरफेस बनाने में सक्षम हैं। यह ओओपी में इस भ्रम के कारण है कि रिफैक्टिंग इतना लोकप्रिय है - प्रतिमान की हीनता के कारण, आप बस कार्यक्रम को फिर से लिखने के लिए बर्बाद हो जाते हैं, उसी क्षण जब आपने ओओपी शैली में इसे डिजाइन करने का फैसला किया। "
(c) अलेक्जेंडर स्टेपानोव, C ++ के सह-लेखक, STL के लेखक

इस लेख (या बल्कि, Stepanov के उद्धृत उद्धरण के विश्लेषण के लिए) पर जाने से पहले, मैं एक उत्तेजक घोषणा के साथ एक छोटा लेख भी याद करना चाहता हूं ("कुटिलता के लिए गणित है"), जो किसी भी तरह एक चमकदार पत्रिका में मेरी आंख (जो अपने आप में पहले से ही अजीब है; इस तरह की पत्रिकाओं में किसी चीज़ पर ध्यान देना संभव है)। इलेक्ट्रॉनिक संस्करण यहाँ है । अगला, मैं इस लेख से शर्तों का उल्लेख करूंगा, इसलिए मैं सुझाव देता हूं कि आप खुद को परिचित करें।

अपने हाथ देखो

वक्तृत्व के संदर्भ में हमारे उद्धरण की सराहना करें। लेकिन सुंदर! जैसा कि वे कहते हैं, अपने हाथों को देखें। यह एक अप्रत्याशित और जोर से बयान के साथ शुरू होता है, इसलिए यह तुरंत ध्यान आकर्षित करता है। फिर वक्ता श्रोता (पाठक) को OOP और गणित के स्वयंसिद्ध वर्गों के बीच समानता के लिए लाता है। यह सादृश्य आगे चलकर अंतिम राग के आधार के रूप में कार्य करता है: "आप बस कामचोर हैं ..."! तालियां। पर्दा। विरोधियों को उखाड़ फेंका जाता है।

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

प्रशस्ति पत्र की नींव एक तरफ गणित के प्रमाण और स्वयंसिद्धों के बीच की समानता है, और दूसरी ओर एल्गोरिदम और वस्तुओं के इंटरफेस। यह उपमा कितनी पुष्ट है? एक नींव की प्रत्याशा की तरह लगता है?

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

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

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

अंततः, ओओपी का प्रमुख घोषित विचार - सब कुछ एक वस्तु है - यह भी पसंद की संकीर्णता जैसा दिखता है। खैर, "सब कुछ एक वस्तु है" क्यों जरूरी है? क्यों नहीं "सब कुछ एक वस्तु के रूप में प्रतिनिधित्व किया जा सकता है"? या यह अनुवाद त्रुटियों है?

निष्कर्ष

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

पुनश्च। और मुझे खेद है कि अगर मैंने प्रोग्रामिंग थ्योरी या गणित को कहीं गड़बड़ कर दिया। मुझे संशोधन करने में खुशी होगी।

इस पोस्ट का उद्देश्य किसी भी तरह से अलेक्जेंडर स्टेपानोव या किसी और के अधिकार को कम करने के लिए नहीं था, और यहां तक ​​कि "मैं कितना स्मार्ट हूं" दिखाने के लिए कम। मैं सिर्फ इस तथ्य पर ध्यान आकर्षित करना चाहता था कि जब हम चर्चाओं में अपनी राय का बचाव करना सीखते हैं, तो हम अक्सर परिष्कार के उपयोग में आते हैं, और हमें इसका एहसास भी नहीं होता है। यह ठगों के लिए ऐसा गणित बताता है।