मैं पैटर्न और विरोधी पैटर्न का अध्ययन कर रहा हूँ। मेरे पास पैटर्न के बारे में एक स्पष्ट विचार है, लेकिन मुझे एंटी-पैटर्न नहीं मिलते हैं। वेब और विकिपीडिया की परिभाषाएं मुझे बहुत भ्रमित करती हैं।विरोधी पैटर्न क्या है?
क्या कोई मुझे सरल शब्दों में समझा सकता है कि विरोधी पैटर्न क्या है? उद्देश्य क्या है? वो क्या करते हैं? क्या यह एक बुरी चीज है या अच्छी बात है?
Anti-patterns सॉफ्टवेयर विकास में कुछ पैटर्न हैं जिन्हें खराब प्रोग्रामिंग प्रथा माना जाता है।
design patterns के विपरीत जो सामान्य समस्याओं के सामान्य दृष्टिकोण हैं जिन्हें औपचारिक रूप दिया गया है और आमतौर पर एक अच्छा विकास अभ्यास माना जाता है, विरोधी पैटर्न विपरीत हैं और अवांछित हैं।
उदाहरण के लिए, ऑब्जेक्ट उन्मुख प्रोग्रामिंग में, विचार सॉफ़्टवेयर को ऑब्जेक्ट नामक छोटे टुकड़ों में अलग करना है। ऑब्जेक्ट उन्मुख प्रोग्रामिंग में एक विरोधी पैटर्न God object है जो बहुत सारे फ़ंक्शन करता है जो अलग-अलग ऑब्जेक्ट्स में बेहतर ढंग से अलग हो जाते हैं।
उदाहरण के लिए:
class GodObject {
function PerformInitialization() {}
function ReadFromFile() {}
function WriteToFile() {}
function DisplayToScreen() {}
function PerformCalculation() {}
function ValidateInput() {}
// and so on... //
}
उपरोक्त उदाहरण एक उद्देश्य यह है कि सब कुछ करता है। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, यह विभिन्न वस्तुओं के लिए अच्छी तरह से परिभाषित जिम्मेदारियों कोड कम युग्मित और अंततः अधिक पोषणीय रखने के लिए के लिए बेहतर होगा:
class FileInputOutput {
function ReadFromFile() {}
function WriteToFile() {}
}
class UserInputOutput {
function DisplayToScreen() {}
function ValidateInput() {}
}
class Logic {
function PerformInitialization() {}
function PerformCalculation() {}
}
लब्बोलुआब यह है वहाँ अच्छा सामान्यतः के साथ सॉफ्टवेयर विकसित करने के तरीके हैं है प्रयुक्त पैटर्न (design patterns), लेकिन सॉफ़्टवेयर विकसित और कार्यान्वित करने के तरीके भी हैं जो समस्याएं पैदा कर सकते हैं। पैटर्न जो खराब सॉफ्टवेयर विकास प्रथाओं के रूप में माना जाता है विरोधी पैटर्न हैं।
भगवान के बगल में एंटी-पैटर्न के किसी भी अन्य उदाहरण? – Tomasz
@ टोमाज़ प्रोग्रामिंग पास्ता सेवा एक ऐसा उदाहरण है। यह कई छोटी वस्तुओं के बीच खराब encapsulation के रूप में सबसे अच्छा सामान्यीकृत है। इसे भगवान ऑब्जेक्ट के विपरीत https://en.wikipedia.org/wiki/Spaghetti_code – AWrightIV
@ टोमाज़ कुछ भी बुरा है, लेकिन कुछ लोगों द्वारा किया जाता है, यह एक एंटीपाटर है। उदा।, कोशिश करें: <कुछ करें>; सिवाय इसके कि: पास 'पायथन में कार्डिनल पाप एंटीपाटरन हो सकता है। इसे देखें: https://realpython.com/blog/python/the-most-diabolical-python-antipattern/ – neuronet
एक पैटर्न कुछ वर्ग की समस्या को हल करने का विचार है। एक विरोधी पैटर्न यह सोचने का एक विचार है कि इसे कैसे हल नहीं किया जाए क्योंकि उस विचार को लागू करने से खराब डिजाइन होगा।
एक उदाहरण: कोड पुन: उपयोग के लिए एक फ़ंक्शन का उपयोग करने के लिए "पैटर्न" होगा, एक "एंटी-पैटर्न" इसके लिए कॉपी-पेस्ट का उपयोग करना होगा। दोनों एक ही समस्या को हल करते हैं, लेकिन एक फ़ंक्शन का उपयोग आमतौर पर कॉपी-पेस्ट की तुलना में अधिक पठनीय और रखरखाव योग्य कोड की ओर जाता है।
गड़बड़ करने का एक आम तरीका। भगवान/रसोईघर वर्ग की तरह (सबकुछ करता है), उदाहरण के लिए।
एक विरोधी पैटर्न एक समस्या को हल करने का एक तरीका है। लेकिन इसके लिए और भी कुछ है: यह एक ऐसा तरीका भी है जिसे समस्या को हल करने के प्रयासों में अक्सर देखा जा सकता है।
बस, एक डिज़ाइन पैटर्न साथ चाहते एक विरोधी पैटर्न भी एक टेम्पलेट और एक निश्चित समस्या के हल के लिए एक repeatable तरीका है, लेकिन एक गैर इष्टतम और अप्रभावी तरीके से।
यदि आप वास्तव में एंटीपाटरर्न का अध्ययन करना चाहते हैं, तो पुस्तक एंटीपाटरर्न (आईएसबीएन -13: 978-0471197133) प्राप्त करें।
इसमें, वे परिभाषित करते हैं "एक एंटीपाटर एक साहित्यिक रूप है जो एक समस्या के सामान्य रूप से होने वाले समाधान का वर्णन करता है जो निश्चित रूप से नकारात्मक परिणाम उत्पन्न करता है।"
इसलिए, यह एक बुरा प्रोग्रामिंग अभ्यास नहीं बल्कि एक आम एक — सीमित एक आवेदन करने के लिए, एक कंपनी या एक प्रोग्रामर, यह पूरा नहीं करता है, तो" AntiPattern परिभाषा के पैटर्न "भाग।
दिलचस्प बात यह है एक किसी समस्या को हल करने का दिया गया तरीका एक पैटर्न और विरोधी पैटर्न दोनों हो सकता है। सिंगलटन इसका मुख्य उदाहरण है। यह साहित्य के दोनों सेटों में दिखाई देगा।
विरोधी पैटर्न सामान्य तरीके हैं जो लोग गलत प्रोग्राम करते हैं रास्ता, या कम से कम इतना अच्छा तरीका नहीं है।
जब भी मैं एंटी- पैटर्न, मैं एक और शब्द याद करते हैं जैसे। डिजाइन गंध ।
"डिजाइन गंध डिजाइन में कुछ संरचनाओं कि मौलिक डिजाइन सिद्धांतों के उल्लंघन से संकेत मिलता है और नकारात्मक डिजाइन गुणवत्ता को प्रभावित कर रहे हैं" (से "सॉफ्टवेयर डिजाइन के लिए पुनर्रचना खुशबू: तकनीकी ऋण प्रबंध")
कई डिजाइन गंध रहे हैं
अमूर्त बदबू आ रही है
अमूर्त लापता:: डिजाइन सिद्धांतों का उल्लंघन करने के आधार पर वर्गीकृत यह गंध पैदा होती है जब डेटा या इनकोडिंग str के गुच्छों कक्षा या इंटरफ़ेस बनाने के बजाय ings का उपयोग किया जाता है।
इंपीरेटिव एब्स्ट्रक्शन: यह गंध उत्पन्न होती है जब एक ऑपरेशन कक्षा में बदल जाता है।
अपूर्ण अमूर्तता: यह गंध तब उत्पन्न होती है जब एक अमूर्त पूरक या पारस्परिक तरीकों का पूरी तरह से समर्थन नहीं करता है।
मल्टीफासिटेड एब्स्ट्रक्शन: यह गंध उत्पन्न होती है जब एक अमूर्तता को एक से अधिक ज़िम्मेदारी सौंपी जाती है।
अनावश्यक सार तत्व: यह गंध तब होती है जब एक अमूर्तता की आवश्यकता नहीं होती है (और इस तरह से बचा जा सकता है) एक सॉफ्टवेयर डिजाइन में पेश किया जाता है।
अप्रयुक्त अबास्ट्रक्शन: यह गंध तब उत्पन्न होती है जब एक अमूर्तता का उपयोग नहीं किया जाता है (या तो सीधे उपयोग नहीं किया जाता है या पहुंच योग्य नहीं होता है)।
डुप्लिकेट एब्स्ट्रक्शन: यह गंध उत्पन्न होती है जब दो या दो से अधिक अवशेषों के समान नाम या समान कार्यान्वयन या दोनों होते हैं।
Encapsulation बदबू आ रही है
कमी Encapsulation: यह गंध तब होता है जब एक अमूर्त के एक या अधिक सदस्यों की घोषणा की पहुंच अधिक अनुमोदक वास्तव में आवश्यकता से है।
लीकी Encapsulation: यह गंध तब उत्पन्न होती है जब एक अमूर्तता अपने सार्वजनिक इंटरफ़ेस के माध्यम से कार्यान्वयन का विवरण "खुलासा" या "लीक" करता है।
गुम Encapsulation: यह गंध तब होती है जब क्रियान्वयन विविधता एक अमूर्त या पदानुक्रम के भीतर encapsulated नहीं हैं।
unexploited Encapsulation: जब ग्राहक कोड स्पष्ट प्रकार चेकों का उपयोग करता है के बजाय पहले से ही एक पदानुक्रम के भीतर समझाया प्रकार में भिन्नता का शोषण करने का (अगर-बाकी या बयान है कि वस्तु के प्रकार के लिए जाँच स्विच जंजीर का प्रयोग करके) यह गंध उत्पन्न होती है।
Modularization बदबू आ रही है
टूटी Modularization: यह गंध पैदा होती है जब डेटा और/या तरीकों कि आदर्श रूप में एक भी अमूर्त में अनुवाद किया जाना चाहिए था अलग कर दिया और कई कपोल-कल्पना भर में फैले हुए हैं।
अपर्याप्त Modularization: यह गंध पैदा होती है एक अमूर्त मौजूद न होने पर कि पूरी तरह से विघटित नहीं किया गया है, और एक और अपघटन इसके आकार, कार्यान्वयन जटिलता, या दोनों को कम कर सकता।
Cyclically पर निर्भर Modularization: यह गंध पैदा होती है जब दो या अधिक कपोल-कल्पना एक दूसरे को प्रत्यक्ष या परोक्ष रूप (कपोल-कल्पना के बीच एक तंग युग्मन बनाने) पर निर्भर हैं।
हब की तरह Modularization: यह गंध पैदा होती है एक अमूर्त अन्य पृथक्करण की एक बड़ी संख्या के साथ निर्भरता (दोनों आवक और जावक) को रखता हो।
पदानुक्रम
बदबू आ रही है गुम पदानुक्रम: जब एक कोड खंड सशर्त तर्क का उपयोग करता यह गंध पैदा होती है स्पष्ट रूप से व्यवहार में विभेद है जहां एक पदानुक्रम बनाया जा सकता था प्रबंधन करने के लिए (आमतौर पर के साथ "टैग प्रकार" संयोजन के रूप में) और उन बदलावों को समाहित करने के लिए प्रयोग किया जाता है।
अनावश्यक पदानुक्रम: यह गंध तब उत्पन्न होती है जब संपूर्ण विरासत पदानुक्रम अनावश्यक है, यह दर्शाता है कि विशेष डिजाइन संदर्भ के लिए विरासत को अनिवार्य रूप से लागू किया गया है।
असुरक्षित पदानुक्रम: यह गंध तब उत्पन्न होती है जब पदानुक्रम में प्रकारों के बीच अनावश्यक डुप्लिकेशंस होता है।
वाइड पदानुक्रम: यह गंध पैदा होती है एक वंशानुगत पदानुक्रम है जब "भी" विस्तृत यह दर्शाता है कि मध्यवर्ती प्रकार गायब हो सकता है।
सट्टा पदानुक्रम: यह गंध उत्पन्न होती है जब पदानुक्रम में एक या एक से अधिक प्रकार अनुमानित रूप से प्रदान किए जाते हैं (यानी वास्तविक आवश्यकताओं के बजाय कल्पना की जरूरतों के आधार पर)।
दीप पदानुक्रम: यह गंध उत्पन्न होती है जब एक विरासत पदानुक्रम "अत्यधिक" गहरा होता है।
विद्रोही पदानुक्रम: यह गंध उत्पन्न होती है जब उपप्रकार अपने सुपरटेप द्वारा प्रदान की गई विधियों को अस्वीकार करता है।
टूटी पदानुक्रम: यह गंध पैदा होती है जब एक महाप्रकार और उसके उप-प्रकार धारणात्मक एक "है- ए 'रिश्ते टूटे प्रतिस्थापन में जिसके परिणामस्वरूप का हिस्सा नहीं है।
बहुपथ पदानुक्रम: यह गंध पैदा होती है जब एक उप-प्रकार दोनों एक महाप्रकार पदानुक्रम में अनावश्यक विरासत पथ के लिए अग्रणी से सीधे और साथ ही परोक्ष रूप से इनहेरिट करती है।
चक्रीय पदानुक्रम: यह गंध उत्पन्न होती है जब पदानुक्रम में एक सुपरटेप इसके किसी उपप्रकार पर निर्भर करता है।
उपरोक्त परिभाषा और वर्गीकरण "Refactoring for software design smells: Managing technical debt में वर्णित है "। कुछ और प्रासंगिक संसाधनों here पाया जा सकता है।
एक विरोधी पैटर्न एक डिज़ाइन पैटर्न के पूरक है। एक रोधी पैटर्न एक टेम्पलेट समाधान है जिसे आपको किसी निश्चित स्थिति में उपयोग नहीं करना चाहिए।
आज, सॉफ्टवेयर इंजीनियरिंग शोधकर्ता और चिकित्सक अक्सर "एंटी-पैटर्न" और "गंध" शब्दों का एक-दूसरे से उपयोग करते हैं। हालांकि , वे अवधारणात्मक रूप से वही नहीं हैं। विरोधी पैटर्न के विकिपीडिया प्रविष्टि में कहा गया है कि एक विरोधी पैटर्न कम अभ्यास से कम या कम से कम दो कारकों से एक बुरा विचार है। एक विरोधी पैटर्न ", एक आमतौर पर इस्तेमाल किया प्रक्रिया, संरचना या कार्रवाई कि के बावजूद शुरू में एक समस्या के लिए एक उपयुक्त और प्रभावी प्रतिक्रिया प्रतीत होने के पैटर्न आम तौर पर लाभकारी परिणाम की तुलना में अधिक बुरा परिणाम है।"
है
यह स्पष्ट रूप से इंगित करता है कि एक विरोधी पैटर्न प्रस्तुत समस्या को विश्वास है कि यह एक अच्छा समाधान है में चुना जाता है (एक पैटर्न के रूप में);। हालांकि, यह लाभ की तुलना में अधिक देनदारियों लाता दूसरी ओर, एक गंध बस एक बुरा अभ्यास है जो नरमवा की गुणवत्ता को नकारात्मक रूप से प्रभावित करता है फिर प्रणाली उदाहरण के लिए, सिंगलटन एक विरोधी पैटर्न है और भगवान वर्ग (या अपर्याप्त मॉड्यूलरेशन) एक डिजाइन गंध है।
https://sourcemaking.com/antipatterns – jaco0646
http://martinfowler.com/bliki/AntiPattern.html – jaco0646