"हॅलो, अमिगो! मी तुम्हाला OOP च्या आणखी एका फायद्याबद्दल सांगू इच्छितो. तुम्ही पहा, कार्यक्रम इमारतींपेक्षा प्राण्यांसारखे असतात. ते बांधलेले नसतात, ते वाढतात. विकास म्हणजे सतत बदल. बांधकामात, तुम्ही हे करू शकता. एक चांगली योजना आहे आणि त्याचे अनुसरण करा. पण सॉफ्टवेअर डेव्हलपमेंटमध्ये तसे नाही."
बर्‍याचदा, तुम्ही इच्‍छित असलेल्‍या मार्गाने काही करू शकत नाही, आणि तुम्हाला तुमच्‍या प्रोग्रॅमवर पुष्कळदा काम करावे लागते. आणि त्याहूनही अधिक वेळा, ग्राहकांच्या गरजा बदलतात.
"परंतु ग्राहकाने खरोखर तपशीलवार तपशील प्रदान केल्यास काय?"
"कालांतराने काय होते ते पहा. एखादे उत्पादन यशस्वी झाल्यास, ग्राहक नवीन आवृत्ती, आणि नंतर दुसरी आणि दुसरी आवृत्ती प्रकाशित करू इच्छितो. आणि, अर्थातच, तुम्हाला काही « छोटे बदल » करावे लागतील विद्यमान उत्पादन. त्यामुळे सॉफ्टवेअर डेव्हलपमेंट ही बदलांची एक लांबलचक मालिका आहे. फक्त कॅडेन्समध्ये फरक आहे. प्रत्येक आठवड्यात, महिन्यातून एकदा किंवा दर सहा महिन्यांनी नवीन आवृत्ती रिलीज केली जाऊ शकते."
"मग या सगळ्यातून आपण काय निष्कर्ष काढतो?"
"उत्पादनाची अंतर्गत रचना अशा प्रकारे राखली जाणे आवश्यक आहे की जेणेकरुन कमीत कमी रीवर्किंगसह मोठे (आणि किरकोळ) बदल करता येतील."
"तुम्ही ते कसे करता?"
"प्रोग्राममध्ये एकमेकांशी संवाद साधणार्‍या ऑब्जेक्ट्सचा समावेश कसा होतो याबद्दल आपण आधीच बोललो आहोत. आपल्या सर्व प्रोग्रॅमच्या ऑब्जेक्ट्सचे बोर्डवर प्रतिनिधित्व करण्यासाठी जाड ठिपके वापरू. आपण प्रत्येक ऑब्जेक्ट (बिंदू) पासून सर्व ऑब्जेक्ट्सवर बाण काढू. (बिंदू) ज्यांच्याशी ते संवाद साधते."
आता ऑब्जेक्ट्स (बिंदू) गटांमध्ये एकत्र करू. ठिपके समान गटाशी संबंधित आहेत जर ते इतर बिंदूंपेक्षा एकमेकांशी खूप जास्त जोडलेले असतील. जर एखाद्या बिंदूचे बहुतेक बाण त्याच्या गटातील ठिपक्यांकडे निर्देशित करतात, तर आम्ही ऑब्जेक्ट्सचे योग्य गट केले आहेत. एकाच गटातील ठिपके घट्ट जोडलेले आहेत असे म्हटले जाते, तर वेगवेगळ्या गटांमधील ठिपके सैलपणे जोडलेले असतात.
याला " सैल कपलिंगचे सिद्धांत " असे म्हणतात . एक प्रोग्राम अनेक भागांमध्ये विभागलेला असतो, अनेकदा स्तर, ज्याचे तर्क त्यांच्या अंतर्गत संरचनेशी जोरदारपणे बांधलेले असतात आणि इतर स्तर/भागांशी कमकुवतपणे बांधलेले असतात. स्तरांमधील परस्परसंवाद सामान्यतः अत्यंत विभागीय असतो. एक स्तर त्याच्या वर्गांचा फक्त एक छोटा उपसंच वापरून दुसऱ्या स्तराला कॉल करू शकतो.
"तेच 'श्रम विभागणी' तत्त्व, पण मोठ्या प्रमाणावर?"
"तंतोतंत. यामुळे आम्हाला विभागाची पुनर्रचना करणे, ते अधिक कार्यक्षम बनवणे आणि आणखी लोकांना कामावर घेण्यास अनुमती मिळते आणि जर आम्ही आंतरविभागीय प्रोटोकॉल बदलले नाहीत, तर आमचे सर्व बदल स्थानिक असतील. कोणालाही पुन्हा प्रशिक्षित करण्याची गरज नाही. आम्ही' संपूर्ण सिस्टीमची पुनर्रचना करावी लागेल. विभागीय परस्परसंवादाची यंत्रणा चांगल्या प्रकारे निवडल्यास प्रत्येक विभाग आपल्या अंतर्गत व्यवहारांना अशा प्रकारे अनुकूल करू शकतो."
"जर ते चांगले निवडले गेले. आणि जर ते चांगले निवडले गेले नाहीत तर काय?"
'मग तुम्हाला बदल करण्यासाठी " विगल रूम " त्वरीत संपेल आणि संपूर्ण सिस्‍टम पुन्हा काम करावे लागेल. असे वेळोवेळी घडते. आम्ही भविष्याचा अंदाज लावू शकत नाही, परंतु आम्ही प्रोग्राम पुन्हा लिहिण्याची संख्या कमी करू शकतो."
"ठीक आहे. प्रोग्रामला असे वाटून घेण्याचा फायदा मला दिसत आहे, पण OOP चित्रात कसा येतो?"
"जेव्हा आपण विभागांची रचना कशी करायची आणि ते कसे परस्परसंवाद करतील हे निवडतो, तेव्हा आम्ही ' अमूर्ततेचे तत्त्व ' लागू करतो. प्रोग्रामिंगमध्ये, अ‍ॅब्स्ट्रॅक्शनचा वापर प्रोग्रामला विभाजित करण्याचा सर्वोत्तम मार्ग आणि भागांचा परस्परसंवाद कसा करावा हे निर्धारित करण्यासाठी केला जातो. हे तत्त्व जोपर्यंत आम्ही प्रोग्रामला वैयक्तिक वर्गांमध्ये मोडत नाही तोपर्यंत घटक भागांवर देखील वारंवार लागू केले जाऊ शकते."
"आणि या भागांची अंतर्गत रचना लपवून ठेवणे आणि ते इतर भागांशी कसे संवाद साधतात यावर कठोरपणे मर्यादा घालणे - हे एन्कॅप्सुलेशन आहे , बरोबर?"
"नक्कीच. एन्कॅप्सुलेशन आणि अॅब्स्ट्रॅक्शन हे ओओपीचे कोनस्टोन आहेत. एका चांगल्या प्रोग्रामला या दोन तत्त्वांचे पालन करणे आवश्यक आहे. नंतर आपण इतर तत्त्वांवर एक नजर टाकू आणि त्यांचे फायदे समजून घेऊ."
"चांगले सामान. मी थांबू शकत नाही!"
GO TO FULL VERSION