इंटरफेस बनाम सार वर्ग (विशिष्ट मामले में)

Question

मैंने डुप्लिकेशंस से बचने के लिए इस वेबसाइट पर कुछ खोज की है, हालांकि अधिकांश प्रश्न इंटरफेस और अमूर्त वर्ग के बीच एक अमूर्त तुलना के बारे में थे।

मेरा प्रश्न मेरी विशिष्ट स्थिति विशेष रूप से मेरे सहयोगी के लिए अधिक है और मैं एक ही दृष्टिकोण के बारे में सहमत नहीं हूं।

मैं 3 वर्गों

1. नोड (एक फ़ोल्डर संरचना में सार नोड)
2. फ़ोल्डर है
3. फ़ाइल

हम करने के लिए समग्र पैटर्न का उपयोग (उप फ़ोल्डर और फ़ाइलें शामिल है) सभी फ़ोल्डर्स और उनकी अनुमतियां प्रति उपयोगकर्ता/समूह

कक्षा Node , यह इंटरफेस या सार वर्ग होना चाहिए? Folder और File नोड से प्राप्त होता है।

मेरी राय में मुझे लगता है कि क्योंकि File सभी तरीकों Folder उदाहरण AddFolder(Node node)

मेरे सहयोगी ने कहा है कि यह बेहतर कोडिंग के लिए इंटरफेस का उपयोग करने के लिए बेहतर है है कि नहीं होना चाहिए Node एक सार होना चाहिए।

संपादित करें: मैं इस प्रकार मेरी नोड दुबारा लिखा:

public abstract class Node 
{ 
    public string Name { get; set; } 
    public string FullName { get; set; } 
    public Node Parent { get; set; } 

    public List<PermissionEntry> Permissions { get; set; } 

    protected Node(string fullName) 
    { 
     FullName = fullName; 
     Permissions = new List<PermissionEntry>(); 
    } 

    public void AssignPermission() 
    { 
     // some Codes 
    } 
} 

Answer 1

लागू करता है वर्णन करता है कोई सही जवाब है यहाँ। यह वास्तव में इस सवाल करने पर निर्भर करता

"Node किसी भी कार्यान्वयन हैFile और Folder के लिए आम है कि?"

अगर जवाब है हाँ, तो एक सार वर्ग, जरूरत वैकल्पिक रूप से एक इंटरफेस है जो अपने व्यवहार

का वर्णन उत्तर कोई है के साथ है, तो आप यह एक सार के साथ वैकल्पिक रूप से एक इंटरफ़ेस बना सकता है, आधार कार्यान्वयन।

तो आप देखते हैं - इसकी मूल रूप से वही तरीका है।

---

के अलावा, वहाँ Folder रोक Node पर परिभाषित नहीं अतिरिक्त तरीकों जो File का हिस्सा नहीं होगा जोड़ने कुछ नहीं है।

जैसे,

public interface INode 
{ 
    void SomethingCommon(); 
} 

public File: INode 
{ 
    public void SomethingCommon(){...} // I must implement this 
} 

public Folder : INode 
{ 
    public void SomethingCommon(){...} // I must implement this 
    public void AddFolder(string name) 
    { 
     // File doesnt need this method, its not on the interface! 
    } 
} 

Answer 2

इंटरफ़ेस खारिज के लिए आपका तर्क बंद लगता है। File में एक विधि AddFolder है यदि Node एक सार श्रेणी थी, लेकिन यह एक इंटरफ़ेस नहीं था?

यदि आप आम तौर पर सभी बच्चों को साझा करते हैं तो आम तौर पर एक अमूर्त वर्ग बनाना चुनते हैं। इस मामले में, यह सामान्य कार्यक्षमता सार आधार वर्ग द्वारा लागू की जाएगी, इसलिए इसे सभी बच्चों में लागू नहीं किया जाना चाहिए।

कई मामलों में, तुम भी दोनों है:

1. एक इंटरफेस है कि अनुबंध
2. एक सार वर्ग कि इंटरफेस और कुछ सामान्य कार्यक्षमता

Answer 3

तुम क्या कह रहे से ....

चाहे नोड एक इंटरफेस या वर्ग है, अगर यह इस पर विधि "AddFolder" है, और फ़ाइल नहीं कर सकते इसे लागू करें, फिर आपको डिजाइन के साथ समस्या है।

समस्या यह है कि, नोड पर्याप्त सार नहीं है, आपको इसे सामान्य इंटरफ़ेस तक सीमित करने की आवश्यकता है।

Answer 4

आपका तर्क क्यों नोड को अमूर्त होना चाहिए क्योंकि फ़ाइल में फ़ोल्डर के समान तरीके नहीं होना चाहिए। एक इंटरफ़ेस नोड बनाने का मतलब क्यों है कि उनके पास समान विधियां होंगी? आईएनओडी एक मार्कर इंटरफ़ेस हो सकता है जो फ़ाइल और फ़ोल्डर दोनों कार्यान्वित करता है। यदि फ़ोल्डर में संचालन का एक अलग सेट होता है (जो यह संभवतः करता है) तो मेरे पास उस ऑपरेशन के साथ IFolder के लिए एक और इंटरफ़ेस होगा।

संक्षिप्त प्रश्न से मैं व्यक्तिगत रूप से विरासत का उपयोग करके इस परिदृश्य में इंटरफेस का उपयोग करता हूं, यह नोड पर कुछ परिभाषित करने के लिए बहुत आसान है कि फाइल वारिस होगी जो फ़ाइल पर नहीं है।

Answer 5

मैं सामान्य रूप से इस नियम का उपयोग:

दो वर्गों कुछ सामान्य तरीके है, तो लेकिन उनके कार्यान्वयन के लिए एक इंटरफेस अलग इस्तेमाल होता है।

यदि दो वर्गों में कुछ सामान्य तरीके हैं और वे कुछ सामान्य कार्यान्वयन को एक मूल वर्ग के रूप में एक सार वर्ग के रूप में साझा करते हैं।