2010-04-20 5 views
13

मैं नकली/ज़िम्मेदारी संचालित डिज़ाइन की कोशिश कर रहा हूं। मुझे ऑब्जेक्ट्स के मामले में मोक्स से लौटने वाले मोक्स से बचने में समस्याएं होती हैं जिन्हें अन्य ऑब्जेक्ट्स को पुनर्प्राप्त करने के लिए सेवा की आवश्यकता होती है।किसी मॉक ऑब्जेक्ट सूची से लौटने वाले मैक से बचने के लिए कैसे करें

एक उदाहरण एक ऐसा ऑब्जेक्ट हो सकता है जो जांचता है कि पिछले महीने के बिलों का भुगतान किया गया है या नहीं। इसे ऐसी सेवा की आवश्यकता है जो बिलों की एक सूची पुनर्प्राप्त करे। तो मुझे अपने परीक्षणों में उस बिलरेट्रिवल सेवा का नकल करने की ज़रूरत है। साथ ही मुझे बिलरेट्रिवलॉक को मॉक बिलों को वापस करने की आवश्यकता है (क्योंकि मैं नहीं चाहता कि मेरा परीक्षण बिल कार्यान्वयन की शुद्धता पर भरोसा करे)।

क्या मेरा डिज़ाइन त्रुटिपूर्ण है? क्या इसका परीक्षण करने का कोई बेहतर तरीका है? या यह खोजक वस्तुओं (इस मामले में बिलों की खोज) का उपयोग करते समय यह होना आवश्यक है?

साइड नोट: बिलकुल बिल एक मूल्य वस्तु उम्मीदवार हो सकता है, तब भी बड़ी समस्या तब भी बनी हुई है जब संग्रह में मूल्य वस्तुओं (जैसे उपयोगकर्ता) शामिल नहीं होते हैं।

+0

ध्यान दें कि अंतिम टैग बहुत लंबा था और इस प्रकार छोटा कर दिया गया था (और एक टाइपो भी था)। –

+0

क्या आप नकली बिल वापस कर रहे हैं, या बस स्टब्स? एक सेवा जो स्टब्स की एक सूची लौटाती है वह मेरे लिए पूरी तरह से स्वीकार्य प्रतीत होती है। – Mathias

+0

@ माथीस उन मॉक्स हैं जिन पर मेरी ऑब्जेक्ट को उन पर एक (मॉक) विधि के परिणाम की आवश्यकता है। – koen

उत्तर

11

अधिकांश समय, अगर मुझे एक और नकली वापस करने के लिए एक नकली की ज़रूरत है, तो मुझे एक निर्भरता मिलती है जो दूसरी दिशा में अधिक समझ में आता है। अलग-अलग बताते हुए, मॉक-रिटर्निंग-मॉक आम तौर पर निर्भरता उलटा सिद्धांत का उल्लंघन करने के लिए इंगित करता है।

एक आम अपवाद: एक कारखाना जो ऑब्जेक्ट बनाता है (एक "धारक" के विपरीत जो हर बार एक ही ऑब्जेक्ट देता है)। अगर मुझे अपने जीवनकाल के दौरान एक ही प्रकार की कई वस्तुएं बनाने की ज़रूरत है, तो मुझे ObjectFactory पर निर्भर रहने की आवश्यकता हो सकती है और #createObject() का आह्वान करना पड़ सकता है, फिर संभवतः ऑब्जेक्ट्स पर अपेक्षाएं निर्धारित कर सकते हैं। फिर भी, मैं इस पर सवाल उठाऊंगा। मेरे लिए Object एस बनाने के लिए कॉल स्टैक को एक और स्तर के लिए संभव हो सकता है और उन्हें आवश्यकतानुसार मुझे दे सकता है।

ObjectHolder मामले में, बल्कि ObjectHolder के आधार पर Object प्राप्त करने के लिए की तुलना में, मैं Object पर सीधे निर्भर करते हैं और मेरे लिए लेकिन यह चाहता है देने के लिए मेरे फोन करने वाले के लिए मजबूर करना पसंद करते हैं। यह संदर्भ आजादी की वांछनीय डिजाइन संपत्ति का सम्मान करता है।

इस समस्या का एक विशिष्ट संस्करण "आभासी घड़ी" पैटर्न है। कभी-कभी आपको वर्चुअल घड़ी पर निर्भर रहने की आवश्यकता होती है, लेकिन अक्सर टाइमस्टैंप की मांग करना बेहतर होता है। ("तत्काल अनुरोध" पैटर्न।)

10

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

नकली वस्तुओं के आविष्कारकों से Growing Object-Oriented Software, Guided by Tests और पेपर Mock Roles, not Objects पुस्तक पढ़ने योग्य हैं।

+0

मेरे पास पुस्तक की एक प्रति है और मैंने पेपर पढ़ लिया है। जो मैं टालना चाहता हूं वह ऐसे परीक्षण हैं जो असफल होते हैं और मुझे आश्चर्य करना होगा कि विफलता बिलों में भुगतान की गई है या नहीं। मूल्य वस्तुएं मॉकिंग नहीं लगती हैं जब वे वास्तव में सरल होते हैं। – koen

4

आमतौर पर जब मैं नकली करता हूं तो मैं वस्तुओं का एक तिहाई होने का अंत करता हूं। पहली वस्तु एक समन्वयक BillsPaidLastMonthCoordinator होगी इस ऑब्जेक्ट में दो निर्भरता BillRetrievalService और BillPaidValidator है।

आप दो निर्भरताओं का नकल करेंगे और आपका परीक्षण पुनर्प्राप्ति के लेनदेन और सत्यापन के लिए बिल पास करने के लिए होगा। तो इस परीक्षण के लिए आपको परवाह नहीं होगा कि डेटा क्या है। यह अलग जिम्मेदारियों में मदद करता है। आपकी मूल वस्तु Bills पुनर्प्राप्त करने के लिए ज़िम्मेदार थी और फिर यह देखने के लिए कि क्या यह एक भुगतान बिल था।

जिस तरह से आपने समस्या का वर्णन किया है, वैसे ही आप समाप्त कर सकते हैं एक शोर और भंगुर परीक्षण है। दो तरीकों से टूटने में सक्षम होने से यह बेकारता आती है।

corrdinator के साथ, Bill कार्यान्वयन में परिवर्तन होने पर इसे बदलने की ज़रूरत नहीं है, केवल वे वस्तुएं जो वास्तव में Bill का उपयोग करती हैं। मेरा 2 सेंटावोस

[संपादित करें]

यह और अधिक ईवेंट हैंडलर्स (समन्वयक)

4

Way of the Testuvius सलाह, कोई सिद्धांत, हालांकि अच्छा के रूप में, पूरी तरह से लिया जाता है और किया जाना चाहिए का उपयोग कर के साथ गठबंधन किया है, ताकि इसके साथ भी है नियम है कि आपको मोक्स लौटने वाले मोजे की आवश्यकता नहीं है, ऐसे मामले हैं जब यह काफी उपयुक्त है।

जैसा कि गुट्ज़ोफ्टर सुझाव देता है, आप वास्तविक वस्तु के लिए दो ऑब्जेक्ट को तोड़ सकते हैं और दूसरा बिल सत्यापित करने के लिए बिलों को पुनर्प्राप्त करने के लिए। इस "एकल जिम्मेदारी केवल" सिद्धांत का लाभ यह है कि वैधकर्ता अधिक सामान्य और पुन: प्रयोज्य होगा। दूसरी तरफ, यदि आपके पास केवल इतना आसान उपयोग मामला है और उच्च पुन: प्रयोज्यता के लिए कोई विशेष आवश्यकता नहीं है, तो यह एक वर्ग में पुनर्प्राप्ति और सत्यापन को रखने के लिए बहुत व्यावहारिक है। ऑब्जेक्ट्स की संख्या का स्तर, विस्फोट, वास्तविक आवश्यकता और एक वास्तविक लाभ से अनुचित, केवल एक सार सिद्धांत को संतुष्ट करने के लिए किया जाता है, अच्छा नहीं है।आपको हमेशा पेशेवरों और विपक्षों को वज़न कम करना पड़ता है और वास्तविकता शायद ही सरल और उतनी ही सुंदर है जितनी हम चाहें :-) इस व्यावहारिक दृष्टिकोण के महान उदाहरण हैं एडम बिएन के रियल वर्ल्ड जावा ईई पैटर्न - सर्वोत्तम व्यवहारों पर पुनर्विचार।

संबंधित मुद्दे