पर्ल/मूस ओओ डिज़ाइन, पैकेज पदानुक्रम

Question

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

उदाहरण - अब एक बहुत आसान आवेदन (वेब ​​और कमांड लाइन इंटरफेस) का सामना करना पड़:

• पहले से ही प्रमाणीकृत छात्र एक ज़िप-फाइल (क्या एक प्रतिपादन काम होता है)
• को फ़ाइल अनज़िप और अपलोड कर देती है नई निर्देशिका और जाँच यह सामग्री दी गई है और शून्य या अधिक छवियों (exatly एक फ़ाइल commands.txt शामिल करना चाहिए)
• यदि सामग्री ठीक है - निर्देशिका के लिए बुलाया जगह ले जाने: JobRepository (किसी अन्य निर्देशिका)
• उपयोगकर्ता अगर फैसला प्रतिपादन काम चलाने के लिए - वैश्विक प्रतिपादन कतार (फिर से, एक और निर्देशिका)
• किसी अन्य प्रक्रिया कतार (फीफो - IPC::DirQueue के साथ बनाया गया) से नौकरियों लेता है के लिए अपने ही JobRepository से काम भेजने के लिए और प्रतिपादन प्रक्रिया निष्पादित
• समाप्त होने पर, परिणाम उन में JobRepository/result निर्देशिका
• भेजने ईमेल उपयोगकर्ता के लिए रखा
• छात्र ज़िपित परिणाम

डाउनलोड कर सकते हैं bash में यह कुछ के साथ संभव है "नहीं जटिल "बैश स्क्रिप्ट के लिए - लेकिन मैं पर्ल (क्योंकि वेब इंटरफेस) में यह करना चाहते हैं - और चाहते अभ्यास perlish (मूस) वस्तु डिजाइन ...

और यहाँ मेरी समस्या शुरू होता है।

कोशिश की "विज़ुअल" संज्ञा-विश्लेषण दृष्टिकोण और अगली छवि बनाएं।

, छवि प्रकाशित किया गया था, क्योंकि यह के रूप में "छोटा" है:

package Iren::JobRepo; 
use Moose; 
use warnings; 
has 'Jobs' => (is => 'rw', isa=>ArrayRef[Iren::Job]); 
… 
method AddJob { 
... 
} 

आदि

आप देख सकते हैं, यह वास्तव में सरल है - लेकिन immediatelly कुछ निर्णय का सामना करना पड़ समस्या, उदाहरण:

• अनजिप/ज़िप/चेकजोब विधियों को किस ऑब्जेक्ट को करना चाहिए? यह संबंधित है: जॉब रिपोजिटरी नौकरी "ज़िप" स्वयं ही?
• उपयोगकर्ता को कौन सी ऑब्जेक्ट ईमेल भेजनी चाहिए? $user->send_email - मुझे मूर्खतापूर्ण आता है, क्योंकि हम उपयोगकर्ताओं को ईमेल भेजते हैं, न कि उपयोगकर्ता को ...
• "कौन" को उपयोगकर्ता के जॉबरेपो से रेंडरक्यूयू में नौकरी भेजनी चाहिए? JobRepo->SendJobToRenderQueue या मुझे कुछ RenderQueue->addJob विधि पर कॉल करना चाहिए?
• क्या वस्तु चाहिए ईसा IPC::DirQueue का उपयोग करना चाहिए -
• परिपत्र परिभाषाओं (RenderQueue की implememtation होना चाहिए)। उपयोगकर्ता में जॉब रिपोजिटरी, रिपोजिटरी में कई नौकरियां हैं, लेकिन नौकरी है? एक उपयोगकर्ता? (पता करने के लिए काम संबंधित जिसे करने की जरूरत है) - और इतने पर ..

आप देख सकते हैं, कोई भूमिका, यहाँ कोई लक्षण - कुछ भी नहीं है - यह सरल है ... - लेकिन सवाल का पूरा :(

किसी को भी गंदगी को साफ मदद कर सकते हैं क्या "अच्छा" पैकेज पदानुक्रम होना चाहिए

तो, मैं सच में खो रहा हूँ और मैं अपने आप को निराश करने के लिए शुरू कर दिया है अतिरिक्त सवाल (मुझे पता है, इन राय आधारित हैं)?। - लेकिन मुझे उनसे पूछना चाहिए ...

• पर्ल/मूस के लिए अच्छा ऑब्जेक्ट डिज़ाइन कैसे सीखें? (शायद मैं कभी भी दूसरी भाषा का उपयोग नहीं करूंगा)
• ऑब्जेक्ट डिज़ाइन (और स्टैक ओवरफ्लो भी) के बारे में Google को खोजते हुए कई बार "चार" पुस्तक (और कुछ अन्य) का उद्धरण दिया गया है। लेकिन आमतौर पर जावा के लिए। पर्ल/मूस के लिए खरीदना उचित है? या यहां पर्ल/मूस के लिए कुछ और अच्छी किताबें हैं?
• कुछ अच्छी तकनीक है कि उचित ऑब्जेक्ट डिज़ाइन कैसे जांचें?
• यूएमएल से कोड जनरेटर शायद मूस के लिए मौजूद नहीं है - या यहां कुछ उपयोग करने योग्य और पुनर्निर्मित है?
• बस - आप अपने ऑब्जेक्ट पदानुक्रम/भूमिकाओं/लक्षणों आदि को कैसे महारत हासिल करते हैं ...? जबकि मैं उदाहरण पढ़ रहा हूँ - मैं समझता हूँ $cat->diets :) - लेकिन कुछ नया करने में माहिर - मेरे लिए खराब है ...

पाठ की दीवार के लिए खेद है। मुझे अच्छी किताब या कुछ भी मदद करने के लिए कोई संकेतक मिल जाएगा ...

Answer 1

क्या ऑब्जेक्ट को अनजिप/ज़िप/चेकजोब विधियों को करना चाहिए?

JobRepository

क्या वस्तु उपयोगकर्ता को ईमेल भेजने चाहिए?

RenderQueue

मैं कुछ RenderQueue-> addJob विधि बुलाना चाहिए?

हाँ, इसे इस तरह से करें। ज़िम्मेदारी RenderQueue पर पड़ती है क्योंकि यह अकेले ही यह तय कर सकती है कि नौकरी स्वीकार करनी है या नहीं।

क्या वस्तु चाहिए ईसा आईपीसी :: DirQueue

म्यू उपयोग करना चाहिए।उत्तराधिकारी मत बनो, बस प्रतिनिधि।

उपयोगकर्ता JobRepository

यह गलत है है, उसे निकाल दें।

लेकिन नौकरी है? एक उपयोगकर्ता?

सही।

---

अपने डिजाइन के अंतिम दो अंक यह बेहद मदद की है होगा यदि आप यूएमएल से पहले एक ER diagram आकर्षित किया है।

Answer 2

सामग्री @daxim का जवाब नहीं दिया:

• कैसे पर्ल/मूस के लिए अच्छा वस्तु डिजाइन जानने के लिए? (मैं कर रहा हूँ शायद किसी अन्य भाषा का उपयोग कभी नहीं होगा)

• जानें सामान्य OO डिजाइन पहले
• फिर भूमिकाओं के बारे में जानने (आप मूल बातें पर अच्छी पकड़ है लगता है)। वे कई मामलों में आपके डिजाइन को सरल बनाने में मदद करते हैं और जावा ओओ का हिस्सा नहीं हैं, इसलिए आम तौर पर मूल ओओ साहित्य में शामिल नहीं होते हैं।
• पर्ल विशिष्ट सामग्री के लिए, मैं अत्यधिक क्रोनिक की "आधुनिक पर्ल" पुस्तक के साथ-साथ अपने आधुनिक पर्ल ब्लॉग की पूरी सामग्री की भी अनुशंसा करता हूं। पुस्तक खरीदी जा सकती है लेकिन आईआईआरसी भी मुफ्त में उपलब्ध है।
• इसके अलावा, यह देखने के लिए कि आपको ओओ का उपयोग करने की आवश्यकता नहीं है, लेकिन पर्ल की अन्य शक्ति, अत्यधिक अनुशंसा करते हैं कि आप मुफ्त "उच्च आदेश पर्ल" पुस्तक पढ़ें।
• सुनिश्चित करें कि व्यावहारिक कोडिंग के लिए, आप उच्च स्तरीय डिज़ाइन चीजों को समझते हैं, आप पर्ल 5 के मूल ओओ के बजाय मूस (म्यू) में देखते हैं। स्टार्टर्स के लिए "moose प्रस्तुति perl" के लिए Google।

• वस्तु डिजाइन के बारे में गूगल खोज (और Stackoverflow भी) कई बार "चार की गांड" पुस्तक (और कुछ अन्य लोगों) उद्धृत किया जाता है। लेकिन आमतौर पर जावा के लिए। पर्ल/मूस के लिए खरीदना उचित है? या यहां पर्ल/मूस के लिए कुछ और अच्छी किताबें हैं?

• GOF पुस्तक निश्चित रूप से एक प्रोग्रामर के रूप में अपने आप को सुधार करने के लिए पढ़ने के लायक है, भले ही पैटर्न में से कुछ में यह Javacific हैं।
• अधिक विशेष रूप से, यह Norvig के Design Patterns in Dynamic Languages
• पर्ल पर एक और अच्छा परिप्रेक्ष्य की रोशनी में पढ़ सकते हैं और GOF here
• पर्ल डिजाइन पैटर्न के लिए है, को देखने के फिल चाउ के (कुछ दिनांकित) पुस्तक: part 1, part 2।
• देखें this PerlMonks discussion

• कैसे उचित वस्तु डिजाइन की जाँच करने के लिए कुछ अच्छी तकनीक है? (1) आंखों की एक दूसरी जोड़ी और (2) देखें कि आपके अनुग्रह करना रखरखाव और पुन: उपयोग करने के लिए ऊपर रखती है साथ डिजाइन समीक्षा:

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

अंगूठे का एक अच्छा नियम यह है: यदि आपको कुछ तरीकों को बदलने की ज़रूरत है, तो संभवतः, आपके कोड को कितना बदलने की आवश्यकता होगी? सबसे अच्छा डिजाइन वह है जो परिवर्तन को कम करता है।

• बस - कैसे आप अपने वस्तु पदानुक्रम/भूमिकाएँ/लक्षण आदि माहिर है ...? जबकि मैं उदाहरण पढ़ रहा हूँ - मैं समझता हूँ $ बिल्ली> आहार :) - लेकिन कुछ नया करने में माहिर - मेरे लिए खराब है ...

अभ्यास। आदर्श रूप से, एक ट्यूटोरियल/पुस्तक द्वारा हल की गई समस्या ढूंढें, स्वयं को पहले हल करें, फिर देखें कि वे इसे कैसे हल करते हैं। तब codereview.SE करने के लिए अपने सबसे अच्छा संयुक्त समाधान पोस्ट और पूछते हैं कि यह :)

---

परिपत्र परिभाषाओं सुधार किया जा सकता। उपयोगकर्ता के पास जॉब रिपोजिटरी है, रिपोजिटरी में कई नौकरियां हैं, लेकिन नौकरी है? एक उपयोगकर्ता? (यह जानने की जरूरत है कि किसके पास नौकरी है) - और इसी तरह ..

नहीं, आपको यह जानने की आवश्यकता नहीं है कि नौकरी किसके अंतर्गत है। मैंने समझाया कि क्यों कुछ हफ्ते पहले - एक बहुत ही समान प्रश्न पूछा गया था और यहां उत्तर दिया गया: OO Design Patterns with Perl।

लघु संस्करण: वास्तविक कोड में, आप किसी भी उपयोगकर्ता के बिना नौकरी के साथ कभी भी शुरू होने की संभावना नहीं रखते हैं - जब तक आप नौकरी पर जाते हैं, तो संभव है कि आप पहले से ही एक ज्ञात उपयोगकर्ता के साथ शुरू हो जाएं और उस से नौकरी भंडार प्राप्त करें उपयोगकर्ता। आपको अब उपयोगकर्ता को फिर से ढूंढने की आवश्यकता नहीं है।