2012-12-25 10 views
5

मेरे पास यह देखने के लिए निम्न कोड है कि कोई गेम इकाई एक खिलाड़ी या दुश्मन है या नहीं। ये केवल दो श्रेणियां हैं। मैं isEnemy विधि को हटा सकता हूं और दुश्मन के लिए सभी चेक चला सकता हूं जैसे कि (! Isplayer), लेकिन मुझे व्यक्तिगत रूप से लगता है कि अगर (isEnemy) कोड स्पष्ट करने का इरादा रखता है। क्या ऐसी कोई स्थापित कोडिंग शैलियों है जिनके पास इस तरह की स्थिति के बारे में कुछ कहना है?क्या अनावश्यक कोड स्वीकार्य है यदि यह पठनीयता में सुधार करता है?

public boolean isPlayer(Unit unit) { 
    return unit == player; 
} 

public boolean isEnemy(Unit unit) { 
    for (Unit e : enemies) { 
     if (unit.equals(e)) 
      return true; 
    } 
    return false; 
} 
+0

IMHO यदि आप किसी उद्देश्य के साथ कोड लिखते हैं, तो जो कुछ भी आप जोड़ते हैं उसे भ्रमित करने की आवश्यकता नहीं होती है। आप उस चीज़ के उद्देश्य को खोजने का प्रयास करने में अधिक समय बर्बाद कर सकते हैं जिसका कोई उद्देश्य नहीं है जो स्पष्ट रूप से एक है। आपके उदाहरण में, यह स्पष्ट नहीं है कि एक विधि को दूसरे के साथ कैसे बदला जा सकता है। –

उत्तर

2

मुझे लगता है कि दोनों विधियां स्वीकार्य हैं। ! यदि isEnemy() == isPlayer() मैं के रूप में isEnemy() लागू करने पर विचार होगा:

public boolean isEnemy(Unit unit) { 
    return !isPlayer(unit); 
} 

इस तरह से आप दो विशिष्ट विधियों होने ज़रूरी नहीं कि वह अपने आप को दोहरा के रूप में यदि आप isPlayer समायोजित कर सकते हैं की पठनीयता हासिल() और दोनों तरीकों को प्रभावित करते हैं।

1

मेरी राय में, यह बिल्कुल स्वीकार्य है। विशेष रूप से बड़ी परियोजना में, पठनीयता बहुत आयात है। यह भी मान लें कि, यदि आप भविष्य में तीसरी भूमिका जोड़ते हैं, तो आप (! Isplayer) का उपयोग करने में सक्षम नहीं होंगे।

3

व्यक्तिगत रूप से, मैं isEnemy() को !isPlayer() के रूप में लागू करता हूं लेकिन assert है जो यह सुनिश्चित करने के लिए लूप चलाता है कि यह वास्तव में एक दुश्मन है।

6

आपके मामले में, आपके पास केवल दो संभावित राज्य हैं - वे या तो दुश्मन हैं, या वे एक खिलाड़ी हैं। यदि वे एक खिलाड़ी हैं, तो वे दुश्मन नहीं हैं। व्यक्त करने का सबसे साफ तरीका !isPlayer होगा।

यदि आपके पास अन्य संभावित राज्य थे, तो आप अन्य राज्यों पर किसी प्रकार की गणना को देखना चाहेंगे।

अंगूठे के सामान्य नियम के रूप में: Don't Repeat Yourself। यदि आपके कोड का एक हिस्सा बदलता है जिसे आपने डुप्लिकेट किया है (शायद एक बग ठीक करने के लिए), तो आपको उस बग की हर घटना को बदलना होगा। यह रखरखाव दुःस्वप्न में बदल सकता है।

1

अपना कोड देखकर आप दुश्मन की पहचान कर रहे हैं यदि यह संग्रह 'दुश्मन' में मौजूद है। तो आपके लिए एक दुश्मन अनिवार्य रूप से कोई नहीं है जो खिलाड़ी नहीं है। यदि आप इस अर्थपूर्ण को लागू करना चाहते हैं तो मुझे नहीं लगता कि आपको एनीमी() विधि से दूर जाना चाहिए।

एक और कारण आपको आवश्यकता हो सकती है एनीमी() विधि यह है कि यदि आप किसी अन्य प्रकार की एली की संभावना देखते हैं। होने के कारण एनीमी() विधि उस जोड़ को सरल और क्लीनर बनाती है।

लेकिन यदि ऊपर 2 स्थितियां वैध नहीं हैं तो इससे छुटकारा पाएं। जैसा कि वे यज्ञ कहते हैं :)

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