क्यों निर्माता को रिवर्स ऑर्डर में बुलाया जाता है?

Question

विरासत में बेस क्लास कन्स्ट्रक्टर को पहले कॉल क्यों मिलता है क्यों व्युत्पन्न नहीं ??

Answer 1

यह सुनिश्चित करने के लिए कि मूल श्रेणी के सार्वजनिक या संरक्षित सदस्यों को व्युत्पन्न कक्षा में उपयोग करने से पहले ठीक से प्रारंभ किया जाता है।
सटीक होने के लिए, व्युत्पन्न-श्रेणी का कन्स्ट्रक्टर पहले बेस-क्लास कन्स्ट्रक्टर को एक निहित कॉल के साथ चलाया जाता है जो कंपाइलर द्वारा व्युत्पन्न-श्रेणी कन्स्ट्रक्टर के शरीर में पहला बयान के रूप में डाला जाता है (डिफ़ॉल्ट नो-एर्ग कन्स्ट्रक्टर मानते हैं)।

Answer 2

व्युत्पन्न कक्षा बेस क्लास को विस्तारित करके बनाई गई है। यह सुनिश्चित किया जाना चाहिए कि आधार वर्ग के सदस्यों को व्युत्पन्न कक्षा में विस्तारित करने से पहले ठीक से शुरू किया जा सके। साथ ही, व्युत्पन्न वर्ग में शुरू किए गए सदस्यों को बेस क्लास द्वारा ओवरराइड नहीं किया जाना चाहिए।

Answer 3

पहले, माता-पिता या बच्चे का जन्म क्या होता है?

Answer 4

विचार करें कि क्या हो सकता है अगर यह दूसरी तरफ हो। आइए _id मान वाले उपयोगकर्ता वर्ग की कल्पना करें। _id का 0 एक विशेष मान है जो "अतिथि" खाते का प्रतिनिधित्व करता है ("विशेष मूल्यों" के आसपास के मुद्दों को अनदेखा करता है, सबसे पहले वे हमेशा एक बुरा विचार नहीं होते हैं, और दूसरी बात यह केवल एक उदाहरण है)। निर्माण के बाद _id भी बदला नहीं जा सकता है (जो समझ में आता है, अगर इसे अब पहचानकर्ता के रूप में बदल दिया जा सकता है)।

public class User 
{ 
    private readonly int _id; 
    public User(int id) 
    { 
    _id = id; 
    } 
    public int ID 
    { 
    get { return _id; } 
    } 
    public bool IsGuest 
    { 
    get { return _id == 0; } 
    } 
} 

अब एडमिन क्लास पर विचार करें जो इससे उप-वर्ग है। व्यवस्थापक वर्ग के नियमों में से एक यह है कि अतिथि कभी भी व्यवस्थापक नहीं हो सकता है। यह अपरिवर्तनीय सभी बिंदुओं पर लागू किया जाना चाहिए अतिथि की स्थिति, बदल सकते हैं जो इस मामले में केवल निर्माता में है:,

public class Admin : User 
{ 
    public Admin(int id) 
    :base(id) 
    { 
    if(IsGuest) 
     throw new SecurityException("Guest users cannot be admins."); 
    } 
} 

तो AdminUser से पहले निर्माण किया गया था तो यह हमेशा इस अपवाद के रूप में परीक्षण हमेशा होगा 0 के साथ 0 की तुलना करें। यदि हमारे पास मेहमानों के लिए एक अलग विशेष मूल्य था तो यह और भी बदतर होगा, और अपवाद को कभी भी फेंकने के बावजूद कभी भी फेंक नहीं देगा, और सुरक्षा समस्या की अनुमति होगी।

ध्यान रखें कि Admin कक्षा लिखने वाले व्यक्ति को इस बारे में कोई जानकारी नहीं है कि User अपने सार्वजनिक और संरक्षित इंटरफेस के बारे में क्या दस्तावेज है उससे परे काम करता है। id शून्य या नहीं है, इसके लिए वे अपना स्वयं का परीक्षण जोड़कर ऊपर दिए गए मुद्दे को पकड़ सकते हैं, लेकिन इसके अलावा कोड की एक अनिवार्य नकल होने के कारण, उन्हें पता होना चाहिए कि IsGuest कैसे काम करता है, और यह और अधिक जटिल हो सकता है यह ऊपर की तुलना में है, और शायद शायद स्वामित्व, obfuscated और अनियंत्रित।

अधिक आम तौर पर, "एक व्यवस्थापक का निर्माण" की पूरी अवधारणा को "उपयोगकर्ता को बनाने" की अवधारणा के बिना कोई समझ नहीं आता है, जो पहले हुआ है, हम एक्स बनाने के बिना एक और विशेष प्रकार का एक्स नहीं बना सकते एक शर्त के रूप में।