2010-09-07 13 views
5

मैं सी ++ में एक प्रोजेक्ट विकसित कर रहा हूं। मुझे एहसास हुआ कि मेरा कार्यक्रम ओओ नहीं है।ऑब्जेक्ट उन्मुख प्रोग्रामिंग

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

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

सभी प्रतिक्रियाएं आपका स्वागत है, इसे पढ़ने के लिए समय लेने के लिए धन्यवाद।

उत्तर

6

नहीं, मुझे लगता है कि अगर यह तोड़ा नहीं गया है, तो इसे ठीक न करें।

कोई भी विंडोिंग सिस्टम स्वाभाविक रूप से डिग्री सेल्सियस है। आपके पास ओएस द्वारा प्रबंधित विंडो के लिए एक हैंडल है, और आप इस पर कुछ संचालन कर सकते हैं। चाहे आप window->resize() या resize(window) उपयोग करें, असीमित है। इस तरह के वाक्य रचनात्मक पुनर्गठन में स्पष्ट रूप से कोई मूल्य नहीं है।

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

तो, यदि आप ओओ के साथ अधिक सुरुचिपूर्ण होने के लिए कार्यक्रम को दोबारा कर सकते हैं, तो इसके लिए जाएं। यदि यह प्राकृतिक विकास के साथ ओओ प्रतिमान में बढ़ता है, तो सर्वोत्तम प्रथाओं का पालन करें और ऐसा होने दें। लेकिन बस buzzword- अनुपालन करने की कोशिश मत करो।

1

यह इस बात पर निर्भर करता है कि आप इस परियोजना के साथ क्या हासिल करना चाहते हैं। यदि आपके लिए सी ++ कामों की ओओ सुविधाओं का उपयोग नहीं किया जाता है और बदलने के लिए कोई अच्छा कारण नहीं है, तो आप जिस तरह से जा रहे हैं उसे जारी रखें। यदि, दूसरी ओर, आप ओओपी के बारे में और जानना चाहते हैं और आपके पास आवेदन करने का समय है, तो इसे और अधिक ओओ शैली के लिए पुन: सक्रिय करने से आपको एक महान सीखने का मौका मिलेगा।

1

मैं जो भी विंडो प्रबंधक आप उपयोग कर रहा हूं उसके साथ काम करने के लिए सर्वोत्तम प्रथाओं का पालन करता हूं। अधिकांश ओओ शैली का उपयोग करते हैं, जिसे आप अपने उपयोग पैटर्न का पालन करते समय स्वचालित रूप से (!) प्राप्त करेंगे।

2

दो चीजें जिनके बारे में आपको सोचने की आवश्यकता है: लागत/लाभ विश्लेषण और अवसर लागत।

ओओ होने के लिए अपना कोड बदलने की लागत क्या है? क्या फायदा है यदि उत्तरार्द्ध पूर्व से अधिक है, तो मैं इसे बदलने की ओर रुख करता हूं।

लागतों में पारंपरिक लागत जैसे समय व्यतीत, पैसा खर्च और अन्य शामिल हैं। लाभों में एक क्लीनर कार्यान्वयन शामिल है, जिससे भविष्य में आसान रखरखाव होता है। जो भी अन्य लागत और लाभ वास्तव में आपकी स्थिति पर निर्भर हैं।

लेकिन एक चीज अक्सर अनदेखी की जाती है अवसर अवसर है। यह एक लागत है जिसे आपके विश्लेषण में शामिल किया जाना चाहिए। यह एक आर्थिक शब्द है जिसका अर्थ है पूर्व अवसर।

दूसरे शब्दों में, यदि आप अपना कोड बदलते हैं, तो आपकी लागत में उस समय के साथ कुछ और करने में आपकी अक्षमता शामिल है।

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

+0

दिलचस्प बिंदु। मेरा कोड ओओ में बदलकर सुंदर दिखता है, लेकिन मुझे ज्यादा कार्यक्षमता नहीं मिलती है। –

+1

कार्यक्षमता सबकुछ नहीं है, और कोड की सुंदरता अप्रासंगिक है। कोड _is_ प्रासंगिक और सुंदर कोड की रखरखाव अधिक रखरखाव हो सकती है लेकिन यह हमेशा एक दी गई नहीं है। – paxdiablo

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