किस तरह की अंतर्दृष्टि या प्रश्न आपको किसी व्यक्ति के ओओएडी कौशल का निर्धारण करने के लिए प्रेरित करेंगे।
जवाबों:
आप एक साधारण समस्या के बारे में कुछ आधा-ओओ डिज़ाइन दिखा सकते हैं, और चर्चा करते हैं कि यह क्या करता है, इसके बारे में क्या अच्छा है और क्या बुरा है, क्या यह पर्याप्त लचीला है, क्या सुधार किया जा सकता है, और कैसे।
यदि आपको चर्चा जारी रखने की आवश्यकता है, तो पूछें कि व्यक्ति कोड के कुछ पहलू के बारे में क्या सोचता है, लेकिन एक अग्रणी प्रश्न के साथ नहीं।
महत्वपूर्ण यह याद रखना है कि चर्चा महत्वपूर्ण है, न कि यह कि आप पहले से उत्तर जानते थे। किसी भी सभ्य डेवलपर को उस कोड के बारे में कुछ इंगित करने में सक्षम होना चाहिए जो आपने पहले भी नहीं सोचा था।
व्यक्ति के साथ एक खुले अंत डिजाइन समस्या पर चर्चा करें। देखें कि सिस्टम के एक मॉडल के निर्माण के लिए वह किस तरह से आगे बढ़ता है, किस तरह के प्रश्न पूछे जाते हैं, नई जानकारी के जवाब में डिज़ाइन कैसे बदलता है।
एक महान उदाहरण - स्टीव येज ने अपने एक ब्लॉग पोस्ट में उल्लेख किया है - व्यक्ति को एक्सएमएल के लिए ऑब्जेक्ट मॉडल के साथ आने के लिए कहना है।
सभी सबसे लोकप्रिय डिजाइन पैटर्न का अच्छा ज्ञान होने से उम्मीदवार अपने डिजाइन की समस्याओं के समाधान के लिए वास्तव में खोजा जा सकता है।
उन पर चर्चा करने और उन्हें लागू करने के बारे में जानने में सक्षम होना एक अच्छा संकेत है कि वह उन्हें समझता है।
उदाहरण के लिए उससे पूछना उसके अतीत के अनुभवों में मदद करता है।
एक शब्दावली प्रश्नोत्तरी न दें। "डिफाइन इनहेरिटेंस" या "ओओ डिज़ाइन की नाम 3 विशेषताएं" ऐसे प्रश्न हैं जो आपको किसी व्यक्ति के कौशल के बारे में कुछ भी नहीं बताएंगे, केवल तब तक जब तक वह आखिरी बार एक पाठ्यपुस्तक पढ़ता है। मैं कई महान प्रोग्रामर से मिला हूं, जो हर दिन इन कौशलों का उपयोग करते हैं, लेकिन अगर औपचारिक परिभाषा देने के लिए कहा जाए, तो वह चौंक जाएगा।
यदि संभव हो, तो नमूना कोड के लिए पूछें।
अन्यथा, एक उदाहरण के रूप में उपयोग करने के लिए कुछ प्रक्रियात्मक कोड ढूंढें (या कुछ खराब डिजाइन किए गए ओओ कोड), और फिर उनसे पूछें कि वे कैसे फिर से डिज़ाइन करेंगे, सामान्य करेंगे और इसे सुधारेंगे। सुनिश्चित करें कि कार्यक्रम में अतिरिक्त संदर्भ है, ताकि नया स्वरूप सार्थक हो सके।
अंतत: आप क्या परीक्षण कर रहे हैं - डिजाइन-- व्यक्तिपरक है। इस प्रकार, आपके मूल्यांकन को कई संभावित अच्छे समाधानों की अनुमति देने के लिए खुला होना चाहिए, और केवल एक ही नहीं। फिर, आवश्यकताओं के संभावित परिवर्तनों के बारे में सोचें जो एक इंटरफ़ेस परिवर्तन को मजबूर करेगा: वे इसे कैसे संभालते हैं?
पुस्तक को हेड फर्स्ट डिज़ाइन पैटर्न पढ़ें। पुस्तक के सभी उदाहरण ऑब्जेक्ट ओरिएंटेड समस्या से शुरू होते हैं और डिज़ाइन पैटर्न में अंत तक होते हैं। वे यह भी बताते हैं कि ओओपी की कुछ अवधारणाएं सीमित परिणाम क्यों प्राप्त करेंगी और कुछ अन्य की तुलना में बेहतर क्यों हैं।
हालांकि एक डिज़ाइन पैटर्न पुस्तक इस पुस्तक OOP की समस्याओं से भरा है :-)
सरल शुरू करें: OOP क्या है?
आप OOP के मूल परिसर के बारे में पूछकर शुरू कर सकते हैं: अमूर्तता, बहुरूपता, विरासत और इनकैप्सुलेशन। विचार के लिए अच्छा भोजन उन्हें गर्म करने के लिए।
उन्हें एक समस्या दें
अगला, उन्हें एक समस्या के साथ प्रस्तुत करें जिसमें पैटर्न शामिल होने की संभावना है। यह नाम या पैटर्न का उपयोग करने के लिए आवश्यक नहीं है, लेकिन उनके दृष्टिकोण की संभावना होगी अगर उन्हें क्षेत्र में अनुभव मिला है।
शायद गतिशील पाठ इनपुट सत्यापन। आप यह देखने के लिए कि यह एक मान्य दिनांक, समय या दिनांक और समय ISO8601 प्रारूप में है, चरित्र द्वारा इनपुट चरित्र को मान्य करने में सक्षम होना चाहते हैं। आपको हर बार एक कुंजी दबाने पर इनपुट स्ट्रिंग की एक प्रति मिलती है और आप यह इंगित करने के लिए बूलियन वापस कर सकते हैं कि क्या पाठ कम से कम एक प्रारूप में अच्छा है। उन्हें ओओ डिजाइन सिद्धांतों का उपयोग करके डिजाइन के माध्यम से बात करने और स्केच करने के लिए कहें।
तब तक आपने चैट करना समाप्त कर दिया है
यदि वे OOD को समझते हैं तो आपको एक बहुत अच्छा विचार होगा।
उन्हें फिर से वही समस्या दें, लेकिन इस बार एक अलग डिजाइन के लिए पूछें
अब, उन्हें ऑब्जर्वर पैटर्न का उपयोग किए बिना सिस्टम को फिर से डिज़ाइन करने के लिए कहें (यदि उन्होंने इसका उल्लेख किया है) - वे चेन ऑफ रिस्पॉन्सिबिलिटी दृष्टिकोण या शायद एक कमांड पैटर्न के लिए जा सकते हैं। आप वास्तव में परवाह नहीं करते हैं, आप जानते हैं कि उनके पास शामिल सिद्धांतों का एक उचित समझ है।
यहां तक कि अगर वे एक पैटर्न आधारित दृष्टिकोण के लिए नहीं जाते हैं, तो जिस तरह से वे समस्या को अपनी संबंधित कार्यक्षमता में नीचे तोड़ने का प्रयास करते हैं, उसे सुनने के बाद परिणाम सामने आएंगे।
मैं एक वास्तविक विश्व परिदृश्य चुनता हूं, जो किसी को अच्छी तरह से पता हो real और उन्हें संस्थाओं की पहचान करने के लिए कहें; अभिनेता शामिल; उनके बीच क्या बातचीत होती है; जहां आम सुविधाओं को अमूर्त किया जा सकता है; क्या गुणों पर विचार किया जाना चाहिए।
हां, आप उन्हें यूएमएल को बैठाने और आकर्षित करने के लिए कह सकते हैं, हां आप उन्हें कुछ ओओपी कार्यान्वयन विवरणों पर खोज करने के लिए कह सकते हैं, यह देखने के लिए कि क्या वे "ग्राउंड रनिंग हिट" कर सकते हैं।
लेकिन एक नियोक्ता को वास्तव में अपनी टीम के भीतर की आवश्यकता होती है, एक ऐसा दिमाग है जो शामिल अवधारणाओं को समझता है और जो कुछ भी मुड़ता है उन्हें लागू कर सकता है। विशिष्टताओं को जल्दी से सीखा जा सकता है, जब अवधारणाएं एम्बेडेड होती हैं।
† गहरी परिचित और कोड की मदद से एक कनेक्शन की अनुपस्थिति: सुबह में एक बाथरूम का परिवार का उपयोग; डिनर बना रही हूं; काम करने के लिए एक बस मार्ग; एक कार की विधानसभा।
कुछ ऐसा है जो अच्छी तरह से काम करने लगता है, और वास्तव में केवल कुछ सेकंड लगते हैं: उन्हें ऑब्जेक्ट मॉडल डिजाइन करने के लिए कहें। यह क्या के लिए कोई फर्क नहीं पड़ता। यह बिल्कुल तुच्छ हो सकता है। वास्तव में, यह संभवतः तुच्छ होना चाहिए, परीक्षण को अनावश्यक रूप से बाहर नहीं निकालना चाहिए।
यदि वे जो पहली चीज लिखते हैं, वह एक वस्तु है, तो वे ओओ की समझ में अपने साथियों के 99% से पहले ही आगे हैं। यदि वे जो पहली चीज लिखते हैं वह एक वर्ग है, तो कृपया उन्हें बाहर जाने और अगले उम्मीदवार को अंदर भेजने के लिए कहें, और इस बारे में चिंतन करें कि इसे ओओपी क्यों नहीं और सीओपी कहा जाता है।