ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को तीन स्तंभों पर आधारित माना जाता है जो प्रोग्रामर को प्रक्रियात्मक दृष्टिकोण पर लाभ प्रदान करते हैं। वे एनकैप्सुलेशन, वंशानुक्रम और बहुरूपता हैं।वंशानुक्रम आपको ऑब्जेक्ट-उन्मुख दृष्टिकोण का उपयोग करते समय कोड दोहराव से छुटकारा पाने की अनुमति देता है। लेकिन इसका उपयोग करते हुए, आपको हमेशा एसओएलआईडी के सिद्धांतों में से एक के बारे में याद रखना चाहिए, जिसे लिस्कोव सब्सट्रेशन कहा जाता है, जो कि जब तक आप विवरण में नहीं जाते हैं, तब तक कहा जाता है कि विरासत का उपयोग केवल "रिश्ते" के कार्यान्वयन के रूप में किया जाना चाहिए। अर्थात्, वंश का वर्ग माता-पिता की "उपप्रजाति" होना चाहिए। उदाहरण के लिए, आपके पास बर्ड क्लास और उसके उपवर्ग स्पैरो (स्पैरो) और रेवेन (रैवेन) हो सकते हैं, उदाहरण के लिए, फ़्लाइट विधि को इनहेरिट (और विस्तारित या संशोधित कर सकते हैं)। हालाँकि, यदि आप पेंग्विन (पेंगुइन) नामक बर्ड का वंशज बनाते हैं और इसकी मक्खी विधि, उदाहरण के लिए, एक अपवाद को फेंकती है (क्योंकि पेंगुइन उड़ते नहीं हैं), यह लिस्कोव प्रतिस्थापन सिद्धांत का उल्लंघन करेगा। विरासत की बात करते हुए,यह भी एक महत्वपूर्ण सिद्धांत का उल्लेख करने योग्य है कि द गैंग ऑफ़ फोर (एरच गामा, रिचर्ड हेल्म, राल्फ जॉनसन, जॉन व्लाइसीड्स) अपनी पुस्तक डिज़ाइन पैटर्न: एलिजिबल ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर (1994) के तत्वों का पालन करता है, जिसमें कहा गया है कि आपको प्रयास करना चाहिए रचना का उपयोग करें (जब एक वस्तु "संभवतया" किसी अन्य वस्तु में होती है) जितना संभव हो सके विरासत में मिलने के बजाय। दरअसल, "गैंग ऑफ़ फोर" द्वारा आविष्कार किए गए कई डिज़ाइन पैटर्न ठीक इसी सिद्धांत पर आधारित हैं।दरअसल, "गैंग ऑफ़ फोर" द्वारा आविष्कार किए गए कई डिज़ाइन पैटर्न ठीक इसी सिद्धांत पर आधारित हैं।दरअसल, "गैंग ऑफ़ फोर" द्वारा आविष्कार किए गए कई डिज़ाइन पैटर्न ठीक इसी सिद्धांत पर आधारित हैं।सामान्य तौर पर, व्यवहार में, विरासत का उपयोग अक्सर ऐसा कहने के लिए नहीं किया जाता है, यहां तक कि इस तथ्य के बावजूद कि ज्यादातर मामलों में अच्छे प्रोग्रामर इसे एक रचना के साथ प्रतिस्थापित करते हैं। अधिक बार एक इंटरफ़ेस के कई कार्यान्वयन होते हैं, जो ग्राहक वर्गों में निर्भरता के रूप में निर्दिष्ट होते हैं। जो बदले में आपको OOP के दूसरे स्तंभ का उपयोग करने की अनुमति देता है - बहुरूपता। जो आपको क्लाइंट कोड के लिए विभिन्न निर्भरता कार्यान्वयन पास करने की अनुमति देता है। इस तथ्य के कारण कि प्रेषित निर्भरताओं में एक ही इंटरफ़ेस है, क्लाइंट (इंटरफ़ेस पर निर्भर करता है) को परवाह नहीं है कि ऑब्जेक्ट क्या आया था और यह प्रोग्रामर को बदलने की अनुमति देता है, प्रोग्राम के निष्पादन के दौरान, किस तरह (इंटरफ़ेस का कार्यान्वयन) अंतिम कार्य हल किया जाएगा। OOP की बात करें तो कोई भी एनकैप्सुलेशन का उल्लेख नहीं कर सकता है। यह OOP का एक अनिवार्य तत्व है,जो विकास की जटिलता को कम करते हुए निम्न-स्तरीय कार्यान्वयन विवरणों को छिपाने के लिए सार बनाने की क्षमता प्रदान करता है। कार्यान्वयन के विवरण निजी और संरक्षित तरीकों तक पहुंच संशोधक द्वारा छिपाए जाते हैं। कक्षाएं बनाते समय, आपको उन्हें बनाने की आवश्यकता होती है ताकि उनके इंटरफेस (सुलभ सार्वजनिक तरीके) एक सुसंगत अमूर्तता प्रदान करें,अन्यथा यह अब OOP (!) नहीं है । उदाहरण के लिए, मान लें कि हम एक ऐसा कार्यक्रम विकसित कर रहे हैं जो परमाणु रिएक्टर की शीतलन प्रणाली को नियंत्रित करता है। तब इंटरफ़ेस का सहमत अमूर्त इस प्रकार देख सकता है।CoolingSystem::getTemperature()
CoolingSystem::SetCirculationRate($rate)
CoolingSystem::OpenValve($valveNumber)
CoolingSystem::CloseValve($valveNumber)
एक संक्षिप्त अभिव्यंजक इंटरफ़ेस के लिए धन्यवाद, जो एक सुसंगत अमूर्तता का निर्माण करता है, हम निम्न-स्तरीय कार्यान्वयन विवरणों के बारे में थोड़ा विचार किए बिना रिएक्टर कूलिंग सिस्टम के साथ काम कर सकते हैं जो चयनित तकनीक की विशेषता हैं। अमूर्त का उपयोग विकसित प्रणाली की जटिलता को काफी कम कर सकता है। और जटिलता के खिलाफ लड़ाई विकास की मुख्य तकनीकी अनिवार्यता है। यहाँ संगत सार के कुछ और उदाहरण हैं:गति नियंत्रण प्रणाली:- गति सेट करें
- वर्तमान सेटिंग्स प्राप्त करें
- पिछले गति मान को पुनर्स्थापित करें
- सिस्टम अक्षम करें
कॉफी बनाने की मशीन:- सक्षम करें
- बंद करना
- गति सेट करें
- कॉफी पीसना शुरू करें
- कॉफी पीसना बंद करें
ईंधन टैंक:- ईंधन टैंक भरें
- नाली का ईंधन
- ईंधन टैंक की क्षमता प्राप्त करें
- ईंधन टैंक की स्थिति प्राप्त करें
दीपक:किसी ऑब्जेक्ट के इंटरफ़ेस को डिज़ाइन करते समय, केवल उन तरीकों को सार्वजनिक करें, जिन्हें क्लाइंट को प्रबंधित करने की आवश्यकता है, बाकी सब कुछ छिपाते हुए। नतीजतन, आपको ब्लैक बॉक्स मिलना चाहिए, जिनमें से डिवाइस को आप कोड कोड जोड़े जाने के बाद भूल सकते हैं। यह दृष्टिकोण विकसित प्रणाली की जटिलता को काफी कम कर सकता है।