आम्हाला ओओपीची गरज का आहे?

1. कंपनी इतिहास

मला तुम्हाला एक कथा सांगायची आहे जी OOP मोठ्या प्रणालींच्या जटिलतेशी लढण्यास कशी मदत करते हे दर्शवते. OOP चा उद्देश समजून घेण्यासाठी हे आवश्यक आहे .

एकेकाळी एक छोटी कंपनी होती जी इंटरगॅलेक्टिक शिपिंग सेवा पुरवत होती...

चला त्याला Galaxy Rush म्हणू या. यात ५ जणांना रोजगार मिळाला. एकाने फायनान्समध्ये काम केले, दुसऱ्याने वेअरहाऊसमध्ये काम केले, तिसऱ्याने डिलिव्हरी केली, चौथ्याने जाहिरात हाताळली आणि पाचव्याने संपूर्ण एंटरप्राइझचे व्यवस्थापन केले.

ते खूप मेहनती होते आणि प्रत्येक गोष्टीत यशस्वी झाले. कंपनी चांगली प्रतिष्ठा होती आणि भरपूर पैसे कमावले. परंतु दरवर्षी अधिकाधिक ऑर्डर येत असल्याने बॉसला अतिरिक्त कर्मचारी नियुक्त करावे लागले. वेअरहाऊससाठी आणखी काही, डिलिव्हरीसाठी आणखी काही, फायनान्ससाठी आणखी एक आणि कंपनीचा मार्केट शेअर वाढवण्यासाठी अतिरिक्त जाहिरात तज्ञ.

आणि तेव्हाच समस्या सुरू झाल्या. तेथे बरेच लोक होते आणि ते एकमेकांच्या मार्गात येऊ लागले.

मार्केटर नवीन जाहिरात मोहिमेवर बँक खाते काढून टाकतो, त्यामुळे त्वरित पाठवण्याची आवश्यकता असलेली उत्पादने खरेदी करण्यासाठी पैसे नाहीत.

वेअरहाऊसमध्ये 10 अगदी नवीन हायपर ड्राईव्ह आहेत ज्या महिन्यातून एकदा क्लायंटला पाठवल्या जातात. एका कुरिअरने उड्डाण केले आणि वेगळ्या क्लायंटसाठी हायपर ड्राईव्ह घेऊन गेला, ज्यामुळे 10 हायपर ड्राइव्हसाठी नियमित ऑर्डर एका महिन्याने उशीर झाला. पहिल्या कुरिअरला दुसर्‍या कुरिअरने भरल्या जाणार्‍या दुसर्‍या ऑर्डरबद्दल फक्त माहित नव्हते.

नवीन सहाय्यक व्यवस्थापक अधिक वस्तू खरेदी करण्यासाठी स्पेसशिपवर कुरिअर पाठवतो. दरम्यान, इतर प्रत्येकजण उपलब्ध स्पेसशिप दिसण्याची वाट पाहत आहे. अनेक तातडीच्या डिलिव्हरी आहेत, परंतु ही सहाय्यक केवळ खरेदीवर देखरेख करते आणि तिचे काम चांगले करण्याचा प्रयत्न करते. कर्मचारी आपले कर्तव्य जितके चांगले पार पाडतो तितका तो इतरांच्या कामात हस्तक्षेप करतो.

परिस्थितीचे विश्लेषण करताना, बॉसच्या लक्षात आले की स्पेसशिप, रोख रक्कम आणि उत्पादने यासारख्या महत्त्वाच्या संसाधनांचा योग्य वापर केला जात नाही. त्याऐवजी, ते "तुम्ही स्नूज करा, तुम्ही गमावाल" या नियमाच्या अधीन आहेत. कोणताही कर्मचारी त्यांच्या कामासाठी आवश्यक असलेले संसाधन घेऊ शकतो, ज्यामुळे इतर कर्मचारी आणि संपूर्ण कंपनी धोक्यात येते.

काहीतरी करणे आवश्यक होते, म्हणून बॉसने मोनोलिथिक कंपनीला काही विभागांमध्ये विभाजित करण्याचा निर्णय घेतला. त्यांनी एक शिपिंग विभाग, एक विपणन विभाग, एक खरेदी विभाग, एक वित्त विभाग आणि एक यादी विभाग तयार केला. यापुढे कोणीही फक्त स्पेसशिप घेऊ शकत नाही. शिपिंग विभागाच्या प्रमुखांनी डिलिव्हरीबद्दल सर्व माहिती प्राप्त केली आणि सर्वात फायदेशीर ऑर्डरसह कुरिअरला जहाज जारी केले. याव्यतिरिक्त, गोदामाने कुरिअरला त्यांना हवा असलेला कोणताही माल घेण्याची परवानगी दिली नाही. त्याऐवजी, वेअरहाऊसमधून उत्पादने उचलणे ही एक नियंत्रित प्रक्रिया बनली. जर लवकरच खरेदी होईल हे माहीत असेल तर वित्त विभाग विपणन मोहिमेसाठी निधी जारी करणार नाही. प्रत्येक विभागाचा एक सार्वजनिक चेहरा होता - विभाग प्रमुख.प्रत्येक विभागाची अंतर्गत रचना हा स्वतःचा व्यवसाय होता. जर एखाद्या कुरिअरला उत्पादने मिळवायची असतील तर ती गोदामात नाही तर वेअरहाऊस मॅनेजरकडे गेली. जर एखादी नवीन ऑर्डर आली असेल, तर ती शिपिंग विभागाच्या प्रमुखाने ( public-facing representative) प्राप्त केली होती आणि कुरिअर ( someone not authorized to interact with the other departments) द्वारे नाही.

दुस-या शब्दात, बॉसने संसाधने आणि कृतींचे समूह (विभाग) मध्ये एकत्रित केले आणि इतरांना विभागांच्या अंतर्गत संरचनांमध्ये हस्तक्षेप करण्यास मनाई केली. आंतरविभागीय संवाद एका विशिष्ट व्यक्तीच्या माध्यमातून जावे लागे.

OOP च्या दृष्टिकोनातून , हे प्रोग्रामला ऑब्जेक्ट्समध्ये विभाजित करण्यापेक्षा अधिक काही नाही . पद्धती आणि व्हेरिएबल्सचा एक मोनोलिथिक प्रोग्राम ऑब्जेक्ट्सचा समावेश असलेला प्रोग्राम बनतो. आणि ऑब्जेक्ट्समध्ये व्हेरिएबल्स आणि पद्धती आहेत.

समस्या अशी होती की कोणताही कर्मचारी कोणत्याही संसाधनासह काम करू शकतो आणि इतर कोणत्याही कर्मचार्‍यांना आदेश देऊ शकतो, सर्व काही देखरेख किंवा नियंत्रणाशिवाय. आम्ही एक लहान निर्बंध लादले, परंतु अधिक ऑर्डर प्राप्त केली. आणि आम्ही सर्व गोष्टींवर नियंत्रण ठेवण्यास सक्षम होतो.

हे त्याच्या शुद्ध स्वरूपात विभाजन आणि विजय आहे.

2. कार्यक्रम कसे तयार केले जातात

मला आणखी एका महत्त्वाच्या मुद्द्याला स्पर्श करायचा आहे जो OOP चा आणखी एक फायदा प्रकट करतो . कार्यक्रम हे इमारतींपेक्षा प्राण्यांसारखे असतात असे तुम्हाला दिसते का? ते बांधलेले नाहीत. ते वाढले आहेत. विकास म्हणजे सतत बदल. बांधकामात, तुम्ही चांगली योजना बनवू शकता आणि त्याचे अचूक पालन करू शकता. सॉफ्टवेअर डेव्हलपमेंटच्या बाबतीत असे होत नाही.

प्रोग्रामिंगमध्ये बर्‍याचदा, आपण मूळ हेतूनुसार काहीतरी करू शकत नाही आणि आपल्याला खूप पुन्हा काम करावे लागेल. ग्राहकांच्या गरजा अधिक वेळा बदलतात.

पण जर ग्राहकाने अगदी अचूक स्पेसिफिकेशन दिले तर? त्यामुळे गोष्टी आणखी वाईट होतात. कालांतराने उत्पादनाचे काय होते ते पहा.

उत्पादनाच्या यशामुळे ग्राहक नवीन आवृत्ती आणि नंतर दुसरी आणि दुसरी आवृत्ती प्रकाशित करू इच्छितात. आणि, अर्थातच, आपल्याला फक्त विद्यमान उत्पादनामध्ये "लहान बदल" जोडण्याची आवश्यकता आहे. तर तुम्ही पाहू शकता की उत्पादनाचा विकास हा सतत बदलांचा एक क्रम आहे. फक्त वेळेचे प्रमाण वेगळे आहे. नवीन आवृत्ती आठवड्यातून एकदा, महिन्यातून एकदा किंवा दर सहा महिन्यांनी एकदा रिलीज केली जाऊ शकते.

आणि या सगळ्यातून आपण कोणता निष्कर्ष काढू शकतो? उत्पादनाची अंतर्गत रचना अशा प्रकारे राखली जाणे आवश्यक आहे जे कमीत कमी पुनर्कार्यासह महत्त्वपूर्ण (आणि किरकोळ) बदल करण्यास अनुमती देते.

ऑब्जेक्ट एकसंध

पण ते करण्याचा निर्णय घेण्यापेक्षा ते करणे कठीण आहे. आम्ही आधीच सांगितले आहे की प्रोग्राममध्ये एकमेकांशी संवाद साधणाऱ्या वस्तू असतात. चला आपल्या सर्व प्रोग्रामच्या ऑब्जेक्ट्स बोर्डवर काढू, त्यांना पॉइंट्सद्वारे दर्शवू. आणि प्रत्येक ऑब्जेक्ट (पॉइंट) मधून इतर सर्व ऑब्जेक्ट्स (पॉइंट्स) ज्याशी तो संवाद साधतो त्याकडे बाण काढू.

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

लूज-कप्लिंग तत्त्व

"सैल कपलिंगचा सिद्धांत" आहे. एक प्रोग्राम अनेक भागांमध्ये विभागलेला असतो, जे बहुतेक वेळा स्तर असतात. या लेयर्स/भागांचे तर्क त्यांच्या अंतर्गत रचनेशी घट्ट जोडलेले असतात आणि इतर लेयर्स/भागांशी अगदी सैलपणे जोडलेले असतात. स्तरांमधील परस्परसंवाद सहसा खूप नियंत्रित असतात. एक स्तर दुसऱ्या स्तराचा संदर्भ घेऊ शकतो आणि त्याच्या वर्गांचा फक्त एक छोटा उपसंच वापरू शकतो. हे "कंपनीला विभागांमध्ये विभागणे" हे तत्त्व आहे जे आपण आधी पाहिले, परंतु मोठ्या प्रमाणावर.

याचा परिणाम असा होतो की आपण एखाद्या विभागाची परिणामकारकता वाढवण्यासाठी आवश्यकतेनुसार त्याची पुनर्रचना करू शकतो आणि त्या विभागासाठी आपण आणखी लोकांना कामावर ठेवू शकतो आणि जोपर्यंत आपण आपल्या इतर विभागांशी परस्पर संवादाचा प्रोटोकॉल बदलत नाही तोपर्यंत केलेले सर्व बदल स्थानिक रहा. कोणालाही पुन्हा काहीही शिकावे लागत नाही. तुम्हाला संपूर्ण सिस्टम पुन्हा काम करण्याची गरज नाही. जर आंतरविभागीय परस्परसंवादाची यंत्रणा चांगली निवडली असेल तर प्रत्येक विभाग अशा प्रकारचे अंतर्गत ऑप्टिमायझेशन करू शकतो.

छान निवडले. पण जर ते चांगले निवडले गेले नाहीत तर? नंतर बदलाची क्षमता त्वरीत संपते आणि तुम्हाला संपूर्ण प्रणाली पुन्हा करावी लागेल. हे वेळोवेळी करावे लागते. तुम्ही भविष्याचा अंदाज लावू शकत नाही, परंतु तुम्ही रेडोची संख्या कमीत कमी ठेवू शकता.

अमूर्ततेचे तत्व

विभागांची रचना कशी केली जाते आणि ते कसे परस्परसंवाद करतात हे निवडणे हे " अमूर्ततेचे तत्त्व " आहे. प्रोग्रामिंगमध्ये, एखाद्या प्रोग्रामला घटक भागांमध्ये विभाजित करण्याचा सर्वोत्तम मार्ग आणि त्या भागांचा परस्परसंवाद कसा असावा हे निर्धारित करण्यासाठी याचा वापर केला जातो. जोपर्यंत आम्ही प्रोग्रामला वैयक्तिक वर्गांमध्ये मोडत नाही तोपर्यंत आम्ही तत्त्व पुन्हा लागू करू शकतो, परिणामी भागांना भागांमध्ये विभाजित करतो.

या भागांची अंतर्गत रचना लपवणे आणि इतर भागांशी काटेकोरपणे परस्परसंवाद मर्यादित करणे म्हणजे एन्कॅप्सुलेशन . एन्कॅप्सुलेशन आणि अॅब्स्ट्रॅक्शन हे ओओपीचे आधारस्तंभ आहेत . चांगल्या कार्यक्रमासाठी या दोन तत्त्वांचे पालन करणे आवश्यक आहे. भविष्यात, आम्ही उर्वरित तत्त्वे पाहू आणि ते कोणते फायदे देतात ते शोधू.