इस मामले में कोड के दोहराव से कैसे बचें?

Question

मेरे परियोजना जावा में एक hypergraph को लागू करने के बारे में है

मेरे hypergraph शिखर प्रकार है कि मैं

वर्टेक्स प्रकार के आधार पर hyperEdge के विभिन्न प्रकार के होते हैं: छवि, टैग ...

HyperEdge = सजातीय (एक ही प्रकार के शिखर) संबंधित/विषम (विभिन्न प्रकार के शिखर)

सजातीय HyperEdge = छवि छवि HyperEdge/टैग टैग hyperEdge

थी संबंधित एक जल्दी से यूएमएल आरेख आकर्षित

है यह मेरा कोड

public interface HomogenousHyperedge< T extends Vertex<L>, L> extends Hyperedge { 

    public abstract List<T> searchNearstNeighborsVertex(
     Hypergraph hypergraph, T vertex); 
} 

public class ImageImageHyperedge implements 
    HomogenousHyperedge<ImageVertex, Map<String,Instance>> { 

    @Override 
    public List<ImageVertex> searchNearstNeighborsVertex(Hypergraph hypergraph, 
     ImageVertex vertex) { 
     return null; 
    } 
} 

समस्या ImageImageHyperEdge वर्ग मुझे पता है क्या है चाहिए में है इसके आधार पर सुविधा का प्रकार मैं ImageVertex निकटतम पड़ोसियोंकी खोज करूंगामैं सुपर इंटरफ़ेस का सार विधि में इसे पारित नहीं कर सकते क्योंकि TagTagHyperEdge वर्ग यह

की जरूरत नहीं है और अगर मैं द्वारा ImageImageHyperEdge वर्ग की जगह {featureOneHyperEdge वर्ग, ... featureFiveHyperEdge वर्ग} (जिसमें मैं जानता हूँ कि सुविधा प्रकार) यह कोड का एक दोहराव हो जाएगा के रूप में यह एक ही निकटतम पड़ोसियों खोज एल्गोरिथ्म

---

सुविधा = एक छवि का स्तर कम सुविधा (उदाहरण के लिए रंग हिस्टोग्राम) है
मैं निम्न स्तर के 5 प्रकार है सुविधा
मैं प्रत्येक को निकटतम नी खोजने के लिए उपयोग करूंगा मेरे वर्तमान छवि
सभी सुविधा का ighbors एक सरल शाब्दिक फ़ाइल
में स्टॉक कर रहे हैं एक ही एल्गोरिथ्म निकटतम पड़ोसियों खोज करने के लिए प्रयोग किया जाता है
केवल फ़ाइल हर बार

Answer 1

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

public class ImageImageHyperedge implements 
    HomogenousHyperedge<ImageVertex, Map<String,Instance>> { 

    private FeatureType featureType; 

    @Override 
    public List<ImageVertex> searchNearstNeighborsVertex(Hypergraph hypergraph, 
     ImageVertex vertex) { 
     return null; 
    } 
} 

Answer 2

ऐसा कुछ करने का प्रयास करें?

public abstract class BaseFeatureHyperEdge { 

    @Override 
    public List<ImageVertex> searchNearstNeighborsVertex(Hypergraph hypergraph, 
     ImageVertex vertex) { 
     // implement nearest neighbor search algorithm 
     // and call getFeatureType where you need it. 
     // This will allow you to have the search algorithm only in one place. 
     //But make the search based on the feature type; 
    } 

    protected FeatureType getFeatureType(); 
} 

public class FeatureOneHyperEdge extends BaseFeatureHyperEdge{ 

    @Override 
    protected FeatureType getFeatureType() { 
     return new FeatureTypeOne(); 
    } 
} 


public class FeatureTwoHyperEdge extends BaseFeatureHyperEdge{ 

    @Override 
    protected FeatureType getFeatureType() { 
     return new FeatureTypeTwo(); 
    } 
} 

शायद आप Template Method Pattern आज़मा सकते हैं?

Answer 3

आपका यूएमएल डिज़ाइन पर्याप्त नहीं है। बदसूरत & मुश्किल-पढ़ने-पढ़ने 'स्टाइल' छोड़ें, हमें 'वर्टेक्स' के साथ-साथ 'एज' और एक एसोसिएशन आरेख दिखाएं; विरासत का आपका (संभावित रूप से अधिक जटिल) विचार नहीं।

आपके एपीआई, डिजाइन & मौलिक प्रश्न वास्तव में स्पष्ट नहीं हैं।'हाइप्रेड' कक्षाएं एज के एक उदाहरण का प्रतिनिधित्व कर सकती हैं, और इसके दो सिरों को जोड़ती हैं; या वे (यदि बेहतर नामित) एक एज प्रकार का प्रतिनिधित्व कर सकते हैं, और एक निर्दिष्ट एंडपॉइंट पैरामीटर से वैश्विक रूप से ग्राफ को खोज सकते हैं।

ये पूरी तरह से अलग डिज़ाइन हैं, आपका प्रश्न तब तक व्यर्थ है जब तक कि आप ऊपर की ओर नहीं आते।

किसी भी तरह से, Edge.search() में सही हस्ताक्षर नहीं है। कहाँ वी.एस. और VE आरंभ और अंत शिखर-प्रकार के होते हैं, और TE किनारे प्रकार है, यह या तो होना चाहिए:

public class EdgeType { 
    public List<EV> getEndpoints (SV startVertex); 
} 

या

public class Vertex { 
    public List<TE> Vertex.getEdges(); 
} 
public class Edge { 
    public EV Edge.getEndpoint(); 
} 

निकटतम-पड़ोसी एल्गोरिथ्म सामान्य प्रकार का उपयोग कर लागू किया जाना चाहिए , और फिर कंक्रीट कक्षाओं द्वारा आवश्यक (सटीक प्रकार-हस्ताक्षर के साथ) कहा जाता है।

बीटीडब्ल्यू, जब आप "निकटतम पड़ोसी" का जिक्र करते हैं; न तो यह स्पष्ट है कि "निकटतम पड़ोसी" का अर्थ है सीधे जुड़े वर्टेक्स, जो छोटा है, या किसी निर्दिष्ट प्रकार के अक्षांश को दूर करने के लिए (दूरी माप कैसे है? आप निर्दिष्ट नहीं करते हैं) को खोजने के लिए।

किसी भी तरह, उपयोगिता & 'एज' के उपप्रकारों को लागू करने की शुद्धता/आवश्यकता स्पष्ट नहीं है। कई ग्राफ़ एल्गोरिदम दिलचस्प और उपप्रकार होने के लिए वर्टिसेस/नोड्स पाते हैं, लेकिन इन्हें किनारों के किनारों के उप-प्रकार (या उप-प्रकार की उपयोगिता) के बारे में पता नहीं है।

अंतिम युक्ति: जटिल नामकरण, KISS को हटा दें। 'वेरटेक्स' और 'एज' आपको एक स्पष्ट, सरल, समझदार & सही डिज़ाइन प्राप्त करने में मदद करेगा। के बाद के लिए अतिरिक्त शब्द सहेजें।

---

जवाब में Nawara से जानकारी आगे बढ़ाने के लिए:

तो यह एक EdgeType आप मॉडल किया है है और जब 'निकटतम पड़ोसी' पूछ आप एक प्रारंभ वर्टेक्स & वापसी या तो एज (रों) लेना चाहिए - अगर आपको दूरी मीट्रिक की आवश्यकता है - या वर्टिसेस।

'ग्राफ' का संदर्भ संभवतः वेरटेक्स पैरामीटर से निहित होना चाहिए।

जहां तक ​​आपकी एज टाइप विरासत विरासत: उपप्रकार & विरासत को व्यवहारिक विशेषताओं का पालन करने के लिए परिभाषित किया जाना चाहिए, न कि जेनेरिक प्रकार (वेरटेक्स प्रकार) जो वे संदर्भित करते हैं। ओओ कक्षा विरासत डिजाइन के लिए सिद्धांत कर रहा है, नहीं है।

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

उदाहरण के लिए।

IMAGE_IMAGE_EDGES = new KnnDistanceEdgeType<ImageVertex,ImageVertex>(ImageVertex.class, ImageVertex.class); 
TAG_TAG_EDGES = new FlickrDistanceEdgeType<TagVertex,TagVertex>(TagVertex.class, TagVertex.class); 
ANY_EDGES = new KnnDistanceEdgeType<Vertex,Vertex>(Vertex.class, Vertex.class); 

अगर वहाँ बहुत अन्य व्यवहार (हम किसी भी निर्धारित नहीं किया है, और भी बहुत कल्पना नहीं कर सकते) EdgeType में है, तो आप अलग वर्ग के लिए रवाना KNN- और फ्लिकर दूरी एल्गोरिदम को स्थानांतरित कर सकते हैं। शायद कोई ज़रूरत नहीं है।

याद रखें: ओओ में, व्यवहार के लिए उप-वर्ग, अस्तित्व के लिए नहीं। और मुझे एक +1 वोट दें!