आप आम तौर पर एक वर्ग के क्षेत्रों को कैसे लेआउट करते हैं?

17

मैं सोच रहा था कि क्या एक वर्ग के क्षेत्रों को बिछाने के लिए एक मानक था।

मैं वर्तमान में उपयोग करता हूं

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldsनिजी गुण और Propertiesसार्वजनिक होने के नाते। यदि आवश्यक हो, तो मैं सामान्य रूप से उप-भाग का उपयोग करूँगा या कभी-कभी नीचे अन्य क्षेत्रों (जैसे इंटरफ़ेस या बेसक्लास सदस्य) को जोड़ दूँगा।

.net programming-practices

— राहेल
स्रोत

1

क्या आप सामान्य रूप से लेआउट के बारे में बात कर रहे हैं या "# भाग" का उपयोग कर रहे हैं?

— Snmcdonald

1

@snmcdonald मैं #regionएक खंड को परिभाषित करने के लिए टैग का उपयोग करता हूं

— राहेल

यह एक समुदाय विकी सवाल नहीं होना चाहिए? मेरा मानना है कि एक मानक नहीं है, और भाषाओं के आधार पर उत्तर बदल सकता है।

— रवलीन

7

मैं सभी #regions

— एड एस।

3

@Ed S. +1 क्योंकि क्षेत्र शैतान हैं। वे सभी आपको ऐसा करने की अनुमति देते हैं कि इस तथ्य को अस्पष्ट किया जाए कि आपकी कोड फ़ाइल बहुत बड़ी है और इसे फिर से तैयार करने की आवश्यकता है।

— मैटवेवी

4

वर्ग-संबंधित एनम या कभी-कभी संरचना / शुद्ध-डेटा कक्षाएं (वास्तविक वर्ग परिभाषा के ऊपर)

--- कक्षा परिभाषा ---

निजी सदस्य

CTORs / DTORs अगर भाषा में DTORs हैं

सार्वजनिक गुण

उपयोगिता विधियाँ (छोटे दायरे वाली निजी या संरक्षित विधियाँ)

कक्षा की कार्यक्षमता (वर्ग के क्षेत्र के आधार पर कई क्षेत्रों में विभाजित की जा सकती है)।

— पैक्स नोक्टिस
स्रोत

17

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

— एमआईए
स्रोत

2

मैं अभी WPF में प्रोग्रामिंग कर रहा हूं और कुछ उपखंडों का एक उदाहरण जो मैं उपयोग करूंगा, एक ViewModel है, जिसके सार्वजनिक गुण UI-संबंधित गुणों, कमांड, डेटा, आदि में विभाजित हैं। यह बहुत आसान है जो मुझे मिल रहा है। जल्दी की तलाश में

— राहेल

2

क्यों नहीं क्षेत्रों के बजाय बड़े टिप्पणी बैनर का उपयोग करें? // ----------ViewModel Properties---------- इस तरह आप अभी भी कोड देख सकते हैं (या इसे रूपरेखा के साथ संक्षिप्त कर सकते हैं और सदस्यों को देख सकते हैं)। क्षेत्र चीजों को छिपाने के लिए हैं। कोड को तब तक छिपाया नहीं जाना चाहिए, जब तक कि यह ऑटोजेनरेटेड या कुछ और न हो।

— क्युरेलसा

1

@ राचल एहसान रचना।

— मैटवेवी

10

मैं सिर्फ इस बात की पुष्टि करना चाहता था कि आपका "# भाग" है और सामान्य रूप से वर्ग लेआउट नहीं है।

मुझे आश्चर्य है कि किसी ने भी क्षेत्रों का उपयोग करने से बचने का उल्लेख नहीं किया है। मैं समझता हूं कि ओपी क्षेत्रों को बाहर करने के बारे में एक सर्वेक्षण करना चाहता है, लेकिन मैं एक वैकल्पिक दृश्य बिंदु उठाना चाहूंगा।

मैं क्षेत्रों से बचता हूं। मैं उस कोड को देखना पसंद करता हूं जिसके साथ मैं काम कर रहा हूं। यदि आपको यह खोजना मुश्किल है कि आप क्या खोज रहे हैं तो कोड फोल्डिंग का उपयोग करें और समूह समान वर्ग निर्माण एक साथ करें।

मुझे क्षेत्रों से नफरत क्यों है? CTRL+M,Lऔर CTRL+M,Oकोड तह टॉगल करेगा। हालांकि, ढहने पर यह पूरे क्षेत्र को छिपा देता है। मुझे केवल तरीकों / संपत्तियों / टिप्पणियों को गिराने की आवश्यकता है।

यदि बहुत सारे क्षेत्र हैं, तो शायद एक कोड गंध है और आपका वर्ग बहुत अधिक काम कर रहा है। जेफ एटवुड क्षेत्रों पर एक अच्छा पद प्रदान करता है जो पढ़ने लायक है।

# भाग पर मेरा पसंदीदा उद्धरण:

नहीं, मैं # वर्णनों का उपयोग नहीं करूंगा। और नहीं, मैं शर्तों के साथ नहीं है। चुप रहो।

- जेफ एटवुड

कहा जा रहा है, मुझे पता है कि कई प्रोग्रामर उनका उपयोग करने पर जोर देते हैं। यह प्रश्न एक व्यक्तिपरक है। मैंने सोचा था कि मैं एक विकल्प प्रदान करूंगा।

— snmcdonald
स्रोत

1

यहाँ एक मैक्रो-टू-डेफिनिशन है, लेकिन क्षेत्रों का विस्तार करें, यदि आप ऐसे क्षेत्रों से जुड़े लोगों के साथ काम कर रहे हैं: stackoverflow.com/questions/523220/awesome-visual-studio-macros/ ... यह अच्छी तरह से काम करता है तो आप वास्तव में बीमार लोगों के साथ काम करना जो क्षेत्रों को तरीकों के अंदर रखते हैं ।

— Kyralessa

एक बहुत उपयोगी मैक्रो! मुझे यकीन नहीं है कि उन्होंने इसे दृश्य स्टूडियो में क्यों नहीं बनाया, कोई भी कम नहीं है, धन्यवाद।

— Snmcdonald

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

— कोडेक्सअर्बनम

4

यह भाषा से भाषा में भिन्न होता है। चूंकि मैं डेल्फी कोडर हूं, मैं डेल्फी मानक सम्मेलन का पालन करता हूं, जो इस तरह दिखता है:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

मुझे यह जानकारी व्यवस्थित करने का एक अच्छा तरीका है जो पढ़ने और समझने में आसान है।

— मेसन व्हीलर
स्रोत

3

मुझे यह बहुत आश्चर्यजनक लगता है कि निजी, संरक्षित, सार्वजनिक और प्रकाशित दोनों को वर्णानुक्रम और encapsulationally आदेश दिया गया है और वे सभी P से शुरू होते हैं!

— पीटर टर्नर

मनोरंजक, मैं नहीं। मैंने हमेशा पाया है कि publicपहले सूचीबद्ध करना अधिक स्वाभाविक था , क्योंकि अधिकांश उपयोगकर्ता केवल publicसामान की परवाह करते हैं ।

— मैथ्यू एम।

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

— S.Robins

3

मैं उन्हें निम्न तरीके से रखना चाहता हूं:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

ऐसी भाषा का उपयोग नहीं किया गया है, जिसका उपयोग Propertiesइसलिए किया जाता है ताकि वे रखी न हों। मैं निजी तरीकों और क्षेत्रों को सबसे नीचे रखता हूं क्योंकि यदि कोई अन्य व्यक्ति अपने कोड में इस फ़ाइल का उपयोग कर रहा है, तो उन्हें केवल एपीआई के साथ खुद को चिंता करने की आवश्यकता है, जो कि सार्वजनिक सामान है। और मेरे द्वारा ज्ञात सभी पाठ संपादक, और यहां तक कि आईडीई भी, फाइलों को खोलते समय सबसे ऊपर कर्सर सेट करता है।

— gablin
स्रोत

निजी क्षेत्रों को नीचे रखने के लिए +1। मैं सार्वजनिक तरीकों को उनके द्वारा लागू किए गए इंटरफ़ेस द्वारा समूहित करता हूं, और उन लोगों को डाल देता हूं जो किसी भी इंटरफ़ेस को शीर्ष पर लागू नहीं करते हैं, ठीक निर्माणकर्ताओं / विध्वंसक के बाद।

— सोज़ेरड

2

यह मेरे लिए एक निर्णय कॉल है। जब वे पठनीयता के लिए आवश्यक होते हैं तो मैं क्षेत्रों का उपयोग करता हूं।

मैं अपने दृश्य स्टूडियो रंग योजना (वर्तमान में एक गहरे लाल) में एक अलग रंग का उपयोग करता हूं ताकि उन्हें बाकी कोड से बाहर खड़ा किया जा सके।

एक उदाहरण जहां मैं एक # भाग का उपयोग कर सकता हूं: यदि मैं एक इकाई परीक्षण के लिए एक परीक्षण विधि लिखता हूं जिसमें XML की बहु-पंक्ति स्निपेट की आवश्यकता होती है, तो XML स्ट्रिंग सामान्य इंडेंटेशन को तोड़ देगा (क्योंकि यह बाएं हाथ के मार्जिन के साथ शुरू होता है) कोड विंडो। कुरूपता को छिपाने के लिए, मैं इसे एक # भाग में लपेटूंगा, ताकि मैं इसे ध्वस्त कर सकूं।

— रॉबर्ट हार्वे
स्रोत

2

बॉब मार्टिन की क्लीन कोड पुस्तक पूरे 5 वें अध्याय को प्रारूपण के लिए समर्पित करती है। कुछ महत्वपूर्ण बिंदु हैं जो मुझे अच्छी तरह से संक्षेप में बताते हैं।

दृश्यता और स्वच्छता द्वारा समूह चर और विधियों के अधिकांश प्रयास बहुत मायने नहीं रखते हैं, और आपको कोड को बहुत अधिक नेविगेट करने का कारण बनाते हैं।
उन तरीकों को रखना जो एक दूसरे को लंबवत रूप से कॉल करते हैं, आपके द्वारा किए जाने वाले नेविगेशन की मात्रा कम कर देता है, और चीजों को ढूंढना आसान बनाता है।
यदि आप को रोकना है और सोचना है कि "किस क्षेत्र में यह बिट कोड है?" हर कुछ मिनट।
उदाहरण चर आमतौर पर कुछ ही होने चाहिए, और हर जगह इस्तेमाल होने की संभावना है, इसलिए वे उस वर्ग के शीर्ष पर हैं जहां उन्हें पता लगाना आसान होगा। चर और घोषणाएं जो केवल एक विधि द्वारा उपयोग की जाएंगी, उस विधि के अंदर मौजूद होना चाहिए। यदि केवल कुछ तरीकों द्वारा उपयोग किया जाता है, तो उन्हें लंबवत रूप से बंद होना चाहिए, लेकिन उन कुछ तरीकों से ऊपर जो उनका उपयोग कर रहे हैं।

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

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

— S.Robins
स्रोत

1

+1 - मुझे आश्चर्य है कि इसका उल्लेख अधिक प्रमुखता से नहीं किया गया था। सामंजस्य का सिद्धांत इस बात पर भी लागू होता है कि आप अपने कोड को कैसे लागू करते हैं, और पहुंच संशोधक द्वारा समूहीकृत करना (अधिक बार नहीं) काउंटर उत्पादक है।

— डेनियल बी

0

मैं वर्तमान में इस तरह की लेआउट कक्षाएं:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

और फिर प्रत्येक घोषणा तक पहुंच स्तर उपसर्ग (जैसे, कभी-कभी समूह द्वारा पहुंच)। मैं पहुँच द्वारा शीर्ष स्तर की समूहीकरण करता था, लेकिन कुछ बिंदुओं पर, मुझे नहीं पता कि कब, यह ऊपर और साथ ही साथ काम नहीं करता था। उदाहरण के लिए C ++ / CLI (जो मैं इस समय उपयोग करने के लिए मजबूर हूं :-() आप ऐसा कर सकते हैं, जो समूहीकरण-अप तक को गड़बड़ कर देता है:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

— Skizz
स्रोत

नीचे "सदस्य" क्या हैं? मेरे लिए यह एक वर्ग के सभी टुकड़ों के लिए एक शब्द है।

— मेसन व्हीलर

@ मेसन: भ्रम से बचने के लिए "सदस्य चर" होना चाहिए।

— स्किज़

मैं वास्तव में उस तरह की चीजों को समूहीकृत नहीं करता। एक विधि और एक संपत्ति के बीच वास्तव में क्या अंतर है? मैं कभी भी एक वर्ग के गुणों की तलाश में नहीं गया हूं, फिर भी मैं तार्किक रूप से संबंधित कोड की तलाश करूंगा, चाहे वे गुण, तरीके, जो भी हों।

— एड एस।

0

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

— व्याट बार्नेट
स्रोत

0

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

क्षेत्रों का एक उपयोग जो मुझे स्वीकार्य लगता है वह है "अपरिहार्य रूप से बदसूरत" कोड को छिपाना; कोड जो विशिष्ट कार्यान्वयन विवरणों से संबंधित है, जो वर्तमान मानकों के लिए आंतरिक रूप से अच्छी तरह से स्थापत्य नहीं हो सकते हैं। यह आमतौर पर उन्नत, गूढ़ कोड है जिसे आम तौर पर एक बार लिखे जाने वाले औसत जूनियर प्रोग्रामर द्वारा गड़बड़ नहीं किया जाना चाहिए। ये चीजें हैं:

कुछ बिल्ट-इन इंटरफ़ेस कार्यान्वयन (आईडीआईएसओप्रोवेबल, IConvertible, कभी-कभी IEnumerable या IComparable क्योंकि उन्हें जेनेरिक और गैर-जेनेरिक कार्यान्वयन की आवश्यकता होती है)
एंबेडेड पी / चालान और संबंधित संरचनाएं।
फाइनल / विध्वंसक
अनवांटेड मेमोरी / पॉइंटर्स / "असुरक्षित" कोड को हुक।

— Keiths
स्रोत