डिजाइन सिद्धांत, सी के लिए सर्वश्रेष्ठ अभ्यास और डिजाइन पैटर्न (या सामान्य रूप से प्रक्रियात्मक प्रोग्रामिंग)? [बन्द है]

Question

क्या कोई ज्ञात डिजाइन सिद्धांत, सर्वोत्तम प्रथाओं और डिजाइन पैटर्न हैं जो एक सी परियोजना को डिजाइन करते समय पालन कर सकते हैं? या सामान्य रूप में प्रक्रियात्मक (अनिवार्य) प्रोग्रामिंग के लिए उपयोगी डिजाइन सिद्धांत?

(मैं 'ऑब्जेक्ट-ओरिएंटेड जनरेशन' का बच्चा हूं और पहली बार एक बड़ी सी परियोजना तैयार करनी है)

Comments

आप इस प्रश्न के लिए

— awsers

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

— डिमी

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

— dmckee --- पूर्व-संचालक बिल्ली

मैं आपके पूर्वव्यापी दृष्टिकोण को साझा नहीं कर सकता क्योंकि मेरे क्षेत्र में सिर्फ मेरे पैर मिलते हैं, लेकिन मैं आपके सुझाव को स्वीकार करता हूं। अपने आप को अधिक स्पष्ट रूप से व्यक्त करने के लिए धन्यवाद, एक अनुभवी व्यक्ति के विचार को पढ़ने के लिए हमेशा महान मूल्य। मैं वास्तव में आपके योगदान की सराहना करता हूं।

— डिमी

एसईआई सीईआरटी सी कोडिंग मानक नियमों और सामान्य अच्छी प्रथाओं का अच्छा सेट प्रदान करता है और साथ ही उन चीजों का उपयोग करने से बचने की कोशिश करनी चाहिए।

— रामी

Answer 1

जानकारी छिपाना - Parnas ( सॉफ्टवेयर बुनियादी बातों ) द्वारा जासूसी के रूप में ।

हेडर और दृश्यता का सावधानीपूर्वक प्रबंधन:

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

• हेडर स्व-सुरक्षित है - इसलिए यह मायने नहीं रखता है कि क्या यह कई बार शामिल है।

  #ifndef HEADER_H_INCLUDED
  #define HEADER_H_INCLUDED
  ...rest of header contents, including other #include lines if necessary
  #endif /* HEADER_H_INCLUDED */
  

• 'ऑब्जेक्ट' (आमतौर पर संरचनाएं) पर काम करने के लिए फ़ंक्शंस के डिज़ाइन सेट - और कोड का उपयोग करने वाले कोड में संरचना के इनर के चारों ओर प्रहार करने के बजाय उन कार्यों का उपयोग करें। इसे आत्म-थोपना समझें।

Comments

अच्छी बात है, धन्यवाद, जोनाथन। सार डेटा प्रकार उपयोग और कार्यान्वयन (ज्ञात बाहरी इंटरफ़ेस और अज्ञात आंतरिक कार्यान्वयन) के स्वच्छ पृथक्करण के साथ छुपाने वाली जानकारी का एक और अच्छा उदाहरण है।

— दीमी

Answer 2

मेरी तीन सलाह:

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

यहाँ एक उदाहरण है:

typedef struct Vector {
  int size;
  int limit;
  int* ints; 
} Vector;

Vector* Vector_new() {
  Vector* res = (Vector*) malloc(sizeof(Vector));
  res->limit = 10;
  res->size = 0;
  res->ints = (int*) malloc(sizeof(int) * res.limit);

  return res;
}


void Vector_destroy(Vector* v) {
  free(v->ints);
  free(v);
}

void Vector_add(Vector* v, int n) {
  if(v->size == v->limit) {
    v->limit = v->limit * 2 + 10;
    v->ints = realloc(v->ints, v->limit);     
  }

  v->ints[v->size] = n;
  ++v->size;
}

int Vector_get(Vector* v, int index) {
  if(index >= 0 && index < v->size)
    return v->ints[index];

  assert false;
}

Comments

धन्यवाद, Itay। मैं आपकी सलाह मानूंगा।

— दीमी

4. का परिणाम मत डालो malloc।

— एसएस ऐनी

Answer 3

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

यदि आपकी परियोजना सुरक्षा-महत्वपूर्ण है, तो MISRA-C नियमों का एक अच्छा समूह है। यह ज्यादातर एम्बेडेड सी के लिए अभिप्रेत है, लेकिन यह अन्य क्षेत्रों में भी उपयोगी हो सकता है।

मैं खुद को एक OO कोडर मानता हूं, और मैं एम्बेडेड-सी के साथ बहुत काम करता हूं। सबसे अच्छी सलाह जो मैं दे सकता हूं, खासकर बड़ी परियोजनाओं के लिए, यह अति नहीं है। ANSI C के शीर्ष पर एक पूर्ण OO ढांचा बनाना बहुत लुभावना हो सकता है, लेकिन इसे ठीक करने में बहुत समय और प्रयास लगता है। आपके द्वारा प्राप्त की जाने वाली कट्टरता, जितना अधिक समय आप वास्तविक परियोजना पर काम करने के बजाय अपने ढांचे को डिबग करने में खर्च करेंगे । स्पष्ट सिर के साथ कार्य को स्वीकार करें , और YAGNI का एक अच्छा, ठोस समझ । शुभकामनाएँ!

Comments

साभार, ई.जम्स मैं एएनएसआई सी के शीर्ष पर ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क नहीं बनाना चाहता हूं, लेकिन विशेष और उचित प्रक्रियात्मक प्रोग्रामिंग डिजाइन सिद्धांतों की तलाश करता हूं। MISRA-C संकेत बहुत उपयोगी है, खासकर क्योंकि यह वास्तव में एक एम्बेडेड परियोजना है। मैं इसे करीब से देखने जा रहा हूं।

— डिमाइ

आह, एम्बेडेड सी की खुशियाँ यह मत भूलो कि आपको अपने चर को अपने फ़ंक्शन के शीर्ष पर (या किसी भी { }ब्लॉक के शीर्ष पर ) घोषित करना होगा । वह हमेशा मुझे एक या दो बार काटता है:)

— ई.जेम्स

Answer 4

ओओपी एक कार्यप्रणाली है न कि तकनीक। इसलिए मेरी पहली सलाह यह प्रक्रियात्मक प्रोग्रामिंग के रूप में सोचना बंद कर देती है।

E.James की बात करने के लिए, आप ऑब्जेक्ट-ओरिएंटेड भाषा को फिर से बनाने और बनाने की कोशिश नहीं करना चाहते हैं या यह दिखावा करते हैं कि आपके पास क्षमताएं हैं। आप अभी भी कुछ सरल सिद्धांतों से चिपके हुए सभी सही काम कर सकते हैं:

1. टेस्ट ड्राइव सब कुछ।
2. खोजें जो बदलता है और उसे एनकैप्सुलेट करता है।
3. इंटरफेस के लिए डिजाइन।