पर्ल में प्रोग्रामिंग शैली

Question

मैं जावा में काम करता हूं इसलिए मूल रूप से मैं कोडिंग के दौरान ओओपी प्रतिमान का उपयोग करता हूं। मैं पर्ल में काम करना शुरू करने वाला हूं और मैं सोच रहा था कि पर्ल डेवलपर्स क्या प्रतिमान है। विकी में यह उल्लेख है कि यह कई प्रतिमानों का समर्थन करता है लेकिन मुझे यकीन नहीं है कि मैं इसे समझता हूं क्योंकि यह एक पटकथा भाषा है।

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

नोट: यह समालोचना पर्ल का सवाल नहीं है। मुझे वास्तव में पर्ल में काम करना है और मैं यह समझना चाहूंगा कि मेरे कार्यक्रम का मौजूदा तरीका कैसे बदलेगा।

Comments

अधिक गंभीर नोट पर, "पर्ल दर्शन" के लिए एक Google खोज करें, और यहाँ एक नज़र डालें: perldesignpatterns.com

— रॉबर्ट हार्वे

पर्ल OOP का समर्थन करता है। आप आभासी कार्यों आदि को लागू करने वाले वर्ग पदानुक्रम का निर्माण कर सकते हैं। सबसे आम उपयोग नहीं है लेकिन यह किया जा सकता है।

— मार्टिन यॉर्क

"चूंकि यह एक स्क्रिप्टिंग भाषा है" - इसका उपयोग इस तरह किया जा सकता है, लेकिन याद रखें कि पर्ल जावा के समान ही एक वीएम है - पर्ल को बायटेकोड पर संकलित (मक्खी पर) हो जाता है जिसे तब निष्पादित किया जाता है। कोई JIT नहीं है, लेकिन इसके अलावा यह अभी भी एक वर्चुअल मशीन है जो आपके कोड को चला रही है।

— टंकटालस

Answer 1

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

पर्ल के बहु-प्रतिमान प्रकृति को श्वार्ट्जियन परिवर्तन जैसी चीजों में देखा जा सकता है, जिनके लिए इसके बहुत ही कार्यात्मक पहलू हैं (लिस्प में इसे "डेकोरेट-सॉर्स-अंडरकोरेट" के रूप में जाना जाता है)। OOP मौजूद है, जैसा कि प्रक्रियात्मक है (C प्रोग्रामिंग की तरह) और अनिवार्य ("ऐसा करें तो यह") जैसे बैश।

डिज़ाइन पैटर्न सामान्य समस्याओं के समाधान का समाधान कर रहे हैं। वे हर भाषा में मौजूद हैं। कभी-कभी इन पैटर्नों को मुहावरे कहा जाता है, हालांकि यह उन चीजों को भी संदर्भित कर सकता है जो एक पैटर्न की तुलना में बहुत अधिक सरल हैं।

जब आवश्यक हो, क्लासिक GOF डिज़ाइन पैटर्न के कई पर्ल में लागू किया जा सकता है। पर्ल डिज़ाइन पैटर्न में कई सामान्य नाम होंगे जो लोग GOF से परिचित हैं। यह आवश्यक नहीं है कि यह सभी मुहावरेदार हो।

पर्ल में डिजाइन पैटर्न की खोज करते समय, मार्क डोमिनस द्वारा नहीं "डिजाइन पैटर्न" पर भी ध्यान दें ।

कई लोग मानते हैं कि डिज़ाइन पैटर्न भाषा की कमियां हैं । उस परिप्रेक्ष्य में, Iterator जैसे डिज़ाइन पैटर्न अक्सर पर्ल में अनावश्यक होते हैं। हमेशा नहीं - लेकिन अक्सर।

सबसे पहले, मुहावरेदार पर्ल लिखें। Perl में C, या perl में लिस्प, या जावा में java लिखने की कोशिश न करें। पर्ल प्रति है। यदि कोई समस्या है जो मुहावरे से बड़ा हो जाता है तो पर्ल को संभाल सकता है और आपको अधिक जटिल वर्ग संरचनाओं की आवश्यकता होती है, तो उन्हें लिखें। पता है कि "यह समस्या अब एक सार कारखाने की जरूरत के बिंदु पर" पहचानने में सक्षम होने के लिए डिज़ाइन पैटर्न को जानती है - लेकिन अगर आपको एक की आवश्यकता नहीं है, तो पर्ल में एक सार कारखाना बनाने की कोशिश शुरू न करें।

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

Comments

+ 1. जानकारी हासिल करना। इन सभी को ध्यान में रखते हुए कि कैसे एसओ में कई पद हैं जो एक पुरानी भाषा के साथ पर्ल की रक्षा / हमला करने की कोशिश कर रहे हैं? मुझे शक्तिशाली और उपयोगी लगता है।

— user10326

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

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

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

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

— डेविड

Answer 2

प्रतिमानों पर पर्ल का रुख TMTOWTDI है (इसे करने का एक से अधिक तरीका है)। यह एक कारण है कि बहुत सारे लोग मजाक में पर्ल को केवल एक भाषा कहते हैं । इसे पढ़ने की तुलना में इसे लिखना बहुत आसान हो सकता है, क्योंकि किसी अन्य व्यक्ति की शैली आपके लिए पूरी तरह से अलग हो सकती है।

कहा जा रहा है कि OOP निश्चित रूप से पर्ल में समर्थित है। यदि आप बहुत सारे थर्ड पार्टी कोड का उपयोग कर रहे हैं, तो यह OOP हो सकता है या नहीं भी हो सकता है, लेकिन आपके अपने कोड के लिए आप OOP को अपने दिल की सामग्री के लिए कर सकते हैं। मैंने वास्तव में पहली बार OOP को पर्ल में सीखा था। मैंने पहले C ++ की कोशिश की और यह किसी कारण से "क्लिक" नहीं हुआ।

Comments

क्यों कई लोग इसे एक बुरा कैरियर विकल्प मानते हैं? ऐसा लगता है कि यह शक्तिशाली है और टूलसेट के हिस्से के रूप में अन्य भाषाओं को पूरक कर सकता है।

— user10326

मान लें कि अन्य भाषाएँ लगभग शक्तिशाली हैं और उनमें बहुत अधिक अंतर्निहित संरचना है। कंपनियों को संरचना पसंद है।

— कार्ल बेवेलफेल्ट

एक अच्छा के लिए पर्ल OOP जाँच ट्यूटोरियल codeproject.com/Articles/3152/Perl-Object-Oriented-Programming

— Pmarcoen

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

— मैट फ्राई

मैंने पर्ल को कभी खराब करियर विकल्प नहीं पाया। एक स्थानीय पर्ल मोंगर्स समूह का पता लगाएं, और बाधाओं यह है कि लगभग हर बैठक में कोई व्यक्ति पर्ल नौकरी के उद्घाटन का उल्लेख करेगा।

— डेविड

Answer 3

मैं एक ही स्थिति में हूं, मैं जावा का उपयोग लूओंग समय के लिए कर रहा हूं,

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

बस पर्ल के साथ याद रखें कि ऐसा करने का एक और तरीका है, मैंने कुछ घंटों को निश्चित कोड को देखने और इसे संशोधित करने में खर्च किया है, लेकिन अंत में यह एक सरल वाक्यविन्यास त्रुटि के साथ किया जाता है।

Answer 4

पर्ल में कोड का पुन: उपयोग करने के कई तरीके हैं। बहुत सारे उदाहरण दृष्टिकोण के बीच अंतर को स्पष्ट नहीं करते हैं और कई वर्ग कम से कम दो का उपयोग करते हैं।

मैं ओओ शैली का यथासंभव उपयोग करने की सलाह देता हूं और केवल एक्सपोर्टर का उपयोग करता हूं जब आपके पास कम से कम तीन या अधिक कक्षाएं होती हैं जिन्हें उपयोगिता कार्यों के अपेक्षाकृत छोटे क्लस्टर की आवश्यकता होती है।

इसलिए:

package Foo; 
use Foo::Util qw(util) ;
use strict ; 

sub foo {
}

sub bar {
}

1; 

package Foo::Bar ;
use Foo ; 
use Foo::Util qw(util) ;
our @ISA = qw(Foo) ; 
use strict ; 

sub bar {
}

1; 

package Foo::Util ; 
use Exporter ; 
our @ISA = qw(Exporter) ; 
our @EXPORT = qw(util) ;
use strict ; 

sub util {
}

1;

मैं ओओ दृष्टिकोण और EXPORTERकोड उपलब्धता के दो अलग-अलग आयामों के रूप में दृष्टिकोण की कल्पना करना पसंद करता हूं , जैसे कि फ़ंक्शन x या y अक्ष से वर्तमान पैकेज में आ रहे थे।

उपरोक्त उदाहरण में:

Foo::Barfoo()कक्षा से विधि प्राप्त करता हैFoo

Foo::Barएक bar()विधि को परिभाषित करता है ताकि बहुरूपी विधि bar()वर्ग से उत्पन्न न होFoo

दोनों वर्गों Fooऔर पैकेज से समारोह ( विधि नहीं ) Foo::Barप्राप्त EXPORTEDकरते हैं ( वर्ग नहीं )util()Foo::Util

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

आम तौर पर यदि कोई फ़ंक्शन अखंड और अपेक्षाकृत गूंगा है, तो एक्सपोर्टर का उपयोग करें, अन्यथा विरासत का उपयोग करें। लेकिन EXPORTERजब तक आप जो करने जा रहे हैं उसका उपयोग न करें, तो 3 या 4 से अधिक पैकेजों को शामिल करने की संभावना है।