विरोधी प्रतिरूप: Difference between revisions
m (added Category:Vigyan Ready using HotCat) |
m (7 revisions imported from alpha:विरोधी_प्रतिरूप) |
||
(One intermediate revision by one other user not shown) | |||
Line 17: | Line 17: | ||
== सॉफ्टवेयर अभियांत्रिकी विरोधी प्रतिरूप == | == सॉफ्टवेयर अभियांत्रिकी विरोधी प्रतिरूप == | ||
सॉफ्टवेयर अभियांत्रिकी में, विरोधी प्रतिरूप में मिट्टी की एक बड़ी गेंद डिज़ाइन सम्मलित होती है, [[भगवान आपत्ति|गॉड वर्ग]] जहाँ एक एकल वर्ग प्रोग्रामिंग कई वर्गों में वितरित नियंत्रण के अतिरिक्त [[कंप्यूटर प्रोग्राम]] में सभी नियंत्रण संभालता है, और पोल्टरजिस्ट क्षणिक नियंत्रक वर्ग जो केवल वर्गों पर अन्य विधियों को लागू करने के लिए उपस्थित होता है।{{sfn|Demeyer|2008|p=102}} | सॉफ्टवेयर अभियांत्रिकी में, विरोधी प्रतिरूप में मिट्टी की एक बड़ी गेंद डिज़ाइन सम्मलित होती है, [[भगवान आपत्ति|गॉड वर्ग]] जहाँ एक एकल वर्ग प्रोग्रामिंग कई वर्गों में वितरित नियंत्रण के अतिरिक्त [[कंप्यूटर प्रोग्राम]] में सभी नियंत्रण संभालता है, और पोल्टरजिस्ट क्षणिक नियंत्रक वर्ग जो केवल वर्गों पर अन्य विधियों को लागू करने के लिए उपस्थित होता है। {{sfn|Demeyer|2008|p=102}} | ||
===मिट्टी की एक बड़ी गेंद=== | ===मिट्टी की एक बड़ी गेंद=== |
Latest revision as of 16:56, 28 October 2023
सॉफ्टवेयर अभियांत्रिकी, परियोजना प्रबंधन और व्यावसायिक प्रक्रियाओं में विरोधी प्रतिरूप एक आवर्ती समस्या के लिए एक आम प्रतिक्रिया होती है जो सामान्यतः अप्रभावी होती है।[1][2] यह शब्द, कंप्यूटर प्रोग्रामर एंड्रयू कोएनिग द्वारा 1995 में प्रस्तावित किया गया था, जो डिज़ाइन प्रतिरूप नामक पुस्तक से प्रेरित था (जो सॉफ्टवेयर विकास में कई डिज़ाइन प्रतिरूप पर प्रकाश डालता है, जिसे इसके लेखक अत्यधिक विश्वसनीय और प्रभावी मानते है)।[3] 1996 में विश्व पश्चिम सम्मेलन में माइकल एक्रोयड द्वारा प्रस्तुत एक पेपर में विरोधी प्रतिरूप का दस्तावेजीकरण किया गया था।[3]
चूँकि, 1998 की पुस्तक विरोधी प्रतिरूप ने इस विचार को लोकप्रिय बनाया था और सॉफ्टवेयर वास्तुकला और योजना प्रबंधन को सम्मलित करने के लिए सॉफ्टवेयर डिजाइन किया था।[3] अन्य लेखकों ने पर्यावरण, संगठनात्मक, सांस्कृतिक विरोधी प्रतिरूप को सम्मलित करने के लिए इसे और आगे बढ़ाया था।[4]
परिभाषा
डिज़ाइन प्रतिरूप के लेखकों के अनुसार, विरोधी प्रतिरूप में दो प्रमुख तत्व होते है जो इसे एक बुरे अभ्यास या बुरे विचार से अलग करते है:
- विरोधी प्रतिरूप सामान्यतः उपयोग की जाने वाली प्रक्रिया, संरचना का प्रतिरूप होता है, जो प्रारंभ में किसी समस्या के लिए उचित और प्रभावी प्रतिक्रिया प्रतीत होने के अतिरिक्त, अच्छे परिणामों की तुलना में अधिक बुरे परिणाम देता है।
- उस समस्या का एक और समाधान उपस्थित होता है जिसे विरोधी प्रतिरूप संबोधित करने का प्रयास करता है। यह समाधान प्रलेखित होता है, दोहराने योग्य होता है, और जहां विरोधी प्रतिरूप नहीं होता है वहां भी प्रभावी सिद्ध होता है।
सामान्यतः जो उपयोग किया जाता है उसके लिए एक मार्गदर्शिका प्रतिरूप के समान "तीन में से एक नियम" होता है: एक विरोधी प्रतिरूप होने के लिए इसे कम से कम तीन बार घटित होना होता है।[5]
उपयोग
किसी समस्या स्थान का विश्लेषण करने और विशेषज्ञ ज्ञान प्राप्त करने के लिए विरोधी प्रतिरूप का दस्तावेजीकरण एक प्रभावी विधि हो सकती है।[6]
जबकि कुछ विरोधी प्रतिरूप विवरण केवल प्रतिरूप के प्रतिकूल परिणामों का दस्तावेजीकरण करते है, अच्छा विरोधी प्रतिरूप दस्तावेज़ीकरण विरोधी प्रतिरूप को सुधारने का एक विकल्प या साधन भी प्रदान करता है।[7]
सॉफ्टवेयर अभियांत्रिकी विरोधी प्रतिरूप
सॉफ्टवेयर अभियांत्रिकी में, विरोधी प्रतिरूप में मिट्टी की एक बड़ी गेंद डिज़ाइन सम्मलित होती है, गॉड वर्ग जहाँ एक एकल वर्ग प्रोग्रामिंग कई वर्गों में वितरित नियंत्रण के अतिरिक्त कंप्यूटर प्रोग्राम में सभी नियंत्रण संभालता है, और पोल्टरजिस्ट क्षणिक नियंत्रक वर्ग जो केवल वर्गों पर अन्य विधियों को लागू करने के लिए उपस्थित होता है। [7]
मिट्टी की एक बड़ी गेंद
यह एक सॉफ्टवेयर प्रणाली को इंगित करता है जिसमें बोधगम्य वास्तुकला का अभाव होता है। चूँकि सॉफ्टवेयर अभियांत्रिकी के दृष्टिकोण से अवांछनीय होती है, व्यावसायिक दबाव, विकासक आवर्त और सॉफ्टवेयर एन्ट्रापी के कारण ऐसी प्रणालियाँ व्यवहार में आम होती है।
यह शब्द ब्रायन फूटे और जोसेफ योडर के 1997 के पेपर में लोकप्रिय हुआ था, जो इस शब्द को परिभाषित करता है:
मिट्टी की एक बड़ी गेंद एक बेतरतीब तरह से संरचित, फैला हुआ, डक्ट-टेप-और-बेलिंग-वायर, स्पेगेटी-कोड है। ये प्रणाली अनियमित विकास और बार-बार, शीघ्र अचूक संकेत दिखाते है। सूचना को प्रणाली के दूरस्थ तत्वों के बीच अनियमित रूप से साझा किया जाता है, अधिकांशतः उस बिंदु तक जहां लगभग सभी महत्वपूर्ण जानकारी वैश्विक हो जाती है।
प्रणाली की समग्र संरचना को कभी भी अच्छी तरह से परिभाषित नहीं किया जा सकता है।
वास्तुकला की थोड़ी-सी समझ रखने वाले प्रोग्रामर इन समस्याओं से दूर रहते है। केवल वे लोग जो वास्तुकला के बारे में चिंतित नहीं है, और, संभवतः, इन असफल बांधों में छेदों को भरने के दिन-प्रतिदिन के काम करने में सहज होते है, ऐसी प्रणालियों पर काम करने के लिए संतुष्ट होते है।
— ब्रायन फूटे और जोसेफ योडर, मिट्टी की बड़ी गेंद कार्यक्रमों के प्रतिरूप भाषाओं पर चौथा सम्मेलन (पीएलओपी '97/यूरोपीएलओपी '97) मोंटीसेलो, इलिनोइस, सितंबर 1997
फूटे और योडर ने इस प्रकार की वास्तुकला के लिए 'मिट्टी की बड़ी गेंद' शब्द के प्रवर्तक के रूप में ब्रायन मैरिक को श्रेय दिया है।[8]
परियोजना प्रबंधन विरोधी प्रतिरूप
विरोधी प्रतिरूप पुस्तक में परियोजना प्रबंधन में ब्लोहार्ड जाम्बोरे, विश्लेषण पक्षाघात, व्यूग्राफ अभियांत्रिकी, सफलता का भय (परियोजना पूरी होने के निकट अतार्किक भय), द कॉर्नकोब (लोगों के साथ कठिनाइयाँ), बौद्धिक हिंसा (शब्दजाल या रहस्यमय प्रौद्योगिकी के उपयोग के माध्यम से भय), अतार्किक प्रबंधन (बुरी प्रबंधन आदते), अग्नि अभ्यास (छोटे संकटों के कारण लंबी अवधि की एकरसता), द फ्यूड (प्रबंधकों के बीच संघर्ष), और ई -मेल समस्या (गलत सलाह वाले ई-मेल संदेशों से उत्पन्न स्थितियाँ) सम्मलित है। [4]
यह भी देखें
- कोड गंध - ख़राब प्रोग्रामिंग का लक्षण
- डिज़ाइन गंध
- गहरा प्रतिरूप
- सॉफ्टवेयर विकास दर्शन की सूची - सॉफ्टवेयर विकास के लिए दृष्टिकोण, शैलियाँ, सिद्धांत और दर्शन
- स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची
- सॉफ्टवेयर सड़ गया
- सॉफ्टवेयर पीटर सिद्धांत
- क्षमता अपरिपक्वता मॉडल
- आईएसओ/आईईसी 29110: बहुत छोटी संस्थाओं (वीएसई) के लिए सॉफ्टवेयर जीवन चक्र प्रोफाइल और दिशानिर्देश
- इनोवेटर की दुविधा
संदर्भ
क्या समर्थन करता है
- ↑ Budgen 2003, p. 225.
- ↑ Ambler 1998, p. 4.
- ↑ 3.0 3.1 3.2 Neill, Laplante & DeFranco 2011, p. 4.
- ↑ 4.0 4.1 Neill, Laplante & DeFranco 2011, p. 5.
- ↑ Neill, Laplante & DeFranco 2011, p. 6.
- ↑ Jimenez 2006.
- ↑ 7.0 7.1 Demeyer 2008, p. 102.
- ↑ Foote, Brian; Yoder, Joseph (26 June 1999). "मिट्टी की बड़ी गेंद". laputan.org. Retrieved 14 April 2019.
स्रोत
- Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). एंटीपैटर्न: सॉफ्टवेयर संगठनों और लोगों का प्रबंधन. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162.
- Budgen, D. (2003). सॉफ्टवेर डिज़ाइन. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4.
जैसा कि लॉन्ग (2001) में बताया गया है, डिज़ाइन विरोधी पैटर्न 'स्पष्ट, लेकिन गलत, आवर्ती समस्याओं के समाधान' हैं।
- Ambler, Scott W. (1998). प्रक्रिया पैटर्न: ऑब्जेक्ट प्रौद्योगिकी का उपयोग करके बड़े पैमाने पर सिस्टम का निर्माण. Cambridge, UK: Cambridge University Press. p. 4. ISBN 0-521-64568-9.
...आवर्ती समस्याओं को हल करने के लिए सामान्य दृष्टिकोण जो अप्रभावी साबित होते हैं। इन दृष्टिकोणों को एंटीपैटर्न कहा जाता है।
- Jimenez, Edward (2006-04-24). "एंटीपैटर्न". एंटीपैटर्न. Retrieved 24 April 2006.
- Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). सॉफ्टवेयर विकास. Springer Science + Business Media. ISBN 9783540764403.
अग्रिम पठन
- Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming. 8 (1): 46–48.
- Later re-printed in: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN 0-521-64818-1.
An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one.
- Later re-printed in: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN 0-521-64818-1.
- Laplante, Phillip A.; Neill, Colin J. (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9.
- Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). Anti-Patterns in Project Management. John Wiley & Sons. ISBN 0-471-36366-9.
- Stamelos, Ioannis (January 2010). "Software project management anti-patterns". Journal of Systems and Software. 83 (1): 52–59. doi:10.1016/j.jss.2009.09.016.