सर्वोत्तम अभ्यास: वर्ग की परिभाषा के भीतर सार्वजनिक / संरक्षित / निजी का आदेश?

Question

मैं जमीन से एक नया प्रोजेक्ट शुरू कर रहा हूं और यह चाहता हूं कि इसमें साफ-सुथरी / अच्छे कोडिंग मानक हों। यहाँ किस क्रम पर अनुभवी डेवलपर्स एक वर्ग के भीतर चीजों को रखना पसंद करते हैं?

A: 1) सार्वजनिक विधियाँ 2) निजी विधियाँ 3) सार्वजनिक संस्करण 4) निजी संस्करण

बी: १) सार्वजनिक संस्करण २) निजी संस्करण ३) सार्वजनिक तरीके ४) निजी तरीके

C: 1) सार्वजनिक संस्करण 2) सार्वजनिक विधियाँ 3) निजी विधियाँ 4) निजी संस्करण

मैं आमतौर पर सार्वजनिक स्थैतिक संस्करण सबसे ऊपर रखना चाहता हूं, लेकिन फिर क्या कोई सार्वजनिक स्थैतिक विधि आपके निर्माता के आगे सूचीबद्ध की जाएगी, या निर्माणकर्ता को हमेशा पहले सूचीबद्ध किया जाना चाहिए? इस तरह की चीज...

मुझे पता है कि यह बहुत ही कठिन है लेकिन मैंने सोचा: इसके लिए सबसे अच्छे अभ्यास क्या हैं?

PS: नहीं, मैं Cc # का उपयोग नहीं करता। मुझे पता है। मैं एक लुडित हूँ।

Comments

C # का उपयोग नहीं करने के साथ कुछ भी गलत नहीं है। मैंने कभी भी एक पेशेवर डेवलपर के रूप में अपने सभी वर्षों में सी # का सिलाई नहीं लिखा है। कार्य के लिए जो भी भाषा उपयुक्त हो उसका उपयोग करें, और जो कुछ भी अलग-अलग कहता है, उसे बताएं जहां वे इसे ले जा सकते हैं!

— ईथर

के संभावित डुप्लिकेट stackoverflow.com/questions/150479/...

— माइकल Freidgeim

Answer 1

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

Comments

मुझे भी जोड़ने का सौभाग्य मिला है: पाने वाले / बसने वाले। यह कक्षाओं को कम तेज़ महसूस करने में मेरी मदद करता है।

— डीन जे

सदस्य चर के ठीक बाद, शीर्ष पर कंस्ट्रक्टर्स। ओओपी में, निष्पादन वस्तु की तात्कालिकता से शुरू होता है।

— असफ़

पाठक को कोड के इर्द-गिर्द कूदने के कारण संभवतः निजी तरीकों के सभी बारीकियों को पढ़ने के लिए पाठक को मजबूर करने के साथ संतुलित करने की आवश्यकता है। अखबार रूपक शायद इस बात को गलत समझ रहा है कि आपकी सार्वजनिक विधियाँ मोटे तौर पर आपकी कक्षा का प्रतिनिधित्व करती हैं, और आपके निजी तरीके विवरणों की आपूर्ति करते हैं (लगभग एक फुटनोट की तरह जिसे आप संदर्भित कर सकते हैं यदि आपको ज़रूरत है)।

— केनी हंग

मैं उलझन में हूं। आपने कहा: (सबसे पहले, फिर निजी सदस्य) । ठीक है। फिर जनता के सदस्य कहां जाते हैं?

— हनी

@ वे स्थिरांक और निजी सदस्यों के ठीक बाद जाएंगे। तो यह निम्नलिखित क्रम में होगा: लगातार, निजी सदस्य, सार्वजनिक सदस्य।

— पियरे जिलेट

Answer 2

सबसे अच्छा अभ्यास सुसंगत होना है ।

व्यक्तिगत रूप से, मैं publicपहले तरीकों को रखना पसंद करता हूं , उसके बाद protectedतरीकों को, विधियों द्वारा पालन करना private। सदस्य डेटा हमेशा निजी या संरक्षित होना चाहिए, जब तक कि आपके पास ऐसा न करने का एक अच्छा कारण है।

publicशीर्ष पर तरीकों को रखने के लिए मेरा तर्क यह है कि यह आपकी कक्षा के लिए इंटरफ़ेस को परिभाषित करता है , इसलिए आपकी हेडर फ़ाइल को भ्रमित करने वाला कोई भी व्यक्ति इस जानकारी को तुरंत देख सकता है।

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

Comments

LeopardSkikPBH, मैं पूरी तरह से सहमत हूँ ... जो समझ में आता है! मुझे लगता है कि मैं उलझन में हूँ कि क्या भीतर, var या funcs पूर्वता लेते हैं। धन्यवाद!

— tempname

मैं इस बात से सहमत नहीं हूं कि सबसे अच्छा अभ्यास सुसंगत होना है। लगातार अपठनीय, अचूक कोड लिखने के कई तरीके हैं।

— जेसन

@ जेसन यह कहने की तरह है कि सड़क के किनारे पर रहना सबसे अच्छा अभ्यास नहीं है क्योंकि आप अभी भी वहां दुर्घटनाएं कर सकते हैं।

— रेक्स एम

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

— तेंदुएकिनपिलबॉक्सबॉक्स 4

@Rex M: नहीं, मैंने जो कहा, वह आपकी व्याख्या के बिल्कुल समान नहीं है। मेरा कहना है कि केवल सुसंगत होना इस मामले में एक मजबूत तर्क नहीं है। कुछ मामलों के लिए स्थिरता ठीक है (उदाहरण के लिए, ब्रेसिज़ की नियुक्ति)। लेकिन यहां विकल्प वास्तव में कोड की पठनीयता को प्रभावित करते हैं। इस प्रकार, स्थिरता की तुलना में मजबूत एक तर्क की आवश्यकता है।

— जेसन

Answer 3

मुझे लगता है कि इस पर मेरा सबसे अलग दर्शन है। मैं एक साथ संबंधित आइटम समूह करना पसंद करता हूं। मैं एक वर्ग के साथ काम करने के लिए इधर-उधर कूदने के लिए नहीं खड़ा हो सकता कोड को एक्सेसिबिलिटी (सार्वजनिक, निजी, संरक्षित इत्यादि) या उदाहरण के आधार पर स्थिर या सदस्य बनाम प्रॉपर्टी बनाम फ़ंक्शन के आधार पर प्रवाहित और उपयोग करना चाहिए। यह एक अच्छा प्रवाह रखने में मदद नहीं करता है। इसलिए अगर मैं एक सार्वजनिक विधि Methodको लागू करता हूं जिसे निजी सहायक विधियों आदि द्वारा कार्यान्वित किया जाता है HelperMethodA, HelperMethodBतो फाइल में एक दूसरे से अलग होने के बजाय ये विधि है, मैं उन्हें एक-दूसरे के करीब रखूंगा। इसी तरह, अगर मेरे पास एक इंस्टेंस मेथड है जिसे स्टैटिक मेथड द्वारा कार्यान्वित किया जाता है, तो मैं इन्हें भी एक साथ समूहीकृत करूँगा।

इसलिए मेरी कक्षाएं अक्सर इस तरह दिखती हैं:

class MyClass {
    public string Method(int a) {
        return HelperMethodA(a) + HelperMethodB(this.SomeStringMember);
    }

    string HelperMethodA(int a) { // returns some string }

    string HelperMethodB(string s) { // returns some string }

    public bool Equals(MyClass other) { return MyClass.Equals(this, other); }

    public static bool Equals(MyClass left, MyClass right) { // return some bool }

    public double SomeCalculation(double x, double y) {
        if(x < 0) throw new ArgumentOutOfRangeException("x");
        return DoSomeCalculation(x, y); 
    }

    const double aConstant;
    const double anotherConstant;
    double DoSomeCalculation(double x, double y) {
        return Math.Pow(aConstant, x) * Math.Sin(y) 
            + this.SomeDoubleMember * anotherConstant;
    }       
}

Answer 4

व्यक्तिगत रूप से मुझे शीर्ष पर सार्वजनिक, संरक्षित और फिर निजी रहना पसंद है। इसका कारण यह है कि जब कोई व्यक्ति शीर्ष लेख को खोलता है तो वह देखता है कि वह पहले क्या एक्सेस कर सकता है, फिर अधिक विवरण के रूप में वह नीचे स्क्रॉल करता है।

इसका उपयोग करने के लिए किसी वर्ग के कार्यान्वयन विवरणों को नहीं देखना चाहिए, फिर वर्ग डिजाइन अच्छी तरह से नहीं किया गया है।

Answer 5

मुझे बहुत परवाह थी। पिछले कई वर्षों में आधुनिक IDEs का उपयोग करके सब कुछ केवल 1 या 2 कीस्ट्रोक्स से दूर है, मैंने अपने मानकों को काफी हद तक आराम करने दिया है। अब, मैं स्टैटिक्स, सदस्य चर के साथ शुरू करता हूं, फिर कंस्ट्रक्टर उसके बाद मैं इसके बारे में ज्यादा चिंता नहीं करता हूं।

C # में मैं Resharper को अपने आप चीजों को व्यवस्थित करने देता हूं।

Comments

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

— फिलिप नगन

Answer 6

यह मेरा आदेश होगा

1. स्थैतिक चर
2. स्थैतिक तरीके
3. सार्वजनिक चर
4. संरक्षित चर
5. निजी चर
6. कंस्ट्रक्टर्स
7. सार्वजनिक तरीके
8. संरक्षित तरीके
9. निजी तरीके

मैं निम्नलिखित नियमों का उपयोग करता हूं:

• किसी चीज से पहले स्थिर
• तरीकों से पहले निर्माणकर्ताओं से पहले चर (मैं निर्माणकर्ताओं को तरीकों की श्रेणी में मानता हूं)
• निजी से पहले संरक्षित सार्वजनिक

विचार यह है कि आप व्यवहार (विधियों) से पहले वस्तु (डेटा) को परिभाषित करते हैं। स्टैटिक्स को अलग करने की आवश्यकता है क्योंकि वे वास्तव में ऑब्जेक्ट का हिस्सा नहीं हैं, न ही यह व्यवहार है।

Comments

शुक्रिया बरकमाडले ... यह दिलचस्प है! कि आप कंस्ट्रक्टर से पहले 4 और 5 डालेंगे। मैं निश्चित रूप से उस बारे में

— सोचूंगा

इस आदेश की तरह हालांकि शीर्ष के पास स्थैतिक विधियां दिलचस्प हैं। मैं एक डेवलपर कि तल पर निजी चर शब्दों में कहें, मैं विचार देख सकते हैं के साथ काम किया है, लेकिन यह सही महसूस नहीं किया था

— कार्लटन

Answer 7

मैं आम तौर पर सार्वजनिक, संरक्षित, निजी आदेश के साथ-साथ स्थिर डेटा, सदस्य डेटा, सदस्य कार्यों के आदेश से सहमत हूं।

हालांकि मैं कभी-कभी सदस्यों (गेटर्स एंड सेटर) की तरह समूह बनाता हूं, मैं आम तौर पर एक समूह ALPHABETICALLY के भीतर सदस्यों को सूचीबद्ध करना पसंद करता हूं ताकि वे अधिक आसानी से स्थित हो सकें।

मुझे डेटा / फ़ंक्शन को लंबवत रूप से अस्तर करना भी पसंद है। मैं दाईं ओर टैब / स्पेस को पर्याप्त बनाता हूं ताकि सभी नाम एक ही कॉलम में संरेखित हों।

Comments

हे - मेरे अपने दिल के बाद एक 'टैब-स्पेसर'! :-) मैं जुनूनी बाध्यकारी नहीं हूँ। ईमानदार मैं नहीं हूँ!

— tempname

Answer 8

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

मेरा लेना यह है कि प्रोग्रामर के लिए यह जानना अधिक महत्वपूर्ण है कि कक्षा के लिए क्या डिज़ाइन किया गया था, और यह कैसे व्यवहार किया जा सकता है।

इसलिए, यदि यह एक सिंगलटन है, तो मैंने पहले शब्दार्थ (स्थिर getInstance () वर्ग) को रखा।

यदि यह एक ठोस कारखाना है, तो मैं पहले गेटन्यू () फ़ंक्शन और रजिस्टर / इनिशियलाइज़ फ़ंक्शन करता हूं।

... और इसी तरह। जब मैं पहली बार कहता हूं, तो मेरा मतलब है कि जल्द ही c'tors और d'tor के बाद से - क्योंकि वे किसी भी वर्ग को तत्काल करने का डिफ़ॉल्ट तरीका हैं।

इसके बाद होने वाले कार्य इस प्रकार हैं:

1. लॉजिकल कॉल-ऑर्डर (उदा। इनिशियलाइज़ करें), प्रीप्रोसेस (), प्रोसेस (), पोस्टप्रोसेस ()), या
2. एक साथ संबंधित कार्य (जैसे एक्सेसर्स, यूटिलिटीज, मैनिपुलेटर्स आदि),

इस पर निर्भर करता है कि वर्ग का मुख्य रूप से कुछ कार्यों के साथ डेटा-स्टोर होना था या कुछ डेटा सदस्यों के साथ फ़ंक्शन प्रदाता।

Answer 9

कुछ संपादकों, जैसे एक्लिप्स और इसके वंश, आपको आउटलाइन को फिर से देखने के लिए अनुमति देते हैं, जैसे कि चर और तरीके, वर्णानुक्रम में या पृष्ठ के रूप में।

Answer 10

संरक्षित और निजी के बाद सार्वजनिक होने का क्रम मेरे लिए अधिक पठनीय है, हेडर फ़ाइल के शीर्ष पर टिप्पणियों में वर्ग तर्क का वर्णन करना बेहतर है बस कॉल करें और यह समझने के लिए कॉल ऑर्डर करें कि कक्षा की खुराक और एल्गोरिदम अंदर क्या उपयोग करते हैं।

मैं कुछ समय के लिए क्यूटी सी ++ का उपयोग कर रहा हूं और कुछ नए तरह के कीवर्ड देख रहा हूं signalऔर slotमैं ऊपर दिए गए आदेश को जारी रखना पसंद करता हूं और यहां अपने विचार साझा करता हूं।

#ifndef TEMPLATE_H
#define TEMPLATE_H


class ClassName
{
    Q_OBJECT
    Q_PROPERTY(qreal startValue READ startValue WRITE setStartValue)
    Q_ENUMS(MyEnum)

public:

    enum MyEnum {
        Hello = 0x0,
        World = 0x1
    };

    // constructors

    explicit ClassName(QObject *parent = Q_NULLPTR);
    ~ClassName();

    // getter and setters of member variables

    // public functions (normal & virtual) -> orderby logic

public slots:

signals:

protected:

    // protected functions it's rule followed like public functions


private slots:

private:

    // methods

    // members

};

#endif // TEMPLATE_H