कक्षाएं बड़े अनुप्रयोगों को प्रबंधित करने में आपकी सहायता कैसे करती हैं?

Question

यह एक बातचीत में आया जो मैं ऑनलाइन था, और यह मेरे लिए हुआ कि मुझे नहीं पता कि यह कैसे काम करना चाहिए: काफी सारे प्रोग्रामर बस एक दिए गए के रूप में लेते हैं - वास्तव में, स्पष्ट है कि कक्षाएं हैं विशाल सॉफ्टवेयर परियोजनाओं के प्रबंधन के लिए आवश्यक भाषा सुविधा।

यह मेरे लिए स्पष्ट नहीं है कि वे यह कैसे करते हैं।

मेरा प्रश्न है, आप कैसे जानते हैं? वहां कौन से उद्देश्य उपाय हैं जो दिखाते हैं कि कक्षाएं उत्पादकता, कोड पुन: उपयोग, और एक कार्यक्रम के उत्पादन की जटिलता को कम करती हैं? कक्षाओं के कौन से पहलू उन्हें बड़ी टीमों के लिए सहयोग करने के लिए आदर्श बनाते हैं?

और अब, एक सवाल है जिसे मैं पूछना चाहता हूं, यह व्यक्त करना मुश्किल है। मुझे खेद है कि अगर मुझे यह गलत लगता है और भ्रमित या किसी को भी परेशान करता है:

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

वह आखिरी बिट ऐसा कुछ है जो स्टीव येगेज अपने ब्लॉग पर संकेत दे रहा है। लेकिन मैं किसी भी कठोर डेटा की वास्तविक कमी के कारण तर्क के दोनों पक्षों पर संदेहस्पद हूं, और मेरे अपने निष्कर्ष पर आने का पर्याप्त अनुभव नहीं है।

आपको क्या लगता है?

संपादित करें: विशेष रूप से मुझे दिलचस्पी है कि क्यों कई प्रोग्रामर सोचते हैं कि प्रोटोटाइप शैली विरासत बड़े अनुप्रयोगों की बात करते समय कार्य तक नहीं है। मुझे खेद है कि इस सवाल के बारे में अस्पष्ट है- यह इस विषय के बारे में समझने की कमी का एक उत्पाद है।

संपादित 2: कार्यात्मक प्रोग्रामिंग के माध्यम से मेरा मतलब कुछ भ्रम लगता है। (मुझे नहीं लगता कि वीबी का कोई भी संस्करण कभी कार्यात्मक था, निश्चित रूप से पुराने संस्करण नहीं)। कृपया विकिपीडिया लेख देखें। http://en.wikipedia.org/wiki/Functional_programming

संपादित 3: और मुझे जोर देना चाहिए कि मैं उद्देश्य उपायों की तलाश में हूं। व्यक्तिपरक राय नहीं।

Answer 1

Encapsulation सिद्धांत एक उद्देश्य कारण प्रदान करता है कि कक्षाएं कक्षाओं की तुलना में बेहतर क्यों होती हैं।

मानकीकरण के लिए अंतर्राष्ट्रीय संगठन encapsulation को परिभाषित करता है, 'एक वस्तु में निहित जानकारी केवल वस्तु द्वारा समर्थित इंटरफेस पर बातचीत के माध्यम से सुलभ है।'

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

ध्यान दें कि शब्द: परिवर्तन। जानकारी छिपाने की संभावना संभावित घटनाओं, जैसे कि भविष्य में कठिन डिजाइन निर्णयों को बदलना।

दो विधियों के साथ एक वर्ग पर विचार करें: विधि ए() जो कक्षा के भीतर छिपी हुई जानकारी है, और विधि बी() जो सार्वजनिक है और इस प्रकार अन्य वर्गों द्वारा सीधे पहुंचा जा सकता है।

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

लहर प्रभावों की यह कम संभावना यह encapsulation का एक प्रमुख लाभ है।

किसी भी कार्यक्रम में स्रोत कोड निर्भरताओं की अधिकतम संभावित संख्या (एमपीई - संक्षिप्त शब्द ग्राफ सिद्धांत से) पर विचार करें। उपर्युक्त परिभाषाओं से बाहर निकलने के लिए, हम कह सकते हैं कि, उपयोगकर्ताओं को समान कार्यक्षमता प्रदान करने वाले दो कार्यक्रम दिए गए हैं, निम्नतम एमपीई के साथ कार्यक्रम बेहतर encapsulated है, और सांख्यिकीय रूप से अधिक अच्छी तरह से encapsulated कार्यक्रम बनाए रखने और विकसित करने के लिए सस्ता होगा, क्योंकि लागत इसमें अधिकतम संभावित परिवर्तन कम अच्छी तरह से encapsulated systém में अधिकतम संभावित परिवर्तन से कम होगा।

विचार करें, इसके अलावा, केवल विधियों और कक्षाओं के साथ एक भाषा पर विचार करें और इसलिए एक दूसरे से छिपाने की जानकारी का कोई मतलब नहीं है। मान लें कि हमारे कार्यक्रम में 1000 तरीके हैं। इस कार्यक्रम का एमपीई क्या है?

Encapsulation सिद्धांत हमें बताता है कि, एन सार्वजनिक नोड्स की एक प्रणाली दी गई है, इस प्रणाली का एमपीई एन (एन -1) है। इस प्रकार हमारे 1000 सार्वजनिक तरीकों का एमपीई 99 99,000 है।

अब चलिए उस वर्ग को दो वर्गों में तोड़ दें, प्रत्येक में 500 विधियां होंगी। जैसा कि अब हमारे पास कक्षाएं हैं, हम कुछ विधियों को सार्वजनिक और कुछ तरीकों से निजी चुन सकते हैं। यह तब तक होगा जब तक कि प्रत्येक विधि वास्तव में हर दूसरी विधि (जो असंभव है) पर निर्भर होती है। मान लें कि प्रत्येक वर्ग में 50 विधियां सार्वजनिक हैं। सिस्टेम का एमपीई क्या होगा?

Encapsulation सिद्धांत हमें बताता है: एन ((एन/आर) -1 + (आर -1) पी) जहां आर कक्षाओं की संख्या है, और पी प्रति वर्ग सार्वजनिक तरीकों की संख्या है। यह हमारे दो-वर्ग के सिस्टेम को 49 9, 000 का एमपीई देगा। इस प्रकार इस दो-वर्ग के सिस्टेम में बदलाव की अधिकतम संभावित लागत पहले से ही अनएन्सेप्लेटेड सिस्टेम की तुलना में काफी कम है।

मान लें कि आप अपने वर्ग को 3 कक्षाओं में तोड़ते हैं, प्रत्येक में 333 वर्ग होते हैं (ठीक है, एक 334 होगा), और फिर प्रत्येक 50 सार्वजनिक तरीकों से। एमपीई क्या है? उपर्युक्त समीकरण का फिर से उपयोग करना, एमपीई लगभग 482,000 होगा।

यदि सिस्टेम 250 तरीकों के 4 वर्गों में विभाजित है, तो एमपीई 44 9, 000 होगा।

यदि ऐसा लगता है कि हमारे सिस्टेम में कक्षाओं की संख्या में वृद्धि हमेशा अपने एमपीई को कम कर देगी, लेकिन ऐसा नहीं है। Encapsulation सिद्धांत से पता चलता है कि कक्षाओं की संख्या जिसमें एमपीईई को कम करने के लिए systém को विघटित किया जाना चाहिए: r = sqrt (n/p), जो हमारे systém वास्तव में है 4. उदाहरण के लिए, 6 वर्गों के साथ एक systém एक एमपीई होगा 465,666 में से।

Answer 2

मैं किसी प्रोग्रामिंग प्रतिमान की ओर कोई बड़ा नहीं हूं, लेकिन मैं थोड़ी देर के लिए ओओ फैशन में काम कर रहा हूं।

व्यक्तिगत रूप से, मेरे पास बहुत सारे 'ए-एचए' हैं! क्षण जिन वर्गों ने मुझे सीधे उस डोमेन को समझने में मदद की है जो मैं बेहतर तरीके से काम कर रहा हूं।

सबसे विशेष रूप से, ऐसे मामलों में जहां भ्रष्टाचार हो रहा है, या सिस्टम को क्या करना है, इस बारे में भ्रम है, कक्षाओं ने मुझे अक्सर यह सोचने के लिए मजबूर किया है कि पूरे का यह अलग टुकड़ा क्या करना चाहिए, और और भी हाथों में कक्षाओं/विधियों को पुन: सक्रिय करने के लिए अक्सर नहीं।

संक्षेप में, encapsulation वास्तव में मुझे एक खुश व्यक्ति बनाता है। ;)

आशा है कि मदद करता है।

Answer 3

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

अन्य चरम public static void main (या ASP.NET में Page_Load) में वैश्विक चर और जाम अपने सभी तर्क का एक समूह का उपयोग करें और स्थिर तरीके कि अन्य स्थिर तरीकों फोन और इतने पर ... (मैं कम से चक्कर आ मिला कॉल करने के लिए है अंतिम वाक्य का अंत।)

मेरी ओओ मानसिकता को तोड़ने वाली एकमात्र चीज यह है कि अगर मैं एक शुद्ध कार्यात्मक भाषा के साथ काम कर रहा था, तो ऐसा कुछ है जिसे मैंने दुर्भाग्य से कॉलेज के बारे में नहीं सोचा था।

Answer 4

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

अब जो मैंने अभी वर्णन किया है वह एक परिपूर्ण दुनिया से एक अजीब दृश्य है। लेकिन ओओपी काम करने वाले किसी भी अच्छे डेवलपर को ऐसा कुछ करने के लिए प्रयास करना चाहिए।

ओओपी एक स्वीकृति है कि हम, डेवलपर्स, बस इंसान हैं और एक ही सिस्टम को एक बार में समझ नहीं सकते हैं। इसलिए हम सिस्टम को छोटे पुन: प्रयोज्य भागों में तोड़ते हैं और उन पर ध्यान केंद्रित करते हैं।

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

तो 1234567890123-456-7890 बन जाता है। सौभाग्य से हमारे लिए, फोन कंपनियां भी इन नंबरों को एक ही तरीके से तोड़ती हैं और अर्थों को आवंटित करती हैं। 123 क्षेत्र कोड है, 456 उपसर्ग है, और 7890 लाइन संख्या है। इनमें से प्रत्येक भाग एक वर्ग की तरह है, उनमें सभी की व्यक्तिगत जिम्मेदारियां, प्रारूप और अर्थ हैं।

तो निष्कर्ष में सबसे अच्छी बात यह है कि मैं कह सकता हूं कि ओओपी हमें बड़ी, स्केलेबल सिस्टम बनाने की अनुमति देता है जिसमें केंद्रीकृत और encapsulated कार्यक्षमता है। यह हमें हर समय बड़ी तस्वीर देखने की ज़रूरत नहीं है और एक चीज करने और इसे अच्छी तरह से करने पर ध्यान केंद्रित करने में सक्षम है।

Answer 5

दो चीजें।

पहला यह विचार है कि एक वर्ग अपारदर्शी डोमेन इकाई है। सही ढंग से किया गया, ऑब्जेक्ट-उन्मुख प्रोग्राम अबास्ट्रक्शन की एक परत पेश करते हैं: अगली उच्चतम परत पर, आप विवरणों से निपटने के बजाय, जो चाहते हैं उसे करने के लिए मार्शल ऑब्जेक्ट्स। आपको यह जानने की आवश्यकता नहीं है कि वस्तुओं और वर्ग कैसे काम करते हैं: केवल वे क्या करते हैं। यह एक तरह की जानकारी छिपाने वाली है, और यह उस जटिलता को कम कर देता है जिसे एक टीम को अपने सिर में रखना पड़ता है।

दूसरी बात यह है कि ओओ प्रोग्रामिंग एक प्रकार के कोड पुन: उपयोग की अनुमति देता है: आप उन वर्गों को परिभाषित कर सकते हैं जो अन्य वर्गों (विरासत) में कुछ व्यवहारों को ओवरराइड करते हैं, या जिनके उदाहरणों में उनके उद्देश्य प्राप्त करने के लिए उनका उपयोग करके अन्य वर्गों के उदाहरण शामिल हैं (encapsulation और संरचना)।

OO तकनीकों का उपयोग करके सही ढंग से प्रबंधित करने के लिए आवश्यक कोड की मात्रा को कम कर सकता है, और सिस्टम को काम करने या बनाए रखने के लिए आपको ध्यान में रखने की आवश्यकता की संख्या को कम कर सकता है। अभ्यास में यह दृष्टिकोण हमेशा काम नहीं करता है।

Answer 6

मुझे लगता है कि कक्षाएं मदद कर सकती हैं, क्योंकि वे categorization की सामान्य संज्ञानात्मक अवधारणा से मेल खाते हैं, और इसलिए स्वाभाविक रूप से बड़े अनुप्रयोगों का वर्णन करने में मदद कर सकते हैं।

Answer 7

निष्पक्ष, तुम कैसे जानते हो कि कक्षाओं के उपयोग आवेदन के साथ शुरू करने के लिए बड़ी होने का कारण नहीं है?

(, कोबोल, यहां तक ​​कि सादे एसक्यूएल जैसे सी) किसी भी बड़े कार्यक्रम/अनुप्रयोग है कि एक OO भाषा में नहीं लिखा गया था ले लो और आप सीधे भाषा प्रतिमान नहीं ठहराया जाता है कि कोड आकार देखने के लिए सक्षम होना चाहिए। अच्छी तरह से डिज़ाइन किए गए, अत्यधिक परिष्कृत, पुन: प्रयोज्य सी # या जावा घटकों की प्रत्येक संख्या के लिए, अच्छी तरह से डिज़ाइन किए गए, अत्यधिक परिष्कृत, पुन: प्रयोज्य सी डीएलएल की एक समान संख्या भी है। इसके विपरीत, भयानक, सूजन कोड के बराबर संख्याएं हैं।

बिंदु यह है कि अच्छे प्रोग्रामर भाषा/मंच के बावजूद अपने सिस्टम डिज़ाइन को परिष्कृत करने में सक्षम हैं।

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

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

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

जब आप मूल सिद्धांत को समझते हैं कि कुछ वस्तु केवल छोटी वस्तुओं से बना है, तो आप अत्यधिक पुन: प्रयोज्य कोशिकाओं या अणुओं को बनाने के अपने रास्ते पर होंगे।

Answer 8

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

जहां तक ​​रखरखाव हो जाता है, यूएमएल कक्षा आरेख को देखना और यह समझना बहुत आसान है कि कार्यों की सूची को देखने से सबकुछ कैसे रखा जाता है, मेरी राय में।

Answer 9

मुझे लगता है कि कक्षाएं कहकर, आपको वस्तुओं का मतलब होना चाहिए। कक्षाएं ऐसी जगह नहीं हैं जहां आप अपनी वस्तुओं में डाल सकते हैं। ओओपी प्रतिमान एक कारण के लिए इतना सफल है। एक बार आपके पास 'आह!' हो पल जब आपको लगता है कि आप अंततः ओओपी की अवधारणा को समझ चुके हैं, तो आप प्रोग्रामिंग को एक और अधिक संगठित फैशन में शुरू कर सकते हैं।

मैंने लंबे समय तक विजुअल बेसिक 3 में प्रोग्राम किया है, इसलिए मुझे कार्यात्मक प्रोग्रामिंग के साथ बहुत अनुभव हुआ, फिर वीबी 5 में आना और वस्तुओं की खोज करना एक बहुत ही राहत थी क्योंकि मैं वास्तविक दुनिया की इकाइयों को अपने कोड में जोड़ सकता था , और इससे बहुत मदद मिली।

यह आपके पूरे कोड में वास्तविक दुनिया की इकाइयों को पुनर्जीवित करने का पूरा बिंदु है। यह पढ़ने और काम करना आसान बनाता है क्योंकि आप कुछ चुन सकते हैं और इसके साथ सामान कर सकते हैं, या इसके लिए सामान कर सकते हैं।

Answer 10

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

Answer 11

यदि आपके पास बड़े एप्लिकेशन में "नंगे" कार्यों का समूह है, तो उन कार्यों में परिवर्तन करना मुश्किल है।

• कठिन है जो समारोह में अन्य लोगों के कोड को तोड़ने के बिना कार्यों में परिवर्तन करने की ("अगर मैं इस बदलने के लिए, जो इसे प्रभावित करता है?")
• मुश्किल उपयोग कर रहा है देखने के लिए।

यदि आप कक्षाओं में कार्यों को लपेटते हैं, तो आप कोड के दायरे को अलग करने में मदद करते हैं। यह एक जादू बुलेट नहीं है, लेकिन यह मदद करता है।