2012-04-26 13 views
8

मैं जावा में कोडित एक जटिल उद्यम अनुप्रयोग पर काम कर रहा हूं जो जटिल ऑब्जेक्ट रचनाओं द्वारा संचालित है। उदाहरण के लिए: एक विशेष परिदृश्य में, कोई कार्रवाई करने के इस प्रवाह है:क्या यह विधियों को लिखने के लिए एक अच्छा अभ्यास है जो शून्य लौटाता है?

login() -> 
Followed by defined sequence of 10 to 20 method calls in different classes -> 
Followed by a logout() 

ढांचे के भीतर, लगभग सभी लॉगिन, लॉगआउट था और इसमें 10 से 20 विधि कॉल के कई कार्यों कोई वापसी है प्रकार के। किसी भी गलत व्यवहार ढांचे द्वारा संभाला जाता है। लॉगिन

public void login(){ 
try{ 
//login actions 
//chained sequence of calls 

}catch(){ 
// framework handling exceptions and other rollback options 
} 
} 

मध्यवर्ती 10 से 20 कार्यों में कहते हैं, विधि ढांचे के पदानुक्रम के विभिन्न स्तरों पर विभिन्न वस्तुओं पर कॉल कर रहे हैं।

एक यादृच्छिक वर्ग इस प्रकार दिखाई देगा:

class someobject{ 

def variable 

void action1(){ do something on variable } 
void action2(){ do something on variable } 
... 
} 

चर परिवर्तन अक्सर राज्य और इन कार्यों एक दृश्य ढांचा जो मैं बहुत कष्टप्रद द्वारा केवल परिभाषित किया गया है।

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

तो अब, मैं इस धारणा के तहत हूं कि कुछ ऐसा काम लिखना हमेशा बेहतर होता है, जो विशेष रूप से जब क्रियाओं की एक श्रृंखला होती है। तो, क्या यह एक सुरक्षित धारणा है? मैं इस पर आपकी राय लेना चाहता हूं। अगर मैं गलत हूं तो मुझे सही करो।

+0

जो आप यहां समझाते हैं वह ऐसा लगता है कि आप एक उचित घटक संचालित डिज़ाइन खो रहे हैं। दृष्टिकोण का परिणाम अनजान 'स्पैगेटी कोड' होगा। आपको कुछ इंटरमीडिएट परतों को पेश करने की आवश्यकता हो सकती है ... – home

उत्तर

4

किसी विधि का सबसे आधार परीक्षण योग्यता इसके रिटर्न कोड के माध्यम से होता है। login के मामले में आपको यह जांचने में सक्षम होना चाहिए कि आपने अभी लॉग इन किया है या boolean वापसी स्पष्ट तरीका है। अन्यथा आपको कुछ संपत्ति की जांच करनी है, जो अनावश्यक रूप से गैर-परमाणु और जटिल लगता है (हालांकि अन्य कारणों से इसकी आवश्यकता हो सकती है)।

मेरे लिए, यह तर्क किसी भी सार्थक विधि तक फैला हुआ है। void का उपयोग करना रिटर्न कोड काफी आम है लेकिन अच्छे डिजाइन कारणों की तुलना में पुरानी आदतों के परिणामस्वरूप अधिक है। सरल संपत्ति सेटर्स हालांकि काउंटर-उदाहरण हैं, और मुझे यकीन है कि अन्य भी हैं।

+1

यदि आप कार्यात्मक प्रोग्रामिंग (जो मैं हूं) का प्रशंसक हूं, तो मैं एक कदम आगे जाऊंगा और कहूंगा कि विधियां व्यवहार्य स्थिति का संकेत हैं - जो खराब है। –

2

जब कोई विधि वर्ग में स्थानीय डेटा पर चलती है, तो एक शून्य विधि पूरी तरह से उचित होती है, जब तक कि यह कुछ "व्यवहार" मॉडल करती है जो वर्ग के संदर्भ में समझ में आता है। उदाहरण के लिए, यदि आपके पास स्पेशलोर्टेडलिस्ट है जो इसकी सामग्री टाइप करता है, यानी myList.sort(), सॉर्ट() विधि शून्य हो जाएगी क्योंकि यह स्पेशलसोर्टेडलिस्ट से जुड़े कुछ व्यवहारों को मॉडल करती है।

यदि कोई विधि कक्षा के भीतर स्थानीय डेटा पर काम नहीं करती है, यानी यह पैरामीटर के माध्यम से अपना डेटा निकालती है और डेटा के कुछ टुकड़े (यानी स्थानीय डेटा पर निर्भरता नहीं) लौटाती है, तो यह स्थिर और यहां तक ​​कि इसे स्थिर घोषित करना भी अच्छा अभ्यास है इसे एक उपयोगिता या सहायक वर्ग में ले जाएं।

2

मेरी राय में हमेशा कार्यों की श्रृंखला पर कुछ वापस करने की आवश्यकता नहीं है यह पूरी तरह से आपकी आवश्यकताओं पर निर्भर करता है। I.e लॉगिन में प्रमाणीकरण विधि सरलीकरण के लिए बूलियन परिणाम लौटने के लिए बेहतर है। यदि कार्यवाही की श्रृंखला एक और दूसरे से स्वतंत्र होती है तो मेरी राय में ऐसी किसी भी चीज को वापस करने की आवश्यकता नहीं है जिसका उपयोग किसी भी कार्रवाई द्वारा नहीं किया जाएगा। तो यदि एक क्रिया का परिणाम अगली कार्रवाई को प्रभावित करता है तो उसे सरलीकरण और परीक्षण के लिए कुछ वापस करना चाहिए ताकि आप सीधे उस विधि के आउटपुट से ट्रैक्ट कर सकें जो समस्याएं पैदा कर रहा है।एक बार विधि की पहचान हो जाने के बाद आप पहचान की गई विशिष्ट विधि की जांच कर सकते हैं। तो मूल रूप से हर चीज आपकी आवश्यकताओं पर निर्भर करती है। यदि आपकी आवश्यकताओं को कुछ वापस किए बिना बेहतर तरीके से संभाला जाता है तो आपको इसके साथ जाना चाहिए। इसके अलावा आपको प्रभावशीलता के लिए सर्वोत्तम प्रथाओं या डिजाइन पैटर्न का पालन करना चाहिए जो सभी परिस्थितियों के लिए बेहतर होगा और आप अंत में गड़बड़ी बनाने से छुटकारा पा सकते हैं। यह सिर्फ मेरी राय है।

0

अधिक से अधिक, मैं बजाय एक स्थिति कोड शून्य की तरह कुछ वापस जाने के लिए पसंद करते हैं। यह चीजों की एक जोड़ी है:

  1. मैं कोड अपने कार्य कहा जाता है अगले (उदाहरण के लिए, यदि कार्रवाई विफल रही तो बुला कोड कुछ अलग करना आवश्यकता हो सकती है कि क्या करना है पता करने के लिए अनुमति देता है कि अगर आपरेशन सफल रहा)।
  2. परीक्षण और डीबग करना आसान है (जैसा कि आप उल्लेख करते हैं)। मैंने विश्वास करना शुरू कर दिया है कि टेस्टेबिलिटी के लिए कोड लिखना कोड की गुणवत्ता सुनिश्चित करने के सर्वोत्तम तरीकों में से एक है (यह मानते हुए कि आप वास्तव में इसका परीक्षण करते हैं)। शून्य कार्यों का परीक्षण करना मुश्किल है।

मेरी वरीयता है, जब भी संभव हो, अधिकांश कार्यों में पैरामीटर लेते हैं, एक जवाब देते हैं और किसी भी वर्ग चर को नहीं बदलते हैं। जैसा जैको ने उल्लेख किया है, इन्हें स्थैतिक घोषित किया जा सकता है और यहां तक ​​कि उपयोगिता वर्ग में भी स्थानांतरित किया जा सकता है। फिर आपके पास कुछ नियंत्रक फ़ंक्शंस फ़ंक्शन का उपयोग करने वाले फ़ंक्शंस का उपयोग कर सकते हैं।

0

मैं 2 भागों के रूप में जवाब विभाजित होगा:

  • जब "शून्य" उपयोगी लौटा रहा है -

    विधि एक मूल्य लौटने जाता है, तो केवल एक गलत राज्य/अपवाद इंगित करने के लिए है, तो यह "शून्य" वापस आना चाहिए। अपवाद को "बूलियन" रिटर्न वैल्यू कहने के बजाय सभी त्रुटि परिदृश्यों को संभालने का ख्याल रखना चाहिए। अब, कॉलिंग कोड को फिर से बुलियन और अपवाद दोनों को सत्यापित करने की आवश्यकता है। अगर यह केवल अपवाद फेंक दिया गया था, तो यह कॉलिंग कोड के लिए & स्पष्ट है।

  • जब शून्य नहीं तो उपयोगी लौटा रहा है - विधि किसी भी कार्रवाई निष्पादित करता है और एक परिणाम के रूप में एक मान देता है

    है, तो "शून्य" वापस नहीं किया जाना चाहिए, प्रासंगिक परिणाम प्रकार (बूलियन/पूर्णांक/वस्तु आदि) वापस लौटने की जरूरत है।

सामान्य में, वापसी मान चाहिए विधि कुछ देता है या नहीं करने के लिए वास्तविक अनुरूप हैं। यह इस बात से मेल नहीं खाता कि विधि सही तरीके से निष्पादित की गई है (ठीक है, यह माना जाता है)। सभी इनपुट सत्यापन/अपवाद परिदृश्यों को संबंधित अपवादों को फेंकने के माध्यम से संभाला जाना चाहिए। उदाहरण, जब अवैध हो तो इनपुट अवैध है, "बूलियन" कहने की बजाय विधि निष्पादित नहीं किया गया था।

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