क्या कक्षा में आधार वर्ग के रूप में खाली कक्षा होने का बुरा अभ्यास है, उम्मीद है कि कक्षा में भविष्य में सदस्य हो सकते हैं?

Question

सरल उदाहरण:

public class Food 
{ 
    public virtual void Eat() 
    { 
     StuffInMouth(); 
    } 
} 

public class Fruit : Food 
{ 
    // Nothing here yet, but likely could be in the future 
    // Is this bad from a .NET/C# style guidelines perspective? 
} 

public class Apple : Fruit 
{ 
    public virtual void Eat() 
    { 
     Clean(); 
     base.Eat(); 
    } 
} 

public class Orange : Fruit 
{ 
    public virtual void Eat() 
    { 
     Peel(); 
     base.Eat(); 
    } 
} 

Answer 1

के रूप में सरल रूप में मैं इसे रख सकते हैं, यह Speculative Generality कहा जाता है।

समस्या के कारण: कभी-कभी कोड अनुमानित भविष्य की सुविधाओं का समर्थन करने के लिए "बस मामले में" बनाया जाता है जो कभी लागू नहीं होता है। नतीजतन, कोड समझने और समर्थन करने के लिए मुश्किल हो जाता है।

---

_{स्टीव McConnell कोड पूरा में बताते हैं के रूप में - 2,}

_{प्रोग्रामर्स अनुमान लगा क्या कार्यक्षमता किसी दिन की आवश्यकता हो सकती पर बेहद खराब हैं।}

_{1. आवश्यकताओं नहीं जाना जाता है, इसलिए प्रोग्रामर लगता है कि होना चाहिए: गलत अनुमान मतलब होगा कोड फेंक दिया जाना चाहिए।}

_{2. यहां तक ​​कि एक करीबी अनुमान विवरण के बारे में गलत हो जाएगा: इन पेचीदगियों प्रोग्रामर के मान्यताओं को कमजोर करेगा - कोड होना चाहिए (या होना चाहिए) फेंक दिया।}

_{3. अन्य/भविष्य प्रोग्रामर सट्टा कोड बेहतर काम करता है या की तुलना में यह अधिक आवश्यक है मान सकते हैं: वे सट्टा कोड के आधार पर कोड का निर्माण, लागत बढ़ जाती है जब सट्टा कोड होना चाहिए हटाया या बदला जा सकता है।}

_{4. सट्टा व्यापकता जटिलता ला देता है और अधिक परीक्षण और रखरखाव की आवश्यकता है: यह लागत के लिए कहते हैं और पूरी परियोजना को धीमा कर देती।}

---

^{क्रेडिट: कोड पूरा - 2 | Pluralsight course on refactoring।}

Answer 2

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

Answer 3

हाँ, यह जानना महत्वपूर्ण है कि यह इस तरह की चीजों को करने के लिए समय बचा सकता है (यदि इसका उपयोग किया जाता है) तो यह तुरंत भविष्य के लिए कोड करना बेहतर होता है, या कम से कम समझते हैं कि आप भविष्य के लिए कोडिंग कर रहे हैं वह कभी नहीं आएगा।

चीजों को बहुत जल्दी लागू करने के रखरखाव ओवरहेड भी है।

Answer 4

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

आपके मामले में, अपने कोड आम तौर पर भोजन पर काम करना चाहिए, फिर भी एक आम Food पूर्वज समझ में आता है। हालांकि, एक बेहतर अवधारणा एक IFood इंटरफेस शुरू किया जा सकता है, प्रभावी रूप से वास्तविक विरासत से खाना अनुबंध decoupling पदानुक्रम। उदाहरण के लिए, एक सार्थक पदानुक्रम एक Animal वर्ग के साथ शुरू हो सकता है, लेकिन हर पशु भोजन (अस्वीकरण: इस किसी न किसी उदाहरण है) माना जाता है।