मैंने कई बार पहलू-उन्मुख प्रोग्रामिंग के बारे में सुना है, ज्यादातर यह है कि यह प्रोग्रामिंग में "अगली पीढ़ी" तकनीक है और ओओपी को 'मार' करने वाला है।
क्या यह सही है? क्या OOP मरने वाला है या उसका कारण क्या हो सकता है?
OOP प्रौद्योगिकी मृत्यु [बंद]
जवाबों:
किसी भी समय कोई आपको बताता है कि एक सॉफ्टवेयर प्रौद्योगिकी एक दूसरे को मार डालेगी या पूरे बाजार / उपयोग / दर्शकों पर हावी होगी, इसे याद रखें:
एक साने (गतिशील लेकिन स्थिर) पारिस्थितिकी तंत्र व्यापक रूप से विभिन्न प्रकार की प्रजातियों से बना है।
इसका मतलब है कि कोई भी नई हाइप तकनीक हाइप कर्व से गुजरेगी और अंत में उसे समय के माध्यम से विशिष्ट (एस) उद्देश्य मिलेगा और इसके बारे में अनुभव होगा।
इसका मतलब यह भी है कि इस तरह की एक चरम अवधारणा पहलू-उन्मुख प्रोग्रामिंग के रूप में उपयोगी है अगर इसकी आवश्यकता है, अर्थ, हमेशा नहीं और बहुत बार, निहित लागत के कारण।
लेकिन इसमें पहले से ही जगह है, जैसे OOProgramming, जेनेरिक प्रोग्रामिंग की तरह, कार्यात्मक प्रोग्रामिंग की तरह, प्रक्रियात्मक प्रोग्रामिंग की तरह, आदि।
क्या आपने देखा कि जो भाषाएं (और विवादास्पद रूप से लोकप्रिय) अधिक इस्तेमाल की जाती हैं और व्यापक रूप से वास्तविक जीवन में फैलती हैं, वे "शुद्ध नहीं हैं? ऐसा इसलिए है क्योंकि कई प्रतिमानों की अनुमति उन्हें समय के माध्यम से संदर्भ बदलने के लिए और अधिक लचीला बनाती है और वे अधिक उपयोग की संभावनाएं भरती हैं।
1
'शुद्ध नहीं' के लिए +1। बहुत ही आला उपयोगों / शिक्षाविदों को छोड़कर, शुद्ध OOP भाषाएँ विशेष रूप से मृत हैं ।
—
jv42
हम एक शुद्ध OO भाषा पर क्या विचार करेंगे? छोटी बात?
—
झिंगो माओ
AOP की वजह से OOP मरने वाला नहीं है। AOP कुछ मूल्य जोड़ता है, लेकिन यह OOP के साथ सही सह-अस्तित्व में रहता है। मुझे नहीं लगता कि कार्यात्मक प्रोग्रामिंग OOP को मार देगी। OOP कई प्रकार के समस्या डोमेन के लिए बहुत अच्छा है, इसे कार्यात्मक प्रतिमान के साथ प्रतिस्थापित करने का कोई मतलब नहीं होगा।
यह अत्यधिक व्यक्तिपरक है। मुझे नहीं लगता कि OOP एक विशिष्ट समस्या डोमेन के लिए एक अच्छा फिट है, यह एक अच्छा है कि कैसे एक विशिष्ट डेवलपर एक समाधान बनाता है। OOP मरने वाला नहीं है क्योंकि डेवलपर्स प्रतिमान स्विच नहीं कर सकते हैं।
—
रेयानोस
क्लासिक उदाहरण जहां OOP एक अच्छा फिट है GUI हैं। GUI टूलकिट के लिए API की कल्पना करना कठिन है जो कि OO नहीं है, भले ही भाषा क्यों न हो। (दी गई बात यह है कि आमतौर पर शब्द समस्या डोमेन का उपयोग कैसे किया जाता है) एक वास्तविक समस्या डोमेन का एक उदाहरण देने के लिए जहां ओओपी एक अच्छा फिट है: वेयरहाउस स्वचालन। भंडारण और पुनः प्राप्ति वाहनों और उनकी गतिविधियों की मॉडलिंग करना जहां OOP एक प्राकृतिक फिट की तरह लगता है।
—
user281377
OO में व्यक्त किए जाने पर @ammoQ, GUI भयानक होते हैं। यही कारण है कि सभी एपीआई DSLs (WPF और एक जैसे) की ओर बह रहे हैं। यह कहना मुश्किल नहीं है, कहना, Tk - OOP का कोई भी निशान वहाँ नहीं है, लेकिन फिर भी यह बहुत बढ़िया है (प्रोग्रामिंग के लिए, इसके लुक और फील के लिए नहीं), किसी भी ओवरब्लोएटेड जावा OO टूलकिट की तुलना में बहुत बेहतर है। OOP किसी भी एजेंट-आधारित सिमुलेशन (जैसे आप सूचीबद्ध हैं) में वास्तव में अच्छी तरह से फिट बैठता है, लेकिन यह मौजूदा समस्याओं का एक छोटा अनुपात है।
—
एसके-तर्क
Tk के पहले उदाहरणों को देखकर मैं पा सकता हूं कि यह OO कैसे नहीं है? ट्यूटोरियल से: "विजेट ऑब्जेक्ट हैं, कक्षाओं के उदाहरण जो बटन, फ्रेम और इतने पर प्रतिनिधित्व करते हैं।" tkdocs.com/tutorial/conpret.html इससे भी अधिक, डीएसएल स्वयं ओओ प्रोग्रामिंग पर बहुत निर्भर हैं। तो मैं वास्तव में नहीं समझ पा रहा हूं कि आप क्या कहना चाहते हैं?
—
इंका
@ Sk-logic, @ammoQ, @Raynos, @jkocking, मैंने इसे अपने स्वयं के एक प्रश्न में बढ़ावा दिया: programmers.stackexchange.com/questions/88385/ ... मुझे इस पर अधिक स्पष्टीकरण देने में बहुत दिलचस्पी होगी, मैं बहुत दिलचस्पी रखता हूं जानने के लिए दिलचस्पी है।
—
इंका
संक्षिप्त उत्तर: नहीं, मुझे ऐसा नहीं लगता।
लंबा उत्तर: जो मैं AOP से समझता हूं, वह अपने आप में एक प्रोग्रामिंग प्रतिमान नहीं है (जैसा कि, यह OOP को प्रतिस्थापित नहीं करता है), लेकिन इसके अलावा, एक टूलकिट जो आपको छोटे तरीकों, सरल, एकल-जिम्मेदारी वर्गों को लिखने में मदद करता है , वगैरह। लेकिन यह OOP को प्रतिस्थापित नहीं करता है।
वह चीज़ जो OOP को कम से कम (आंशिक रूप से) प्रतिस्थापित या जोड़ती है, कार्यात्मक प्रोग्रामिंग है, जो वास्तव में एक अलग प्रोग्रामिंग प्रतिमान है (हालांकि इसे ओओएल के साथ मिश्रित किया जा सकता है, उदाहरण के लिए स्काला प्रोग्रामिंग भाषा में )। यह अपरिवर्तनीय डेटास्ट्रेक्टर्स और सभी प्रकार की फैंसी सुविधाओं को पसंद करता है जो ओओपी डेवलपर्स को निराश करते हैं, खासकर जब यह संगामिति की बात आती है।
क्रियात्मक <-> इंपीरियल लाइन है। OOP इसके समानांतर है। मुझे लगता है कि प्रक्रियात्मक OOP के दूसरे छोर पर है, लेकिन मुझे यकीन नहीं है। बेशक यह मनोरंजक है कि कार्यात्मक प्रतिमान पुराना है फिर
—
ओओपी
@ रेयानोस, कोई सीधी रेखा नहीं है। ओओपी संभव अमूर्त भाषाओं के एक विशाल (अनंत) सेट के अंदर सिर्फ एक छोटा धातुविज्ञान है। और निश्चित रूप से उनमें से किसी एक के लिए खुद को सीमित करना बेहद बेवकूफी है।
—
तर्क
OOP के बारे में इन दिनों कम बात की जाती है क्योंकि इसके कई स्थितियों में वास्तविक दृष्टिकोण के रूप में माना जाता है। किसी भी तरह के जन आंदोलन के रूप में AOP कभी मैदान में नहीं उतरे।
मुझे याद है कि पहली बार OOPSLA '97 ट्यूटोरियल में बैठकर एस्पेक्ट ओरिएंटेड प्रोग्रामिंग के बारे में सुनना। उन्होंने कहा कि यह ओओ के रास्ते को मारने जा रहा था। तब से, OO केवल बेतहाशा अपेक्षाओं से आगे बढ़ा है। AOP, अभी भी मुश्किल से कंप्यूटिंग उद्योग पर अनिवार्य रूप से कोई प्रभाव नहीं के साथ जाना जाता है। मुझे लगता है कि जवाब स्पष्ट है कि AOP कोई OO हत्यारा नहीं है।
कुछ मौजूदा AOP प्रणालियों को देखें। वे आप पर किसी न किसी रूप में लिखे गए कोड पर निर्भर करते हैं - उदाहरण के लिए, स्प्रिंग एओपी आप पर निर्भर करता है कि आपके तरीके एक वर्ग पर परिभाषित हैं। कैसल विंडसर C # में इसका समर्थन करता है, जो एक वस्तु उन्मुख भाषा है।
आप सैद्धांतिक रूप से OOP से संरचित प्रोग्रामिंग पर स्विच कर सकते हैं और फिर भी AOP रख सकते हैं, लेकिन व्यवहार में, यह मुश्किल होगा। कुछ को उप-लिंक करना आसान है, फ़िल्टर से पहले / बाद में उपयुक्त कॉल करने के लिए प्रासंगिक विधि को ओवरराइड करें, और निर्भरता इंजेक्शन की प्रक्रिया में इसे पास करें।
उपयोगकर्ता द्वारा परिभाषित फ़िल्टर को कॉल करने के लिए डिज़ाइन किए गए एक ट्रैम्पोलिन विधि को रूट करने के लिए स्थिर विधि कॉल को फिर से लिखने की तुलना में यह कठिन है।
इसलिए एक सामान्य कार्यान्वयन के दृष्टिकोण से, AOP को OOP की आवश्यकता होती है।
जबकि OOP निश्चित रूप से चांदी की गोली नहीं है, AOP के लिए भी यही कहा जा सकता है। यह घटक आधारित डिजाइन का समर्थन करता है, हालांकि ग्रैंडर स्कीम में आपके घटक नई वस्तुएं हैं और घटक इंटरफेस मूल रूप से विधियों की एक ट्रांजेक्शनल सूची है, जो कि सच नहीं है ओओपी।
इसके अलावा AOP और घटक आधारित डिज़ाइन एक एनीमिक डेटा मॉडल का समर्थन करते हैं, जो अपने से अधिक चालाक लोगों की आलोचना करते हैं।
http://martinfowler.com/bliki/AnemicDomainModel.html
(मुझे पता है कि उपरोक्त लेख पुराना है, फिर भी आश्चर्यजनक रूप से प्रासंगिक है)
लब्बोलुआब यह है कि एओपी सिस्टम यहां रहने के लिए हैं, लेकिन वे एकदम सही से दूर हैं। कोई भी सिस्टम सही नहीं है।