Call super
कॉल सुपर कुछ ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं का एक कोड गंध या एंटी-पैटर्न है। कॉल सुपर एक डिज़ाइन पैटर्न है जिसमें एक विशेष वर्ग निर्धारित करता है कि एक व्युत्पन्न उपवर्ग में, उपयोगकर्ता को एक विधि को ओवरराइड करने और एक विशेष बिंदु पर ओवरराइड किए गए फ़ंक्शन को वापस कॉल करने की आवश्यकता होती है। ओवरराइड विधि जानबूझकर अधूरी हो सकती है, और निर्धारित तरीके से अपनी कार्यक्षमता बढ़ाने के लिए ओवरराइड विधि पर निर्भर हो सकती है। हालाँकि, यह तथ्य कि भाषा स्वयं इस आह्वान पर निर्धारित सभी शर्तों को लागू करने में सक्षम नहीं हो सकती है, यही इसे एक विरोधी पैटर्न बनाता है। विवरण ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, उपयोगकर्ता उपवर्गों में एक सुपरक्लास के गुणों और व्यवहार को विरासत में प्राप्त कर सकते हैं। एक उपवर्ग अपने सुपरक्लास के तरीकों को ओवरराइड कर सकता है, सुपरक्लास के कार्यान्वयन के लिए विधि के अपने कार्यान्वयन को प्रतिस्थापित कर सकता है। कभी-कभी ओवरराइडिंग विधि सुपरक्लास में संबंधित कार्यक्षमता को पूरी तरह से बदल देगी, जबकि अन्य मामलों में सुपरक्लास की विधि को अभी भी ओवरराइडिंग विधि से बुलाया जाना चाहिए। इसलिए, अधिकांश प्रोग्रामिंग भाषाओं के लिए आवश्यक है कि एक ओवरराइड विधि को निष्पादित करने के लिए सुपरक्लास पर स्पष्ट रूप से ओवरराइड विधि को कॉल करना चाहिए। कॉल सुपर एंटी-पैटर्न एक विशेष वर्ग से एक उपवर्ग प्राप्त करने के लिए एक इंटरफेस या ढांचे के उपयोगकर्ताओं पर निर्भर करता है, एक निश्चित विधि को ओवरराइड करता है और ओवरराइड विधि से मूल विधि को कॉल करने के लिए ओवरराइड विधि की आवश्यकता होती हैः यह अक्सर आवश्यक होता है, क्योंकि सुपरक्लास को सही ढंग से काम करने के लिए वर्ग या ढांचे के लिए कुछ सेटअप कार्य करने होते हैं, या क्योंकि सुपरक्लास का मुख्य कार्य (जो इस विधि द्वारा किया जाता है) केवल उपवर्ग द्वारा संवर्धित होता है। एंटी-पैटर्न माता-पिता को बुलाने का है। वास्तविक कोड में कई उदाहरण हैं जहां उपवर्ग में विधि अभी भी सुपरक्लास की कार्यक्षमता की आवश्यकता हो सकती है, आमतौर पर जहां यह केवल मूल कार्यक्षमता को बढ़ा रही है। यदि इसे अभी भी मूल वर्ग को कॉल करना है, भले ही यह पूरी तरह से कार्यक्षमता को बदल रहा हो, तो एंटी-पैटर्न मौजूद है। इन मुद्दों को हल करने के लिए एक बेहतर तरीका टेम्पलेट विधि पैटर्न का उपयोग करना है, जहां सुपरक्लास में एक विशुद्ध रूप से अमूर्त विधि शामिल है जिसे उपवर्गों द्वारा लागू किया जाना चाहिए और मूल विधि को उस विधि को कॉल करना चाहिएः भाषा भिन्नता कार्यक्रमों में इस विरोधी पैटर्न की उपस्थिति आमतौर पर इसलिए होती है क्योंकि कुछ प्रोग्रामिंग भाषाएं अनुबंध रूप से यह सुनिश्चित करने के लिए एक सुविधा प्रदान करती हैं कि एक सुपर विधि को व्युत्पन्न वर्ग से बुलाया जाता है। एक भाषा जिसमें यह विशेषता है, काफी कट्टरपंथी तरीके से, बीटा है। यह सुविधा उदाहरण के लिए जावा और सी + + में सीमित तरीके से पाई जाती है, जहां एक चाइल्ड क्लास कंस्ट्रक्टर हमेशा पैरेंट क्लास कंस्ट्रक्टर को कॉल करता है। कॉमन लिस्प (विशेष रूप से कॉमन लिस्प ऑब्जेक्ट सिस्टम) जैसी विधियों से पहले और बाद में समर्थन करने वाली भाषाएं इस विरोधी पैटर्न से बचने का एक अलग तरीका प्रदान करती हैं। उपवर्ग का प्रोग्रामर, सुपरक्लास की विधि को ओवरराइड करने के बजाय, एक अतिरिक्त विधि की आपूर्ति कर सकता है जिसे सुपरक्लास की विधि से पहले या बाद में निष्पादित किया जाएगा। इसके अलावा, सुपरक्लास का प्रोग्रामर उन तरीकों को पहले, बाद में और आसपास निर्दिष्ट कर सकता है जिन्हें उपवर्ग के कार्यों के अलावा निष्पादित करने की गारंटी है। उदाहरण मान लीजिए कि वीडियो रेंटल स्टोर की सूची के बारे में एक रिपोर्ट तैयार करने के लिए एक वर्ग है। प्रत्येक विशेष स्टोर में वर्तमान में उपलब्ध वीडियो को सारणीबद्ध करने का एक अलग तरीका है, लेकिन अंतिम रिपोर्ट बनाने के लिए एल्गोरिदम सभी स्टोरों के लिए समान है। कॉल सुपर एंटी-पैटर्न का उपयोग करने वाला एक ढांचा निम्नलिखित अमूर्त वर्ग प्रदान कर सकता है (सी #में): अमूर्त वर्ग रिपोर्ट जनरेटर {सार्वजनिक आभासी रिपोर्ट क्रिएट रिपोर्ट () {// सामान्य रिपोर्ट ऑब्जेक्ट जनरेट करें//. नई रिपोर्ट वापस करें (.);}} वर्ग के एक उपयोगकर्ता से इस तरह के एक उपवर्ग को लागू करने की उम्मीद की जाती हैः वर्ग कंक्रीट रिपोर्ट जनरेटरः रिपोर्ट जनरेटर {सार्वजनिक ओवरराइड रिपोर्ट क्रिएट रिपोर्ट () {// स्टोर-विशिष्ट तरीके से डेटा को सारणीबद्ध करें//.// इस वर्ग के डिजाइन के लिए मूल क्रिएट रिपोर्ट () फ़ंक्शन को ओवरराइड फ़ंक्शन के// अंत में कॉल करने की आवश्यकता होती है। लेकिन ध्यान दें कि इस पंक्ति को आसानी से छोड़ दिया जा सकता है, या कॉल के बाद// लौटी गई रिपोर्ट को और संशोधित किया जा सकता है, जो वर्ग डिजाइन// और संभवतः कंपनी-व्यापी रिपोर्ट प्रारूप का भी उल्लंघन करता है। रिटर्न base.CreateReport ();} एक बेहतर इंटरफेस इस तरह दिखता हैः अमूर्त वर्ग रिपोर्टजनरेटर {सार्वजनिक रिपोर्ट क्रिएट रिपोर्ट () {टैबुलेट ();// सामान्य रिपोर्ट ऑब्जेक्ट उत्पन्न करें//. नई रिपोर्ट वापस करें (.);} संरक्षित अमूर्त शून्य टैबुलेट ();} एक कार्यान्वयन इस वर्ग को इस तरह ओवरराइड करेगाः वर्ग कंक्रीट रिपोर्टजनरेटरः रिपोर्टजनरेटर {संरक्षित ओवरराइड शून्य टैबुलेट () {// स्टोर-विशिष्ट तरीके में टैबुलेट डेटा//।