2009-06-11 15 views
39

मैं अभी भी पर्ल प्रोग्रामिंग के लिए अपेक्षाकृत नया हूं, लेकिन मुझे पता है कि पर्ल 5 ओओ मूल रूप से कैसे काम करता है। हालांकि, मैंने कभी भी पर्ल 5 ओओ के साथ कोई परियोजना नहीं बनाई है, इसलिए मुझे पूरा यकीन है कि मैं कई नुकसान में भाग जाऊंगा।क्या मुझे पहले पर्ल 5 ओओ या मूस सीखना चाहिए?

हाल ही में मैं Moose मॉड्यूल के बारे में प्रचार की खोज की। मैंने सीपीएएन पर कुछ दस्तावेज देखे और मैंने इसे काफी रोचक पाया और मुझे डेवलपर के रूप में बहुत मदद की। इसके अतिरिक्त, यह बहुत स्थिर और भरोसेमंद प्रतीत होता है।

क्या मुझे मूल पर्ल 5 ओओ सिंटैक्स के साथ काम करना चाहिए, जब तक कि मुझे इसके बारे में बहुत परिचित न हो (यह जानने के लिए कि चरणों के पीछे क्या चल रहा है), या आपको लगता है कि मुझे आगे बढ़ना चाहिए और मूस का उपयोग करके सीधे विकासशील अनुप्रयोगों को शुरू करना चाहिए ? या मुझे माउस को भी कोशिश करनी चाहिए?

उस पर किसी भी विचार और अनुभव की सराहना की जाती है।

अग्रिम धन्यवाद!

उत्तर

36

जैसा कि हर किसी ने पर्ल में ओओ के बारे में मूल बातें सीखने की ओर इशारा किया है, न केवल वहां पर अधिकांश गैर-मूस पैकेजों के साथ, बल्कि मूस के साथ ही मूस के साथ ही मूल रूप से मानक पर्ल ओओ का उपयोग करता है लेआउट। असल में एक बार जब आप सहज महसूस करते हैं तो आप समझते हैं कि Moose::Manual::Unsweetend दिखा रहा है कि आपको पर्ल में ओओ सिद्धांतों का उचित समझ होगा। डेमियन कॉनवे ऑब्जेक्ट ओरिएंटेड पर्ल बुक ऑब्जेक्ट ओरिएंटेशन अवधि के लिए केवल उत्कृष्ट पर्ल के स्वाद का उत्कृष्ट परिचय है। मैं इसे पढ़ने का सुझाव देता हूं, या कम से कम इसका पहला भाग।

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

प्रकटीकरण: मैं कोर मूस डेवलपर हूं, और माउस पर और साथ काम किया है।

+0

"Moose-Unsweetened" से ऊपर का लिंक मेरे लिए काम नहीं करता था। लेकिन http://search.cpan.org/search?query=Moose%3A%3AUnsweetened&mode=all मिला मॉड्यूल – lexu

+0

लिंक को ठीक किया गया, धन्यवाद – perigrin

+0

मुझे लगता है कि आपका मतलब है "मूस का उपयोग न करने का कोई कारण नहीं है" उस अनुच्छेद में अगली वाक्य। – mmrobins

10

पहले मूल बातें के साथ सहज रहें। जब तक आप बहुत सारी ओओ जावास्क्रिप्ट नहीं कर लेते हैं, ओओ पर्ल थोड़ा अजीब लग रहा है, और कुछ चीजें जो मूस या किसी अन्य लाइब्रेरी में डरावनी लगती हैं।

+1

मैं इससे असहमत हूं; मूस स्मालटॉक या सीएलओएस से कक्षा-आधारित ओओ की तरह है। (या जावा/सी ++/सी # जैसी अन्य भाषाओं में से एक) – jrockway

+4

जावास्क्रिप्ट ओओ एक खराब तुलना है। यह ऑब्जेक्ट विरासत का उपयोग कर एक प्रोटोटाइप (यानी वर्गीकृत) भाषा है जो कि बहुत आम है कि ओओ कार्यान्वयन (सी #, सी ++, जावा, पायथन, पर्ल और रूबी) कैसे काम करते हैं। केवल वैध तुलना के बारे में वे दोनों मेज पर ज्यादा नहीं लाते हैं। – Schwern

+0

पर्ल ऑब्जेक्ट सिस्टम पायथन आधारित है, इसलिए यह पाइथन –

31

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

+8

अधिकांश * आपकी * पर्ल दुनिया मूस नहीं है, शायद;) – jrockway

+8

चॉन, जॉन। आप मुझे और साथ ही जानते हैं कि अधिकांश पर्ल कोड बेस आउट हैं जो मूस का उपयोग नहीं कर रहे हैं। यदि वे कोड बेस किसी ओओ का उपयोग कर रहे हैं, तो "सादा पुराना पर्ल 5 ओओ" उपयोगी होगा। उसने कहा, यदि आप बस पर्ल में जा रहे हैं, तो आप अपने स्वयं के अनुप्रयोगों के लिए मूस से शुरू करके गलत नहीं होंगे। यह अत्यधिक उत्पादक, बहुत विश्वसनीय, और बस अधिक मजेदार है। –

+4

इस उत्तर में एक निहितार्थ है कि यह एक या/या सवाल है। अगर आप पहले मूस सीखते हैं तो अचानक आपका मस्तिष्क भरा हुआ है और इसे करने के पर्ल के ओओ तरीके से नहीं सीख सकता है। शायद आप नहीं चाहते हैं, लेकिन आप अभी भी कर सकते हैं। – Schwern

5

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

मैं भी उपयोग किया है वस्तु :: InsideOut, जो मूस की तरह एक बहुत कुछ है और यह भी साथ छेड़छाड़ किए जाने पर आपके वस्तु चर की रक्षा में मदद करता है।

एक और ध्यान दें, मैं समझता हूँ कि पर्ल 6 वस्तुओं ज्यादा मूस वस्तुओं तरह होगा .. तो सीखने मूस पर्ल 6. के लिए आप तैयार करेंगे

2

मूस उपयोगी है, लेकिन आप अभी भी पर्ल OO उचित के बारे में जानने के लिए चाहते हो सकता है leaky abstraction problem से खुद को ढालने के लिए।

पर्ल OO ही नहीं बल्कि बालों है, लेकिन इस किताब को यह बहुत आसान पचाने के लिए बनाता है: Intermediate Perl। अत्यधिक सिफारिशित।

+3

यह सच है। मूस किसी को आपके नेटवर्क केबल काटने से रोकने में सक्षम नहीं होगा, इसलिए आपको उस समस्या के आसपास काम करने के लिए जोएल के लेख को पढ़ना चाहिए। आम तौर पर, मूस ओओ एक रिसाव अमूर्त नहीं है; अगर आपको एमओपी द्वारा संक्षेप में कुछ ऐसी चीज तक पहुंचने की ज़रूरत है, तो आप इसे गलत कर रहे हैं। – jrockway

+1

एक वास्तविक मूस किसी को आपके नेटवर्क केबल्स काटने से रोक सकता है। वो लोग विशाल हैं! –

+2

@brian - लेकिन असली मूस बस अपने नेटवर्क केबल को अपने एंटलर पर फेंक सकता है और इसे टुकड़ों में चिपका सकता है। आधा डेटा केंद्र के साथ। (oups ... माफ करना .. वह आखिरी व्यक्ति एक सन तकनीशियन के बारे में था) – DVK

18

मूस अच्छा है, लेकिन यह सीखने के बारे में निर्णय आपके लक्ष्य पर निर्भर करता है।

तुम सिर्फ OO तकनीक का उपयोग अपने स्वयं के कार्यक्रमों लिखना चाहते हैं, तो यह बहुत अच्छी तरह से लायक डाइविंग मूस में हो सकता है (और अन्य OO तकनीकों के बारे में बाद में चिंता)

आप "एक पर्ल प्रोग्रामर" बनने के लिए चाहते हैं , तो आप मूस ओओ कोड के बाद अधिक गैर-मूस ओओ कोड का सामना करेंगे, इसलिए आपको पहले मूस के बिना कोडिंग से निपटना सीखना चाहिए। मैं एक अच्छा प्रारंभिक बिंदु के रूप में Damian Conway द्वारा ऑब्जेक्ट ओरिएंटेड पर्ल का सुझाव देता हूं।

21

ईमानदारी से, मुझे यकीन नहीं है कि पर्ल के कच्चे ओओ प्राइमेटिव का कितना मूल्यवान ज्ञान अब नए कोड लिखने के लिए है। मैंने अपने कोड में बहुत लंबे समय तक @ISA या "आधार का उपयोग" या "आशीर्वाद" का उपयोग नहीं किया है; कोई भी ओओ मैं मूस एमओपी के माध्यम से करता हूं। (मैं निश्चित रूप से विद्रोही उदाहरण करता हूं, लेकिन मैं सिर्फ "आशीर्वाद" के बजाय $ मेटा-> rebless_instance का उपयोग करता हूं। बहुत साफ करने वाला!)

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

एक उदाहरण के रूप:

#!/usr/bin/env perl 

use strict; 
use warnings; 
use feature ':5.10'; # for 'say' 

use MooseX::Declare; 

class Point { 
    has [qw/x y/] => (is => 'ro', isa => 'Num', required => 1); 

    method new_from_ordered_pair(ClassName $class: Num $x, Num $y){ 
     return $class->new(x => $x, y => $y); 
    } 

    method distance(Point $a: Point $b){ 
     return sqrt(($a->x - $b->x)**2 + ($a->y - $b->y)**2); 
    } 

} 

my $origin = Point->new_from_ordered_pair(0,0); 
my $point = Point->new_from_ordered_pair(3,4); 

say '(3,4) is '. $point->distance($origin). ' units away from the origin.'; 

सूचना कैसे वहाँ पर्ल के कार्यान्वयन के विवरण के साथ कोई और अधिक लड़ाई है। पर्ल में ओओ करने के तरीके के बजाय आप आसानी से अपने कार्यक्रम के ब्योरे के बारे में चिंता कर सकते हैं। आपको "प्वाइंट.pm" फ़ाइल भी नहीं बनाना है, आपके पास कक्षा परिभाषा इनलाइन हो सकती है।

मुझे यह भी लगता है कि यह कोड लगभग किसी भी प्रोग्रामर के लिए तुरंत समझा जा सकता है - यहां तक ​​कि पर्ल या मूस (या मूसएक्स :: घोषणा) के विवरण से परिचित नहीं हैं।

(बीटीडब्लू, इस उदाहरण ने विधि हस्ताक्षर में वाक्यविन्यास के साथ थोड़ा विचित्र रूप से काम किया। आम तौर पर, आपको पहले तर्क के रूप में स्वयं को $ स्वयं कहा जाता है। अगर आप पहले कुछ और आपूर्ति करते हैं: हस्ताक्षर, आप चर के प्रकार और नाम को बदल सकते हैं। मैंने "new_from_ordered_pair" भी लिखा है ताकि आपको हर बार नए तर्कों के रूप में x => $x, y => $y टाइप करना पड़े। यह केवल चीनी है जो मुझे लगता है कि अच्छा है; कुछ भी जादुई नहीं यहाँ हो रहा है।)

अंत में, आपको "मुफ्त में" बहुत कुछ मिलता है। इन प्रयास करें, और उपयोगी त्रुटि संदेश पर ध्यान दें:

Point->new; # x is required 
Point->new_from_ordered_pair('foo', 'bar'); # x needs to be a number 
$point->distance('some string'); # $b needs to be a Point 

आप मुक्त करने के लिए यह सब मिलता है, और यह अपने कार्यक्रम आसान डिबगिंग बनाता है। इससे बचने का कोई कारण नहीं है, यह वास्तव में प्रोग्रामिंग को और अधिक सुखद बनाता है (और यह आपके प्रोग्राम को अधिक विश्वसनीय बनाता है ... मुफ्त में!)

ओह, एक और बात। मूस के साथ, आप अपनी कक्षाओं का आत्मनिरीक्षण कर सकते हैं। यह तुरंत महत्वपूर्ण नहीं हो सकता है, लेकिन यह अच्छा हो सकता है। ओपन Devel :: आरईपीएल, प्रकार प्वाइंट वर्ग लोड करने के लिए ' "test.pl" कर', और फिर कुछ ऐसा कहना:

map { $_->name } Point->meta->get_all_attributes; 

परिणाम ['x', 'y'] है। स्रोत कोड के बिना, आप यह पता लगा सकते हैं कि कक्षा में क्या विशेषताएं हैं। "सादे" पर्ल ओओ के साथ ऐसा करने का प्रयास करें। (बात इस तरह की क्या अमीर MooseX :: नाम स्थान संभव बनाता है। आप आत्मनिरीक्षण की जरूरत नहीं है, लेकिन आप CPAN से विश्वसनीय मॉड्यूल उपयोग करने की क्षमता मज़ा आएगा।)

26

IMHO मैं मूस पहले सीखना होगा। क्यूं कर? हां, अधिकांश पर्ल ओओ मूस कर नहीं किया जाता है। हां, मूस धीमा है (हालांकि Mouse आज़माएं)। हां, बहुत सारे व्यावहारिक कारण हैं कि आपको अंततः इसे कठिन तरीके से सीखना क्यों होगा। लेकिन एक ओवरराइडिंग कारण है।

क्योंकि ओआरओ करने का पर्ल का तरीका आपके मस्तिष्क को मारता है।

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

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

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

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

मूस आपको बॉक्स के बाहर सब कुछ देता है, ताकि आप ऑब्जेक्ट लिखने पर ध्यान केंद्रित कर सकें और ओओ सिस्टम लिखने पर ध्यान केंद्रित न करें।

एक बार जब आपने ओओ को सही तरीके से करना सीख लिया है तो आप पर्ल के ओओ सीख सकते हैं और इसे बीस अन्य तरीकों से कैसे करना है, उनमें से बारह गलत हैं।

4

यह श्वेर्न की पोस्ट पर एक टिप्पणी होने वाला था, लेकिन यह बढ़ गया।

मैं कहूँगा कि मूस "सामान्य" पर्ल OO की तुलना में धीमी है, लेकिन सबसे पहले यह सबसे कोड (समय से पहले अनुकूलन) और दूसरी अगर आप __PACKAGE__->make_immutable करना तो क्रम भूमि के ऊपर का एक बहुत वैसे भी निकाल दिया जाता है के लिए बहुत महत्वपूर्ण नहीं है।

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

2

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

प्रकटीकरण: हम, किताब (श्री बंदर) बनाया है, हालांकि हम इसे (है कि डेव Rolsky और स्टीवन लिटिल था) नहीं लिखा था।

4

ओओपी सीखें जो मूस से पहले पर्ल के साथ आता है।इससे लंबे समय तक आपके लिए यह बहुत आसान हो जाएगा।

संबंधित मुद्दे