मैं हाल ही में 'God object' शब्द भर गया था जिसे 'एंटी-पैटर्न' के रूप में वर्णित किया गया था। मैंने खराब कोडिंग प्रथाओं के बारे में सुना होगा, लेकिन मैंने उन्हें कभी वर्णित नहीं सुना होगा।रैवियोली कोड - एक विरोधी पैटर्न क्यों?
तो मैं और अधिक जानने के लिए विकिपीडिया की ओर अग्रसर हुआ, और मैंने पाया कि 'Ravioli code' नामक एंटी-पैटर्न है जिसे "छोटे और (आदर्श) ढीले-युग्मित सॉफ़्टवेयर घटकों द्वारा वर्णित किया गया है।"
मुझे परेशान है - यह एक बुरी बात क्यों है?
Spaghhetti:
स्पेगेटी कोड स्रोत कोड के लिए एक अपमानजनक अवधि
रैवियोली है:
रैवियोली कोड कंप्यूटर कार्यक्रम संरचना का एक प्रकार है, विशेषता द्वारा छोटे और (आदर्श) ढीले-युग्मित सॉफ्टवेयर घटक। शब्द स्पेगेटी कोड के साथ तुलना में है, प्रोग्राम संरचना की तुलना पास्ता से;
यह उनकी तुलना कर रहा है। यह नहीं कह रहा है कि यह एक विरोधी पैटर्न है।
लेकिन मैं सहमत हूं। लेख उलझन में है। समस्या ravioli समानता के साथ नहीं है, लेकिन विकिपीडिया लेख संरचना के साथ ही। यह स्पेगेटी को बुरी आदत के रूप में बुलाता है, फिर कुछ उदाहरण कहते हैं और इसके बाद रावियोली कोड के बारे में कुछ कहते हैं।
संपादित करें: उन्होंने लेख में सुधार किया। एक विरोधी पैटर्न है क्योंकि
जबकि आम तौर पर एक युग्मन और एकता परिप्रेक्ष्य, ज्यादा जुदाई और कोड कॉल के ढेर ब्लोट और रखरखाव प्रयोजनों के लिए और अधिक कठिन कोड के माध्यम से नेविगेशन कर सकते हैं की कैप्सूलीकरण से वांछनीय।
हम्म के रूप में सूचीबद्ध किया गया है, यदि "रैवियोली कोड" एक विरोधी पैटर्न नहीं है, तो कोडबेज के लिए _pejorative_ शब्द क्या है जो टूट गया है इतने सारे व्यक्तिगत वर्ग जो कोई भी समझ नहीं सकता कि सिस्टम क्या करता है? क्योंकि मैं इसके लिए "रैवियोली कोड" का उपयोग कर रहा था। – Trejkaz
@Trejkaz मैंने इस उत्तर के 5 साल बाद लेख पढ़ा है और यह बहुत बेहतर है। "आमतौर पर युग्मन और एकजुट परिप्रेक्ष्य से वांछनीय होने पर, ** अति उत्साही ** कोड के पृथक्करण और समावेशन कॉल स्टैक को फहरा सकता है और रखरखाव उद्देश्यों के लिए कोड के माध्यम से नेविगेशन बना सकता है।" – GmonC
मैं ज़ेड शॉ द्वारा इस पोस्ट की अनुशंसा करता हूं, यह अति उत्साही decoupling के मुद्दे पर एक बहुत अच्छा परिप्रेक्ष्य देता है: http://zedshaw.com/archive/indirection-is-not-abstraction/ .. शायद हम कह सकते हैं कि आपको ' खुद को रैवियोली के साथ बांधने के लिए भरें या आप बाद में बुरा महसूस करेंगे। –
यह जरूरी नहीं है, है ना? विकिपीडिया लेख इसे खराब के रूप में वर्णित नहीं करता है। कई कमजोर-युग्मित सॉफ़्टवेयर घटक, जहां समस्या घटकों के संबंध में इन घटकों का आकार और संख्या समझदार है, मेरे लिए बहुत आदर्श लगता है।
वास्तव में, यदि आप रैवियोली कोड की अन्य परिभाषाओं को देखते हैं, तो आपको इसे आदर्श सॉफ़्टवेयर डिज़ाइन पैटर्न के रूप में वर्णित किया जाएगा - मैं अब भी चेतावनी पसंद करता हूं कि आकार और संख्या उचित होने की आवश्यकता है।
लेख पढ़ना, स्पेगेटी एक विरोधी पैटर्न है; लेकिन Ravioli और Lasagna विरोधी पैटर्न नहीं हैं।
धन्यवाद। मैं सिर्फ स्पेगेटी और रैवियोली के बारे में पढ़ने के साथ ठीक था, लेकिन अब जब आप लगातार तीन सूचीबद्ध हैं, तो मुझे भूख लगी है। मुझे आश्चर्य है कि पेन पेन कोड है ताकि आप देख सकें। – OregonGhost
@OregonGost - "पेनने" पैटर्न "पाइप" कोड हो सकता है: http://www.eaipatterns.com/PipesAndFilters.html – ChrisW
यह स्पेगेटी कोड के पृष्ठ में सूचीबद्ध है लेकिन इसका मतलब यह नहीं है कि यह एक बुरी बात है। यह वहां है क्योंकि यह एक प्रासंगिक शब्द है और अपने पृष्ठ के लिए पर्याप्त महत्वपूर्ण नहीं है।
इसके बारे में बुरा पक्ष के बारे में, Googling http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355 में एक टिप्पणी देता है:
समस्या यह है कि यह कार्य (तरीकों, आदि) सच जुटना बिना पर आधारित होते हैं, और यह अक्सर कोड छोड़ देता है बहुत बड़ी संख्या में कार्यों पर बिखरे हुए कुछ भी सरल को लागू करने के लिए। कोड को बनाए रखने वाले किसी को यह समझना होगा कि सभी बिट्स के बीच सभी कॉल कैसे काम करती हैं, स्पैगेटी कोड की लगभग सभी बुरी चीजों को दोबारा बनाने के बजाए फ़ंक्शन कॉल को छोड़कर। ...
यदि आप उचित हैं तो आपको न्याय करना होगा :)।
यदि आप एक dogmatic नियम लागू करते हैं कि सभी परियोजनाओं में सभी वर्गों को किसी भी कारण के बावजूद कम से कम युग्मित किया जाना चाहिए, तो मैं देख सकता हूं कि बहुत सारी संभावित समस्याएं हैं।
आप अपने पहियों को एक पूरी तरह से ठीक आवेदन करने की कोशिश कर सकते हैं और अधिक से अधिक और अधिक आसानी से इसके बिना किसी भी मूल्य को जोड़ते हुए जोड़ा जा सकता है।
मुझे जोड़ने के लिए, हालांकि, मुझे लगता है, कि हम सब शिथिल युग्मित कक्षाएं, घटकों की ओर लक्ष्य रखना चाहिए कि जल्दी चलो आदि
के रूप में एक मुहावरा है क्योंकि प्रोग्रामर है सुंदर ज्यादा एकमात्र कारण "रैवियोली कोड" बच गया है विनोद की एक सहज भावना। कोशिश करें कि मैं कर सकता हूं - और मेरा विश्वास करो, मैंने कोशिश की है - ऑब्जेक्ट ओरिएंटेड कोड के उदाहरण के साथ आना वाकई मुश्किल है जो कि (ए) पैक किया गया था कि उसी मेटा-अर्थ में नेविगेट करना वाकई मुश्किल था " स्पेगेटी कोड "नेविगेट करना मुश्किल है, और (बी) कोडिंग अभ्यास में लगातार विरोधी पैटर्न को प्रतिबिंबित करता है।
"रैवियोली कोड" का सबसे अच्छा उदाहरण मैं कक्षाओं की भीड़ के साथ आ सकता हूं, प्रत्येक कसकर पैक किया जाता है, लेकिन जहां निष्पादन का मुख्य प्रवाह है, वहां खोदना मुश्किल होता है। तंत्रिका नेटवर्क अनुप्रयोग इसे प्रदर्शित कर सकते हैं, लेकिन यह बिंदु की तरह है। एक और अधिक प्रचलित उदाहरण यूआई कोड होगा जो बहुत अधिक घटना-उन्मुख है, लेकिन फिर से, इसके साथ ओवरबोर्ड जाना मुश्किल है - यदि कुछ भी हो, तो अधिकांश यूआई कोड ईवेंट संचालित नहीं है पर्याप्त।
मैं कहूंगा कि यह स्पष्ट रूप से स्पष्ट है कि रैवियोली कोड और Lasagna कोड दोनों अपमानजनक शब्द हैं - जानबूझकर अपने साथी पास्ता सिमुलेशन 'स्पेगेटी कोड' के साथ रखा गया है - और दोनों शब्द असली दुनिया विरोधी पैटर्न का वर्णन करते हैं। कुछ कोड बनाए रखने के लिए बहुत समय लेने वाला है और असफलता के लिए बहुत प्रवण है क्योंकि यह इतनी अलग उप-प्रक्रियाओं में टूट गया है - यह रैवियोली कोड है। कुछ कोड में अमूर्तता की इतनी सारी परतें होती हैं कि इसमें परिवर्तन को लागू करना बहुत मुश्किल हो जाता है और/या समझ में आता है कि विफलता किस स्तर पर होती है - वह लसगना कोड है। लसगना कोड में बदलाव करने का एकमात्र व्यावहारिक तरीका अक्सर परतों को बाईपास करना और नौकरी करने वाले सीधा कोड लिखना होता है। मुझे कुछ रैवियोली कोड बनाए रखना है, लेकिन आम तौर पर इस तरह के कोड को इसके संकल्प से पीड़ित होता है और व्यापक रूप से उपयोग करने में विफल रहता है, इसलिए इसके कुछ उदाहरण हैं कि हम सभी परिचित होंगे। इसके विपरीत, इस समय lasagna कोड हर जगह है। मुझे लगता है कि मैं खुद को कोई पास्ता कोड नहीं लिखता हूं, लेकिन आप कम से कम स्पेगेटी की एक स्ट्रिंग का पालन कर सकते हैं ...
प्लस वन "लेकिन आप कम से कम स्पेगेटी की एक स्ट्रिंग का पालन कर सकते हैं।" – fhogberg
समस्या यह है कि अलग-अलग लोग अलग-अलग चीज़ों के लिए "रैवियोली कोड" शब्द का उपयोग करते हैं।
उचित रूप से छोटे घटकों की एक उचित संख्या अच्छी है। कोई स्पष्ट समग्र संरचना के साथ छोटे घटकों का एक विशाल ढेर इतना अच्छा नहीं है।
ढीले युग्मित घटक अच्छे हैं। जो घटक कमजोर युग्मित दिखने के लिए अपनी परस्पर निर्भरता को छिपाते हैं वे इतने अच्छे नहीं होते हैं।
विभिन्न घटकों के बीच संबंध देखने में सक्षम होने के नाते वास्तव में एक अच्छी बात है।
अधिकांश कोड अड्डों में विपरीत समस्या होती है, इसलिए अधिक मॉड्यूलरिटी की ओर बढ़ना आमतौर पर एक अच्छी बात है। मुझे उम्मीद है कि ज्यादातर लोगों ने बुरे अर्थ में कभी भी "रैवियोली कोड" नहीं देखा है। प्रैक्टिस में, यह कटा हुआ रैवियोली की तरह दिखता है (जहां मॉड्यूल को "मॉड्यूल" में विभाजित किया जाना चाहिए - इनमें से कोई भी अपने आप को समझ में नहीं आता है, लेकिन केवल अपने संबंधित हिस्सों के साथ संयोजन में), या रैवियोली की तरह पर्याप्त पानी के बिना पकाया जाता है (इसलिए आप एक साथ फंस गए "मॉड्यूल" के विशाल ब्लॉब के साथ समाप्त होते हैं)।
TODO: अतिसंवेदनशीलता प्रदर्शित करने के लिए ~ 100 मॉड्यूल के रूप में "हैलो वर्ल्ड" प्रोग्राम लिखें।
TODO2: उपोष्णकटिबंधीय संरचनात्मक विशेषताओं का प्रदर्शन करने के लिए रैवियोली के ट्रकलोड से बाहर एक पुल बनाने का प्रयास।
जिन्होंने कहा कि यह एक बुरा अभ्यास था? लूज-युग्मन एक अच्छी बात है। – jldupont
मेरा कोड भंगुर नहीं है, यह "अल डेंटे" है :) – RedFilter
@jldupont, मुझे नहीं लगता कि यह एक बुरी बात है। हालांकि, 'ईश्वर ऑब्जेक्ट' के बारे में विकिपीडिया लेख में इसे एक विपरीत * एंटी-पैटर्न * –