2010-05-25 11 views
5

मेरे पास कुछ कोड है जो इस तरह दिखता है:मैं इस मामले में फीचर ईर्ष्या कैसे सही करूं?

class Parent { 
private Intermediate intermediateContainer; 
public Intermediate getIntermediate(); 
} 

class Intermediate { 
private Child child; 
public Child getChild() {...} 
public void intermediateOp(); 
} 

class Child { 
public void something(); 
public void somethingElse(); 
} 

class Client { 
private Parent parent; 

public void something() { 
    parent.getIntermediate().getChild().something(); 
} 

public void somethingElse() { 
    parent.getIntermediate().getChild().somethingElse(); 
} 

public void intermediate() { 
    parent.getIntermediate().intermediateOp(); 
} 
} 

मैं समझता हूं कि "फीचर ईर्ष्या" कोड गंध का एक उदाहरण है। सवाल यह है कि इसे ठीक करने का सबसे अच्छा तरीका क्या है? मेरा पहला वृत्ति माता-पिता पर तीन विधियों को रखना है:

parent.something(); 
parent.somethingElse(); 
parent.intermediateOp(); 

... लेकिन मुझे यह डुप्लीकेट कोड पसंद है, और माता-पिता वर्ग (जो पहले से ही व्यस्त है) के एपीआई को अव्यवस्थित करता है।

क्या मैं getIntermediate(), और/या getChild() के परिणाम को संग्रहीत करना चाहता हूं, और इन ऑब्जेक्ट्स में अपना खुद का संदर्भ रखना चाहता हूं?

+0

धन्यवाद! इन सभी उत्तरों में मददगार थे, इसलिए मैंने उन्हें – RMorrisey

उत्तर

5

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

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

जब आप अंत में महसूस करते हैं कि "समस्याएं" क्या हैं, तो समाधान लागू करने के लिए इतना आसान नहीं हो सकता है। यह एक बमर है, लेकिन वैसे भी अच्छी लड़ाई जारी रखें और उस समाधान की प्रतिक्रिया दें!

+1

से ऊपर उठाया, मुझे एहसास हुआ कि मेरे मामले में, चाइल्ड (मेरे यूआई घटक के लिए डेटासोर्स) को अपने मूल घटक द्वारा स्वामित्व या प्रबंधित करने की आवश्यकता नहीं थी, और वह पूरी तरह से माता-पिता से संबंधित था मैंने क्लाइंट में उसका उपयोग शुरू किया (समानांतर में काम कर रहे एक और यूआई घटक)। मैंने बच्चे के निर्माण को एक उच्च वर्ग तक खींच लिया जो माता-पिता और ग्राहक दोनों का मालिक है, और इसे दोनों में पारित कर दिया। – RMorrisey

10

यह बिल्कुल फ़ीचर ईर्ष्या नहीं है, लेकिन इन वर्गों के बीच उच्च युग्मन समस्या और डेमेटर http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html के कानून का एक निश्चित उल्लंघन है। माता-पिता पर सीधे तरीके रखने का आपका पहला विचार अच्छा है। ग्राहकों को इस तरह के ढेर के माध्यम से कॉल करने की आवश्यकता नहीं है।

यदि आप माता-पिता के बारे में चिंतित हैं, तो शायद आप वहां बहुत अधिक कार्यक्षमता रखते हैं और इसे कुछ छोटे वर्गों में विभाजित किया जाना चाहिए। कक्षाएं अकेले जानी चाहिए।

3

Client पर कौन पहुंच रहा है? क्या आपको parent निजी रखने की आवश्यकता है, या आप इसे बेनकाब करना चाहिए ताकि कॉलिंग कोड उस स्थान पर जा सके जहां आवश्यक सुविधाएं हैं?

यदि आप parent को पूरी तरह से उजागर करने के बारे में चिंतित हैं, तो दूसरा विकल्प Parent से इंटरफ़ेस निकालने और Client से इसका खुलासा करना है।

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