2012-11-03 6 views
5

मैं एक संचार सॉफ्टवेयर लिख रहा हूं जो मेरे यूनी में नियंत्रण विभाग में प्रयोगशाला प्रक्रियाओं से बात करेगा। प्रक्रियाएं धारावाहिक बंदरगाह पर संचार करती हैं और थोड़ी सी जांच/हेरफेर होगी।क्या इस मामले में सार्वजनिक जावा क्लास के सदस्यों के लिए बुरा व्यवहार होगा?

public class Channel { 

    public enum Kind {DIGITAL_IN, DIGITAL_OUT, ANALOG_IN, ANALOG_OUT, COUNTER_IN}; 

    private int resolution; 
    private int number; 
    private Kind kind; 
    public byte[] bits; 

    public Channel(Kind kind, int resolution, int number) throws Exception { 
     if (resolution % 8 != 0) { 
      throw new Exception("Resolution must be divisible by 8"); 
     } 
     this.kind = kind; 
     this.resolution = resolution; 
     this.number = number; 
     this.bits = new byte[resolution/8]; 
    } 


    public int getResolution() { 
     return resolution; 
    } 

    public int getNumber() { 
     return number; 
    } 

    public Kind getKind() { 
     return kind; 
    } 
} 

मेरा प्रश्न अब अगर यह मेरी बाइट [] सार्वजनिक रूप में घोषित किया है करने के लिए इस मामले में बुरा व्यवहार पर विचार किया जाएगा है: मैं निम्नलिखित की तरह एक सहायक वर्ग में लिखा है? मेरी लैबप्रोसेप्रोटोकॉल कक्षा में मैं इन चैनल बिट्स तक पहुंचूंगा और सीरियल पोर्ट पर प्रक्रिया से जो कुछ प्राप्त करता हूं उसके अनुसार उन्हें बदल दूंगा।

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

अग्रिम धन्यवाद।

+0

मुझे लगता है कि यह CodeReview में होना चाहिए। – poitroae

उत्तर

8

ठीक है, सार्वजनिक क्षेत्रों के खिलाफ कोई पूर्ण प्रतिबंध नहीं है। अगर आपको लगता है कि यह सबसे अच्छा समाधान है, तो शर्मिंदा मत हो, इसे आगे बढ़ें।

उस ने कहा, रुको और जो आप पूरा करना चाहते हैं उसके बारे में सोचें। सबकुछ निजी बनाना अपने आप में एक लक्ष्य नहीं है - विचार को समझने और काम करने में आसान बनाने के लिए इनवेरिएंट स्थापित करना है।

तो विचार करें कि आप byte[] के साथ क्या करना चाहते हैं - अन्य लोग इस पर क्या संचालन करना चाहते हैं? इन परिचालनों के तरीकों के बारे में विचार करें, जो क्षेत्र को सार्वजनिक रूप से उजागर करने से समझना और साफ करना आसान होगा। साथ ही, विचार करें कि आप क्या करते हैं अनुमति देना चाहते हैं (वह वह हिस्सा होगा जो इनवेरिएंट स्थापित करता है)। उदाहरण के लिए, प्रत्यक्ष फ़ील्ड एक्सेस byte[] को अलग-अलग लंबाई के साथ बदलने की अनुमति देगा - शायद आप इसे रोकना चाहते हैं।

या शायद byte[] पर इतना कुछ होता है कि यह अपने (रैपिंग) वर्ग के योग्य है? यह सब इस बात पर निर्भर करता है कि इसका उपयोग कैसे किया जाता है।

समापन में, एक साधारण सार्वजनिक क्षेत्र से शुरू करने में कोई समस्या नहीं है। एक बार जब आप एक अधिक उचित समाधान प्राप्त कर लेते हैं, तो आप इसे बाद में हमेशा पुन: सक्रिय कर सकते हैं।

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

+0

धन्यवाद! वह सहायक था। यह निजी होगा। – evading

+0

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

+0

@AdriaanKoster: हाँ, अच्छा बिंदु। मैंने इसे अपने जवाब में जोड़ा। – sleske

2

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

+3

मुझे नहीं लगता कि केवल गेटर और सेटर सार्वजनिक क्षेत्र की तुलना में काफी बेहतर है - यह एक ही चीज़ पर उबाल जाता है। एकमात्र अपवाद एक सार्वजनिक एपीआई है, वहां इसके लायक हो सकते हैं। अन्यथा, यदि आप किसी क्षेत्र में पूर्ण पहुंच देना चाहते हैं, तो बस इसे सार्वजनिक बनाएं। यदि आपको बाद में इसे बदलने की आवश्यकता है, तो बस इस वर्ग के साथ उपयोग कक्षाओं को दोबारा दोहराएं। – sleske

3

आम तौर पर byte[] फ़ील्ड को private के रूप में छोड़ने और कक्षा के बाहर से क्षेत्र में हेरफेर करने के तरीकों को लागू करने की अनुशंसा की जाएगी। ऐसा नहीं है कि भयानक क्षेत्र को public (कम से कम इमो) के रूप में घोषित करने का अभ्यास है, लेकिन इसे private छोड़कर बाद में समस्याएं बच सकती हैं क्योंकि आप प्रोजेक्ट को विकसित/अपडेट करना जारी रखते हैं। मुझे लगता है कि this बताता है कि मेरा क्या मतलब है।

0

मुझे एपीआई से कार्यान्वयन को अलग करने की परवाह है। यदि आप चाहें, तो भविष्य में, जब आप Channel कक्षा के आंतरिक में कुछ बदल देंगे, तो अन्य कोड जो Channel एपीआई का उपयोग कर बिना संशोधनों के काम करने के लिए उपयोग कर रहे हैं, तो आप गेटर्स और सेटर्स का उपयोग करेंगे और private फ़ील्ड्स का उपयोग करेंगे। अन्य मामलों में आप public फ़ील्ड का उपयोग कर सकते हैं। लेकिन, ध्यान दें कि इन मामलों में भी bits फ़ील्ड का नाम और प्रकार कार्यान्वयन विवरण हैं। मेरी राय में आपके आंतरिक क्षेत्रों के नाम और प्रकार को अन्य वर्गों को प्रभावित नहीं करना चाहिए।

3

इसे निजी बनाएं, लेकिन केवल गेटर्स और सेटर्स का उपयोग न करें - उपयोगकर्ताओं को आपके bits सरणी का उपयोग कैसे करना चाहिए? क्या वे हमेशा पहले तत्व प्राप्त कर रहे हैं, या वे हमेशा इसके माध्यम से साइकिल चल रहे हैं? (ByteBuffer आपको यहां कुछ उपयोगी विचार दे सकता है, या शायद आपको ByteBuffer का उपयोग सीधे करना चाहिए।) उपयोगकर्ताओं को इसका उपयोग करने के तरीकों से इसे एक्सेस करने के तरीकों को प्रदान करें; केवल गेटर्स और सेटर्स प्रदान न करें।

0

फ़ील्ड्स को निजी बनाकर और एक्सेसर और संशोधक विधियों का उपयोग करके आप encapsulation नियम का पालन कर रहे हैं जो फ़ील्ड को आकस्मिक परिवर्तन से रोकता है और इस प्रकार अधिक गलती सहनशील अनुप्रयोग का विकास करता है।

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