2009-06-09 11 views
8

बड़ी सी ++ परियोजनाओं में एक समस्या निर्माण समय हो सकती है। आपके निर्भरता पेड़ में कुछ वर्ग ऊंचा है जिस पर आपको काम करने की आवश्यकता होगी, लेकिन आम तौर पर आप ऐसा करने से बचते हैं क्योंकि हर निर्माण में बहुत लंबा समय लगता है। आप अपने सार्वजनिक इंटरफ़ेस को बदलना नहीं चाहते हैं, लेकिन हो सकता है कि आप अपने निजी सदस्यों को बदलना चाहते हैं (कैश-वैरिएबल जोड़ें, एक निजी विधि निकालें, ...)। आप जिस समस्या का सामना कर रहे हैं वह यह है कि सी ++ में, यहां तक ​​कि निजी सदस्यों को भी सार्वजनिक हेडर फ़ाइल में घोषित किया जाता है, इसलिए आपके निर्माण प्रणाली को सब कुछ पुनः संयोजित करने की आवश्यकता होती है।सी ++ में इंटरफेस और कार्यान्वयन को कम करने के लिए आप किस पैटर्न का उपयोग करते हैं?

आप इस स्थिति में क्या करते हैं?

मैंने दो समाधानों को स्केच किया है जो मुझे पता है, लेकिन दोनों के पास उनके डाउनसाइड्स हैं, और शायद एक बेहतर तरीका है जिसे मैंने अभी तक नहीं सोचा है।

उत्तर

9

pimpl पैटर्न:

अपने हेडर फाइल में, केवल आगे घोषित कार्यान्वयन वर्ग के लिए सार्वजनिक तरीकों और एक निजी सूचक (pimpl-सूचक या प्रतिनिधि) की घोषणा।

अपने स्रोत में, कार्यान्वयन कक्षा घोषित करें, प्रतिनिधि को अपनी सार्वजनिक कक्षा की हर सार्वजनिक विधि को आगे बढ़ाएं, और अपनी सार्वजनिक कक्षा के प्रत्येक निर्माता में अपने पिंपल वर्ग का एक उदाहरण बनाएं।

प्लस:

  • तुम सब कुछ पुन: संयोजित किए बिना अपने वर्ग के कार्यान्वयन बदलने देता है।
  • विरासत अच्छी तरह से काम करता है, केवल वाक्यविन्यास थोड़ा अलग हो जाता है।

माइनस:

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

विरासत का उपयोग करना:

आपके शीर्षक में, शुद्ध आभासी तरीकों और एक कारखाने के रूप में जनता के तरीकों की घोषणा।

अपने स्रोत में, अपने इंटरफ़ेस से कार्यान्वयन कक्षा प्राप्त करें और इसे कार्यान्वित करें। फैक्ट्री के कार्यान्वयन में कार्यान्वयन का एक उदाहरण लौटाता है।

प्लस:

  • तुम सब कुछ पुन: संयोजित किए बिना अपने वर्ग के कार्यान्वयन बदलने देता है।
  • लागू करने के लिए आसान और मूर्खतापूर्ण।

माइनस:

  • सच सार्वजनिक आधार वर्ग जो जनता के आधार के (निजी) कार्यान्वयन के तरीकों के कुछ वारिस चाहिए की एक (सार्वजनिक) व्युत्पन्न उदाहरण परिभाषित करने के लिए अजीब।
+0

एक और प्लस है कि आप आसानी से इकाई परीक्षण के लिए वर्ग नकली कर सकते हैं अगर आप एक इंटरफेस –

0

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

+0

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

6

जॉन Lakos 'Large Scale C++ Software Design एक उत्कृष्ट पुस्तक है कि बड़े सी ++ परियोजनाओं के निर्माण में शामिल चुनौतियों को संबोधित करता है। समस्याएं और समाधान सभी वास्तविकता में आधारित हैं, और निश्चित रूप से ऊपर की समस्या पर चर्चा की जाती है। अत्यधिक सिफारिशित।

+0

सहमत - एक क्लासिक, अगर थोड़ा धीमा पढ़ा जाता है। बीटीडब्ल्यू, मैंने सुना है कि वह एक दूसरा संस्करण जारी करने जा रहा था - किसी ने इस पर एक अपडेट सुना है? +1 –

+0

ड्रू - क्या आपको याद है कि आपने यह कहां सुना (लगभग 2 संस्करण)? इसके अलावा, मैं देखा था कि Lakos स्केलेबल सी ++ के बारे में 2006 में एक किताब के लिए जा रहा था, लेकिन यह stillborn गया लगता है (या कम से कम बैक burnered।) यह एक शर्म की बात है क्योंकि किताब (LSCSD) वास्तव में एक की जरूरत को संबोधित करता है, मैं उम्मीद कर रहा था कि 13 साल बाद अपडेट जारी किया जाएगा। – Dan

+0

दान - मेरी इच्छा है कि मुझे याद आए - मैंने सोचा कि यह एडब्ल्यू वेबसाइट पर था लेकिन मुझे अब यह नहीं दिखाई देता है। शायद अमेज़ॅन भी? शायद मेरे हिस्से पर सिर्फ इच्छापूर्ण सोच ... –

0

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

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

+0

क्या आपके पास मेकफ़ाइल में एक सामान्य लक्ष्य है या आप मैन्युअल रूप से संकलित और लिंक करते हैं? – Tobias

0

कोई नहीं।

मैं एक का उपयोग कर में बिंदु देखते हैं, लेकिन मुझे लगता है कि निम्नलिखित तर्क कई स्थितियों में उस बिंदु को कम:

  1. स्पष्टता पहले आता है। यदि रनटाइम गति के लिए स्पष्टता समझौता करना संकलन समय गति के लिए स्पष्टता समझौता करने के बारे में क्या माना जाना चाहिए?
  2. निजी सदस्यों को अक्सर इतना नहीं बदला जाना चाहिए।
  3. आमतौर पर, यह कि लंबे सब कुछ के पुनर्निर्माण के लिए नहीं ले करता है।
  4. तेज़ उपकरण भविष्य में आ जाएगा, इसलिए संकलन गति की समस्या को स्वचालित रूप से कम किया जाएगा। आपका कोड स्वचालित रूप से स्पष्ट नहीं होगा।
  5. आपको वैसे भी पुनर्निर्माण करना चाहिए।
  6. आप Incredibuild की कोशिश की?
बेशक

अंत में यह एक आर्थिक फैसला है। यदि आपकी परियोजना में "3" का वजन महत्वपूर्ण है और किसी कारण से "6" लागू नहीं हो सकता है, तो आगे बढ़ें: आप खोने से इन टेम्पलेट्स का उपयोग करने से अधिक जीतेंगे।

+1

आपका बिंदु निश्चित रूप से मान्य है, इस तरह की चीज समय से पहले नहीं की जानी चाहिए क्योंकि आपको प्रोफाइलिंग से पहले कोड अनुकूलित नहीं करना चाहिए। मैं बिंदु 2 से असहमत हूं - सॉफ्टवेयर स्थिर नहीं है, लेकिन लगातार विकसित होता है। यदि कुछ भी हो, तो आपको अपने सार्वजनिक इंटरफेस को स्थिर रखने की कोशिश करनी चाहिए, लेकिन जब आप सामान को दोबारा बदलते हैं तो भी तेज़ी से बदल जाता है। मैं भी असहमत हूं 4. तेज उपकरण आएंगे, लेकिन इस बीच, डेवलपर्स ने बहुत सारे स्थान जोड़े होंगे। प्वाइंट 5 बिल्कुल सही है, और इस कारण का एक हिस्सा है कि आप इस तरह के पैटर्न का उपयोग क्यों करना चाहते हैं। – Tobias

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

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