यह हब पर ऐसा हुआ कि हर होलीवर लेख "प्रो" के लिए हमेशा एक लेख "कॉन्ट्रा" होता है।
मैंने यह भी फैसला किया कि
“ओओपी और एफपी के साथ गलत क्या है” पोस्ट को अकेले नहीं छोड़ना चाहिए।
यह सीधे तौर पर विरोधाभासी नहीं है कि क्या लिखा है, क्योंकि वहाँ "स्वाद" वर्णित है, और, जैसा कि आप जानते हैं, स्वाद और रंग ... हर कोई अपने वाईपी से प्यार करता है।
OOP और AF से कोई समस्या नहीं है। कार्यों की शुद्धता केवल एक उपकरण है, साथ ही साथ "सब कुछ एक वस्तु है।"
कानून की केवल एक आलोचना है - मिलीमीटर के संघर्ष में, उज्ज्वल छेद स्पष्ट रूप से दिखाई देते हैं, और किसी भी पतित विधियों में, कमियां स्पष्ट रूप से प्रकट होती हैं।
एक और बात यह है कि किसी भी गैर-पतित तरीकों में भी नुकसान हैं, केवल उनमें से अधिक हैं, लेकिन वे इतनी आसानी से ध्यान देने योग्य नहीं हैं।
C ++ के प्रेमी OOP के लिए सड़ांध फैलाते हैं, अपूर्ण OOP के लिए Java C ++ के लिए रोट फैलाते हैं, Haskell अन्य गंदे कार्यों के लिए सड़ांध फैलाते हैं, बाकी रोट को Haskell को अत्यधिक स्वच्छ कार्यों के लिए फैलाते हैं।
सब कुछ सिक्के के लिए अपने फ्लिप पक्ष है।
फिर सब कुछ एरे और पॉइंटर्स के बजाय ऑब्जेक्ट्स और फ़ंक्शंस में क्यों गया?
इस लेख को मेरे लेख
"प्रोग्रामिंग में उपयोगकर्ता-परिभाषित डेटा प्रकारों का विकास" का सामान्यीकरण कहा जा सकता है।
यह समझने के लिए कि ऑब्जेक्ट और फ़ंक्शंस इतने गलत क्यों हैं, आइए उपरोक्त भाषाओं पर एक नज़र डालें।
उदाहरण 1
हमारे पास PHP और एक व्यवसाय कार्ड साइट दोनों हैं। लगभग निश्चित रूप से, न केवल रूपरेखा लगभग अनुपस्थित हैं, बल्कि एक आम तौर पर समझदार संरचना भी है।
यदि यह साइट धीरे-धीरे विकसित होती है, तो हमारे पास फ़ंक्शन, सरणियां होंगी, फिर ऑब्जेक्ट्स दिखाई देंगे, दृढ़ता से ऑब्जेक्ट-फ्रेम तक।
जैसा कि हम देख सकते हैं, साइट की बढ़ती जटिलता हमें कार्यक्रमों में जटिलता लाने के लिए मजबूर करती है। सबसे विरोधाभासी बात यह है कि जटिलता को कम करने के लिए जटिलता का परिचय दिया जाता है (जबकि उच्च स्तर पर जाने पर)। वस्तुओं का उपयोग करने वाली एक अच्छी तरह से लिखित साइट खो जाएगी यदि सब कुछ एक प्रक्रियात्मक दृष्टिकोण के लिए फिर से लिखा गया है।
उदाहरण 2
कोडांतरक। आप इस पर एक ऑपरेटिंग सिस्टम भी लिख सकते हैं, जैसे कि KolibriOS के लोग करते हैं, उदाहरण के लिए, लेकिन चलो ईमानदार रहें, इसका उपयोग करें जहां आप इसके बिना नहीं कर सकते।
कुछ सरल के लिए, वे ज्यादातर सी का उपयोग करते हैं, बहुत कम अक्सर पास्कल, बेसिक। और आप सी में एक ओएस लिख सकते हैं (उदाहरण के लिए, लिनक्स खुद), लेकिन अब यह आमतौर पर बड़ी परियोजनाओं के लिए बहुत कम उपयोग किया जाता है। और यह इस तथ्य के बावजूद कि सी कई प्रोग्रामिंग भाषाओं का लिंगुआ फ्रेंका है।
एल्गोरिदम की बढ़ती जटिलता अब भाषा की क्षमताओं का
गहन उपयोग करना संभव नहीं बनाती है, आपको इसे
बड़े पैमाने पर उपयोग करना होगा!
अब जटिल परियोजनाओं के लिए, जावा, सी ++, सी #, ... का उपयोग किया जाता है - अत्यधिक वस्तु भाषाएं।
कार्यात्मक प्रोग्रामिंग को जटिलता को हल करने के लिए एक वैकल्पिक दृष्टिकोण के रूप में माना जा सकता है - लिस्प और लिस्प जैसी भाषाएं C की शक्ति के बराबर हैं, OCaml C ++ की तुलना में और यहां तक कि उच्चतर हैं (मॉड्यूल जैसे ऑब्जेक्ट्स में लगभग समान शक्ति होती है), Haskell अधिक है जावा (इसके बारे में अधिक जानकारी)।
लब्बोलुआब यह है कि प्रत्येक तरीके / कार्य / ऑब्जेक्ट / ... केवल उनकी जटिलता की सीमा को हल करते हैं।
और
2+2 को
(2).(+)((2)) रूप में विचार करने के लिए
(2).(+)((2)) - का अर्थ है कि वस्तु एक जटिल इकाई है, और हल्की चीजें बस उस पर प्रोग्राम नहीं की जाती हैं। रूबी जैसी भाषाएं जटिल शर्करा की इस सीमा को कम करने में मदद करती हैं।
वस्तुएं
उस लेख में यह कहा गया है कि "OOP और FI अप्रभावी हैं यदि आप उनके चरम पर जाते हैं तो इससे कम नहीं है।"
लेकिन मुझे लगता है कि यह उनका मुख्य "दोष" नहीं है।
वस्तुओं का उपयोग करते हुए गहन समाधान (बड़ी परियोजनाओं के लिए) समाप्त हो गए हैं, और यह वस्तुओं के बारे में ठीक से मुख्य शिकायत है - व्यापक समाधान उस सुंदरता, सादगी और प्रभावशीलता नहीं देते हैं। और नाइटपैकिंग शुरू होती है। उदाहरण के लिए, जैसे: "फ़ंक्शंस एक मौलिक अवधारणा है, जबकि ऑब्जेक्ट केवल उनमें होते हैं।"
मेरा सुझाव है कि आप इस नाइट-पिकिंग को एक अलग दृष्टिकोण से देखें: यदि आप किसी फ़ंक्शन को ऑब्जेक्ट के रूप में मानते हैं, तो आप देख सकते हैं कि यह जटिलता को स्केल करने के लिए एक उपकरण भी है।
बेशक, स्केलिंग को फ्रैक्टल स्केलिंग के रूप में समझा जाता है - अगर हमें कोई समस्या है - हम छोटी समस्याओं को हल करते हैं, और हम एक ही तरीकों के साथ एक ही तरीके से बड़ी समस्याओं को हल करते हैं, और बड़ी समस्याओं को भी एक ही तरीकों से बड़ी समस्याओं को हल करते हैं।
ऑब्जेक्ट हमारे कार्यों को स्केल करने के लिए एक उपकरण हैं। मेरे द्वारा बताए गए लेख में, मैंने ऑब्जेक्ट्स को उपयोगकर्ता डेटा कहा है, जो इसके साथ काम करने के लिए टूल को सहेजना संभव बनाता है।
यह वही है जिसने वस्तुओं को इतना लोकप्रिय बनाया है - वे आसानी से बड़े पैमाने पर हैं।
उदाहरण 3
ग्रह पृथ्वी। नीचे से ऊपर प्रोग्राम करते हैं। हमारे पास इमारतें, संरचनाएं और लोग हैं। बड़े पैमाने पर गाँव, शहर और मानव प्रवाह होंगे। एक और स्तर ऊपर जिलों, क्षेत्रों, मेगासिटी और जनसंख्या प्रवास को देखना चाहिए। देशों और लोगों की संख्या अधिक होगी। महाद्वीप और विदेश नीति और भी अधिक होगी। इससे भी अधिक पृथ्वी और मानवता होगी।
हालांकि, हमें फ्रैक्टल स्केलिंग की कमी पर ध्यान देना चाहिए। जैसा कि आप जानते हैं, एक प्रणाली तत्वों का एक संग्रह है, जबकि इसमें ऐसे गुण हैं जो तत्वों का योग नहीं रखते हैं। यह छोटा है, लेकिन सबसे महत्वपूर्ण भत्ता है, जो धीरे-धीरे फ्रैक्टल स्केलिंग के साथ घुल जाता है - आपको हर स्तर के लिए लड़ना होगा, क्योंकि भंग होने का उल्लंघन करना होगा। विशेष रूप से, इसलिए, वस्तुओं के बहुत बड़े पदानुक्रम का उत्पादन नहीं करना प्रस्तावित है।
कक्षाएं टाइप करें
क्या ऐसा कुछ है जो वस्तुओं की तुलना में अधिक आसानी से तराजू है? जैसा कि मैंने एक अन्य लेख में बताया है, वहाँ है।
ये हास्केल में टाइप क्लास (वे टाइप क्लास) हैं, स्काला द्वारा शुरू किया गया एक समान तंत्र (हालांकि तंत्र वहां काफी जटिल है), और एक वस्तु एनालॉग - पर्ल में भूमिकाएं।
जैसा कि आप देख सकते हैं, ये सबसे लोकप्रिय भाषाओं से दूर हैं।
यदि आप देखें, तो आप देख सकते हैं कि अब प्रकार वर्ग शक्ति के मामले में सुविधाओं से आगे निकल गए हैं और एक गहन पथ का अनुसरण कर रहे हैं। उन्होंने अभी तक छत पर आराम नहीं किया है।
निष्कर्ष
कार्यक्रमों की जटिलता बढ़ रही है। OOP और FP के साथ सब कुछ ठीक है।
यह जटिलता की तेजी से स्केलिंग के साथ परिमाण का एक क्रम नहीं है, क्योंकि जटिलता गहन क्षमताओं की तुलना में तेजी से बढ़ती है।