आपको पहले से ही कुछ अच्छे जवाब मिले हैं, लेकिन आपके सवाल में कमरे का विशाल हाथी यह है:
किसी से सुना है कि विरासत का उपयोग करने से बचना चाहिए, और हमें इसके बजाय इंटरफेस का उपयोग करना चाहिए
अंगूठे के नियम के रूप में, जब कोई आपको अंगूठे का नियम देता है, तो इसे अनदेखा करें। यह न केवल "किसी को आपको कुछ बताने" के लिए जाता है, बल्कि इंटरनेट पर सामान पढ़ने के लिए भी जाता है। जब तक आप नहीं जानते कि क्यों (और वास्तव में इसके पीछे खड़े हो सकते हैं), ऐसी सलाह बेकार है और अक्सर बहुत हानिकारक होती है।
मेरे अनुभव में, ओओपी में सबसे महत्वपूर्ण और सहायक अवधारणाएं "कम युग्मन" और "उच्च सामंजस्य" हैं (कक्षाएं / ऑब्जेक्ट्स एक दूसरे के बारे में जितना संभव हो उतना कम जानते हैं, और प्रत्येक इकाई यथासंभव कम चीजों के लिए जिम्मेदार है)।
कम युग्मन
इसका मतलब यह है कि आपके कोड में किसी भी "सामान का बंडल" अपने परिवेश पर जितना संभव हो उतना कम निर्भर होना चाहिए। यह कक्षाओं (वर्ग डिजाइन) लेकिन वस्तुओं (वास्तविक कार्यान्वयन), सामान्य रूप से "फाइलें" (यानी, #includeप्रति एकल .cppफ़ाइल की संख्या, importप्रति .javaफ़ाइल की संख्या और इतने पर) के लिए जाती है।
एक संकेत है कि दो संस्थाएं युग्मित हैं, उनमें से एक टूट जाएगा (या बदलने की आवश्यकता है) जब दूसरे को किसी भी तरह से बदल दिया जाता है।
विरासत में युग्मन बढ़ता है, जाहिर है; बेस क्लास बदलने से सभी उपवर्ग बदल जाते हैं।
इंटरफेस युग्मन को कम करते हैं: एक स्पष्ट, विधि-आधारित अनुबंध को परिभाषित करके, आप इंटरफ़ेस के दोनों किनारों के बारे में कुछ भी स्वतंत्र रूप से बदल सकते हैं, जब तक कि आप अनुबंध को नहीं बदलते। (ध्यान दें कि "इंटरफ़ेस" एक सामान्य अवधारणा है, जावा interfaceया सी ++ सार कक्षाएं केवल कार्यान्वयन विवरण हैं)।
उच्च सामंजस्य
इसका मतलब है कि प्रत्येक वर्ग, वस्तु, फ़ाइल आदि के संबंध में कम से कम या यथासंभव जिम्मेदार हों। यानी, बड़ी कक्षाओं से बचें जो बहुत सारा सामान करती हैं। आपके उदाहरण में, यदि आपके हथियारों में अलग-अलग पहलू (बारूद, फायरिंग व्यवहार, चित्रमय प्रतिनिधित्व, सूची प्रतिनिधित्व आदि) हैं, तो आपके पास अलग-अलग वर्ग हो सकते हैं जो उन चीजों में से एक का प्रतिनिधित्व करते हैं। मुख्य हथियार वर्ग तब उन विवरणों के "धारक" में बदल जाता है; एक हथियार वस्तु तब उन विवरणों के कुछ संकेत से थोड़ा अधिक है।
इस उदाहरण में, आप यह सुनिश्चित करेंगे कि "फायरिंग बिहेवियर" का प्रतिनिधित्व करने वाला आपका वर्ग मुख्य हथियार वर्ग के बारे में जितना संभव हो उतना कम जानता है। वैकल्पिक रूप से, कुछ भी नहीं। उदाहरण के लिए, इसका मतलब यह होगा, कि आप अपनी दुनिया में किसी भी वस्तु ("फ़ॉरेस्ट, ज्वालामुखी, NPCs ..." को एक उंगली की एक तस्वीर द्वारा "फायरिंग बिहेवियर" दे सकते हैं । यदि आप किसी समय में बदलना चाहते हैं कि कैसे इन्वेंट्री में हथियारों का प्रतिनिधित्व किया जाता है, तो आप बस इतना कर सकते हैं - केवल आपके इन्वेंट्री वर्ग को इस बारे में पता है।
एक संकेत है कि एक इकाई सामंजस्यपूर्ण नहीं है यदि यह बड़ा और बड़ा हो जाता है, तो एक ही समय में कई दिशाओं में शाखाकरण होता है।
जैसा कि आप वर्णन करते हैं कि विरासत में सामंजस्य कम हो जाता है - आपकी हथियार कक्षाएं दिन के अंत में होती हैं, जो बड़ी मात्रा में होती हैं जो आपके हथियारों के सभी प्रकार के विभिन्न, गैर-संबंधित पहलुओं को संभालती हैं।
इंटरफेस के दो पक्षों के बीच जिम्मेदारियों को स्पष्ट रूप से विभाजित करके अंतर अप्रत्यक्ष रूप से सामंजस्य बढ़ाते हैं।
अब क्या करे
अभी भी कोई कठिन और तेज़ नियम नहीं हैं, यह सब सिर्फ दिशा निर्देश हैं। सामान्य तौर पर, जैसा कि उपयोगकर्ता टीकेके ने अपने उत्तर में उल्लेख किया है, विरासत को स्कूल और पुस्तकों में बहुत कुछ सिखाया जाता है; यह OOP के बारे में फैंसी सामान है। इंटरफेसेस दोनों शायद सिखाने के लिए अधिक उबाऊ हैं, और यह भी (यदि आप पिछले उदाहरणों पर जाएं) थोड़ा कठिन है, निर्भरता इंजेक्शन के क्षेत्र को खोलना, जो विरासत के रूप में इतना स्पष्ट नहीं है।
दिन के अंत में, आपकी विरासत आधारित योजना अभी भी कोई स्पष्ट OOP डिजाइन होने से बेहतर है। इसलिए बेझिझक इसके साथ चिपके रहें। यदि आप चाहते हैं, तो आप लो कपलिंग, उच्च सामंजस्य के बारे में थोड़ा-सा पता लगा सकते हैं या यह देख सकते हैं कि क्या आप इस तरह की सोच को अपने शस्त्रागार में जोड़ना चाहते हैं। आप हमेशा कोशिश कर सकते हैं कि अगर आप चाहें, तो बाद में इसे आज़माएं; या कोड के अपने अगले बड़े नए मॉड्यूल पर इंटरफ़ेस-आधारित दृष्टिकोण आज़माएं।