वस्तु उन्मुख डिजाइन: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
वस्तु में एनकैप्सुलेशन डेटा और प्रक्रियाओं को एक इकाई का प्रतिनिधित्व करने के लिए एक साथ समूहीकृत किया जाता है। 'ऑब्जेक्ट इंटरफ़ेस' को परिभाषित करता है कि ऑब्जेक्ट के साथ कैसे इंटरैक्ट किया जा सकता है। वस्तु-उन्मुख कार्यक्रम का वर्णन इन वस्तुओं की परस्पर क्रिया द्वारा किया जाता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन ऑब्जेक्ट-ओरिएंटेड विश्लेषण के दौरान पहचानी गई और प्रलेखित समस्या को हल करने के लिए ऑब्जेक्ट्स और उनकी इंटरैक्शन को परिभाषित करने का अनुशासन है। | वस्तु में एनकैप्सुलेशन डेटा और प्रक्रियाओं को एक इकाई का प्रतिनिधित्व करने के लिए एक साथ समूहीकृत किया जाता है। 'ऑब्जेक्ट इंटरफ़ेस' को परिभाषित करता है कि ऑब्जेक्ट के साथ कैसे इंटरैक्ट किया जा सकता है। वस्तु-उन्मुख कार्यक्रम का वर्णन इन वस्तुओं की परस्पर क्रिया द्वारा किया जाता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन ऑब्जेक्ट-ओरिएंटेड विश्लेषण के दौरान पहचानी गई और प्रलेखित समस्या को हल करने के लिए ऑब्जेक्ट्स और उनकी इंटरैक्शन को परिभाषित करने का अनुशासन है। | ||
[[ कक्षा आधारित प्रोग्रामिंग ]]का विवरण इस प्रकार है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के वर्ग-आधारित उपसमुच्चय का विवरण इस प्रकार है, जिसमें [[प्रोटोटाइप-आधारित प्रोग्रामिंग]] सम्मलित नहीं है। ओरिएंटेड डिज़ाइन की एक विधि है जिसमें ऑब्जेक्ट-ओरिएंटेड अपघटन की प्रक्रिया | [[ कक्षा आधारित प्रोग्रामिंग ]]का विवरण इस प्रकार है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के वर्ग-आधारित उपसमुच्चय का विवरण इस प्रकार है, जिसमें [[प्रोटोटाइप-आधारित प्रोग्रामिंग]] सम्मलित नहीं है। ओरिएंटेड डिज़ाइन की एक विधि है जिसमें ऑब्जेक्ट-ओरिएंटेड अपघटन की प्रक्रिया सम्मालित है और डिज़ाइन के तहत प्रणाली के तार्किक और भौतिक दोनों के साथ-साथ स्थिती और गतिशील मॉडल दोनों को चित्रित करने के लिए संकेत चिन्ह होता है। | ||
== वस्तु-उन्मुख डिजाइन विषय == | == वस्तु-उन्मुख डिजाइन विषय == | ||
=== वस्तु-उन्मुख डिजाइन के लिए इनपुट (स्रोत) === | === वस्तु-उन्मुख डिजाइन के लिए इनपुट (स्रोत) === | ||
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के लिए इनपुट ऑब्जेक्ट-ओरिएंटेड विश्लेषण और डिज़ाइन | ऑब्जेक्ट-ओरिएंटेड विश्लेषण के आउटपुट द्वारा प्रदान किया जाता है। एहसास करें कि ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के इनपुट के रूप में काम करने के लिए एक आउटपुट आर्टिफैक्ट को पूरी तरह से विकसित करने की आवश्यकता नहीं है; विश्लेषण और डिजाइन समानांतर में हो सकते हैं, और व्यवहार में एक गतिविधि के परिणाम दूसरे को पुनरावृत्त प्रक्रिया के माध्यम से एक संक्षिप्त प्रतिक्रिया चक्र में खिला सकते हैं। विश्लेषण और डिजाइन दोनों को वृद्धिशील रूप से किया जा सकता है, और कलाकृतियों को एक शॉट में पूरी तरह से विकसित करने | ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के लिए इनपुट ऑब्जेक्ट-ओरिएंटेड विश्लेषण और डिज़ाइन | ऑब्जेक्ट-ओरिएंटेड विश्लेषण के आउटपुट द्वारा प्रदान किया जाता है। एहसास करें कि ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के इनपुट के रूप में काम करने के लिए एक आउटपुट आर्टिफैक्ट को पूरी तरह से विकसित करने की आवश्यकता नहीं है; विश्लेषण और डिजाइन समानांतर में हो सकते हैं, और व्यवहार में एक गतिविधि के परिणाम दूसरे को पुनरावृत्त प्रक्रिया के माध्यम से एक संक्षिप्त प्रतिक्रिया चक्र में खिला सकते हैं। विश्लेषण और डिजाइन दोनों को वृद्धिशील रूप से किया जा सकता है, और कलाकृतियों को एक शॉट में पूरी तरह से विकसित करने अतिरिक्त लगातार विकसित किया जा सकता है। | ||
वस्तु-उन्मुख डिज़ाइन के लिए कुछ विशिष्ट इनपुट कलाकृतियाँ हैं: | वस्तु-उन्मुख डिज़ाइन के लिए कुछ विशिष्ट इनपुट कलाकृतियाँ हैं: | ||
* [[वैचारिक मॉडल (कंप्यूटर विज्ञान)]]: वस्तु-उन्मुख विश्लेषण का परिणाम, यह [[डोमेन (सॉफ्टवेयर इंजीनियरिंग)]] में अवधारणाओं को पकड़ता है। वैचारिक मॉडल को स्पष्ट रूप से कार्यान्वयन विवरण से स्वतंत्र होने के लिए चुना गया है, जैसे कि कॉन्करेंसी (कंप्यूटर साइंस) या डेटा स्टोरेज। | * [[वैचारिक मॉडल (कंप्यूटर विज्ञान)]]: वस्तु-उन्मुख विश्लेषण का परिणाम, यह [[डोमेन (सॉफ्टवेयर इंजीनियरिंग)]] में अवधारणाओं को पकड़ता है। वैचारिक मॉडल को स्पष्ट रूप से कार्यान्वयन विवरण से स्वतंत्र होने के लिए चुना गया है, जैसे कि कॉन्करेंसी (कंप्यूटर साइंस) या डेटा स्टोरेज। | ||
* उपयोग मामला: घटनाओं के अनुक्रमों का वर्णन, जो एक साथ लिया जाता है, एक प्रणाली को कुछ उपयोगी करने के लिए प्रेरित करता है। प्रत्येक उपयोग मामला एक या एक से अधिक [[परिदृश्य (कंप्यूटिंग)]] प्रदान करता है जो बताता है कि विशिष्ट व्यावसायिक लक्ष्य या कार्य को प्राप्त करने के लिए | * उपयोग मामला: घटनाओं के अनुक्रमों का वर्णन, जो एक साथ लिया जाता है, एक प्रणाली को कुछ उपयोगी करने के लिए प्रेरित करता है। प्रत्येक उपयोग मामला एक या एक से अधिक [[परिदृश्य (कंप्यूटिंग)]] प्रदान करता है जो बताता है कि विशिष्ट व्यावसायिक लक्ष्य या कार्य को प्राप्त करने के लिए प्रणाली को अभिनेताओं नामक उपयोगकर्ताओं के साथ कैसे बातचीत करनी चाहिए। केस अभिनेता अंतिम उपयोगकर्ता या अन्य प्रणाली हो सकते हैं। कई परिस्थितियों में उपयोग के मामलों को आगे उपयोग केस आरेख में विस्तृत किया जाता [[स्थिति चित्र का उपयोग]] का उपयोग अभिनेता (उपयोगकर्ता या अन्य प्रणाली) और उनके द्वारा की जाने वाली प्रक्रियाओं की पहचान करने के लिए किया जाता है। | ||
* [[ सिस्टम अनुक्रम आरेख ]]: एक | * [[ सिस्टम अनुक्रम आरेख | प्रणाली अनुक्रम आरेख]] : एक प्रणाली सीक्वेंस डायग्राम (SSD) एक तस्वीर है, जो उपयोग के मामले के एक विशेष परिदृश्य के लिए, बाहरी अभिनेताओं द्वारा उत्पन्न होने वाली घटनाओं, उनके क्रम और संभावित इंटर-प्रणाली घटनाओं को दिखाती है। | ||
* उपयोगकर्ता इंटरफ़ेस दस्तावेज़ीकरण (यदि लागू हो): दस्तावेज़ जो अंतिम उत्पाद के उपयोगकर्ता इंटरफ़ेस के स्वरूप और अनुभव को दर्शाता है और उसका वर्णन करता है। यह होना अनिवार्य नहीं है, लेकिन यह अंतिम उत्पाद की कल्पना करने में मदद करता है और इसलिए डिजाइनर की मदद करता है। | * उपयोगकर्ता इंटरफ़ेस दस्तावेज़ीकरण (यदि लागू हो): दस्तावेज़ जो अंतिम उत्पाद के उपयोगकर्ता इंटरफ़ेस के स्वरूप और अनुभव को दर्शाता है और उसका वर्णन करता है। यह होना अनिवार्य नहीं है, लेकिन यह अंतिम उत्पाद की कल्पना करने में मदद करता है और इसलिए डिजाइनर की मदद करता है। | ||
* [[संबंधपरक डेटा मॉडल]] (यदि लागू हो): एक डेटा मॉडल एक सार मॉडल है जो बताता है कि डेटा का प्रतिनिधित्व और उपयोग कैसे किया जाता है। यदि [[ वस्तु डेटाबेस ]] का उपयोग नहीं किया जाता है, तो रिलेशनल डेटा मॉडल आमतौर पर डिज़ाइन से पहले बनाया जाना चाहिए, क्योंकि [[ऑब्जेक्ट-रिलेशनल मैपिंग]] के लिए चुनी गई रणनीति OO डिज़ाइन प्रक्रिया का एक आउटपुट है। हालाँकि, रिलेशनल डेटा मॉडल और ऑब्जेक्ट-ओरिएंटेड डिज़ाइन कलाकृतियों को समानांतर में विकसित करना संभव है, और एक आर्टिफैक्ट की वृद्धि अन्य कलाकृतियों के शोधन को प्रोत्साहित कर सकती है। | * [[संबंधपरक डेटा मॉडल]] (यदि लागू हो): एक डेटा मॉडल एक सार मॉडल है जो बताता है कि डेटा का प्रतिनिधित्व और उपयोग कैसे किया जाता है। यदि [[ वस्तु डेटाबेस ]] का उपयोग नहीं किया जाता है, तो रिलेशनल डेटा मॉडल आमतौर पर डिज़ाइन से पहले बनाया जाना चाहिए, क्योंकि [[ऑब्जेक्ट-रिलेशनल मैपिंग]] के लिए चुनी गई रणनीति OO डिज़ाइन प्रक्रिया का एक आउटपुट है। हालाँकि, रिलेशनल डेटा मॉडल और ऑब्जेक्ट-ओरिएंटेड डिज़ाइन कलाकृतियों को समानांतर में विकसित करना संभव है, और एक आर्टिफैक्ट की वृद्धि अन्य कलाकृतियों के शोधन को प्रोत्साहित कर सकती है। | ||
| Line 32: | Line 32: | ||
* वस्तुओं की माताओं को परिभाषित करना, वैचारिक मॉडल (कंप्यूटर विज्ञान) से [[वर्ग आरेख]] बनाना: आमतौर पर इकाई को कक्षा में मैप करना। | * वस्तुओं की माताओं को परिभाषित करना, वैचारिक मॉडल (कंप्यूटर विज्ञान) से [[वर्ग आरेख]] बनाना: आमतौर पर इकाई को कक्षा में मैप करना। | ||
* पहचान [[विशेषता (कंप्यूटिंग)]]। | * पहचान [[विशेषता (कंप्यूटिंग)]]। | ||
* [[डिज़ाइन पैटर्न]] का उपयोग करें (यदि लागू हो): एक डिज़ाइन पैटर्न एक पूर्ण डिज़ाइन नहीं है, यह एक संदर्भ में एक सामान्य समस्या के समाधान का विवरण है।<ref name="gof">{{cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |year=1995 |publisher=Addison-Wesley |isbn=0-201-63361-2 |url-access=registration |url=https://archive.org/details/designpatternsel00gamm }}</ref> डिज़ाइन पैटर्न का उपयोग करने का मुख्य लाभ यह है कि इसे कई अनुप्रयोगों में पुन: उपयोग किया जा सकता है। इसे किसी समस्या को हल करने के लिए एक टेम्पलेट के रूप में भी सोचा जा सकता है जिसका उपयोग कई अलग-अलग स्थितियों और/या अनुप्रयोगों में किया जा सकता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पैटर्न आमतौर पर अंतिम एप्लिकेशन क्लासेस या ऑब्जेक्ट्स को | * [[डिज़ाइन पैटर्न]] का उपयोग करें (यदि लागू हो): एक डिज़ाइन पैटर्न एक पूर्ण डिज़ाइन नहीं है, यह एक संदर्भ में एक सामान्य समस्या के समाधान का विवरण है।<ref name="gof">{{cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |year=1995 |publisher=Addison-Wesley |isbn=0-201-63361-2 |url-access=registration |url=https://archive.org/details/designpatternsel00gamm }}</ref> डिज़ाइन पैटर्न का उपयोग करने का मुख्य लाभ यह है कि इसे कई अनुप्रयोगों में पुन: उपयोग किया जा सकता है। इसे किसी समस्या को हल करने के लिए एक टेम्पलेट के रूप में भी सोचा जा सकता है जिसका उपयोग कई अलग-अलग स्थितियों और/या अनुप्रयोगों में किया जा सकता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पैटर्न आमतौर पर अंतिम एप्लिकेशन क्लासेस या ऑब्जेक्ट्स को सम्मालित किए बिना निर्दिष्ट किए बिना, कक्षाओं या ऑब्जेक्ट्स के बीच संबंध और इंटरैक्शन दिखाते हैं। | ||
* [[ आवेदन ढांचा ]] को परिभाषित करें (यदि लागू हो): एप्लिकेशन फ्रेमवर्क आमतौर पर पुस्तकालयों या कक्षाओं का एक सेट होता है जो किसी विशिष्ट ऑपरेटिंग | * [[ आवेदन ढांचा ]] को परिभाषित करें (यदि लागू हो): एप्लिकेशन फ्रेमवर्क आमतौर पर पुस्तकालयों या कक्षाओं का एक सेट होता है जो किसी विशिष्ट ऑपरेटिंग प्रणाली के लिए किसी एप्लिकेशन की मानक संरचना को लागू करने के लिए उपयोग किया जाता है। बड़ी मात्रा में पुन: प्रयोज्य कोड को एक ढांचे में बांधकर, विकासक के लिए बहुत समय बचाया जाता है, क्योंकि वह विकसित होने वाले प्रत्येक नए एप्लिकेशन के लिए बड़ी मात्रा में मानक कोड को फिर से लिखने के कार्य से बच जाता है। | ||
* लगातार वस्तुओं / डेटा की पहचान करें (यदि लागू हो): उन वस्तुओं की पहचान करें जिन्हें एप्लिकेशन के एक रनटाइम से अधिक समय तक चलना है। यदि एक [[ संबंध का डेटाबेस ]] का उपयोग किया जाता है, तो ऑब्जेक्ट रिलेशन मैपिंग डिज़ाइन करें। | * लगातार वस्तुओं / डेटा की पहचान करें (यदि लागू हो): उन वस्तुओं की पहचान करें जिन्हें एप्लिकेशन के एक रनटाइम से अधिक समय तक चलना है। यदि एक [[ संबंध का डेटाबेस ]] का उपयोग किया जाता है, तो ऑब्जेक्ट रिलेशन मैपिंग डिज़ाइन करें। | ||
* दूरस्थ वस्तुओं को पहचानें और परिभाषित करें (यदि लागू हो)। | * दूरस्थ वस्तुओं को पहचानें और परिभाषित करें (यदि लागू हो)। | ||
=== ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का आउटपुट (डिलिवरेबल्स) === | === ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का आउटपुट (डिलिवरेबल्स) === | ||
* [[अनुक्रम आरेख]] - | * [[अनुक्रम आरेख]] - प्रणाली घटनाओं को संभालने वाली विशिष्ट वस्तुओं को जोड़ने के लिए प्रणाली अनुक्रम आरेख का विस्तार करें। | ||
: एक अनुक्रम आरेख दिखाता है, समानांतर लंबवत रेखाओं के रूप में, विभिन्न प्रक्रियाएं या ऑब्जेक्ट जो एक साथ रहते हैं, और, क्षैतिज तीरों के रूप में, उनके बीच संदेशों का आदान-प्रदान होता है, जिस क्रम में वे होते हैं। | : एक अनुक्रम आरेख दिखाता है, समानांतर लंबवत रेखाओं के रूप में, विभिन्न प्रक्रियाएं या ऑब्जेक्ट जो एक साथ रहते हैं, और, क्षैतिज तीरों के रूप में, उनके बीच संदेशों का आदान-प्रदान होता है, जिस क्रम में वे होते हैं। | ||
* क्लास डायग्राम - एक क्लास डायग्राम एक प्रकार की स्टैटिक स्ट्रक्चर [[ एकीकृत मॉडलिंग भाषा ]] डायग्राम है, जो | * क्लास डायग्राम - एक क्लास डायग्राम एक प्रकार की स्टैटिक स्ट्रक्चर [[ एकीकृत मॉडलिंग भाषा ]] डायग्राम है, जो प्रणाली की कक्षाओं, उसकी विशेषताओं और कक्षाओं के बीच संबंधों को दिखाकर प्रणाली की संरचना का वर्णन करता है। अनुक्रम आरेखों के विकास के माध्यम से पहचाने गए संदेश और कक्षाएं प्रणाली के वैश्विक वर्ग आरेख के स्वत: निर्माण के लिए इनपुट के रूप में काम कर सकती हैं। | ||
=== कुछ डिजाइन सिद्धांत और रणनीतियाँ === | === कुछ डिजाइन सिद्धांत और रणनीतियाँ === | ||
* निर्भरता | * निर्भरता अंतःक्षेपण : मूल विचार यह है कि यदि कोई वस्तु किसी अन्य वस्तु के उदाहरण पर निर्भर करती है तो आवश्यक वस्तु को आश्रित वस्तु में "इंजेक्ट" किया जाता है; उदाहरण के लिए, एक डेटाबेस कनेक्शन को आंतरिक रूप से बनाने अतिरिक्त [[कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] के तर्क के रूप में पारित किया जा रहा है। | ||
* [[चक्रीय निर्भरता सिद्धांत]]: | * [[चक्रीय निर्भरता सिद्धांत]]: संकुल या घटक के निर्भरता ग्राफ (ग्रैन्युलैरिटी एक विकासक के लिए काम के दायरे पर निर्भर करता है) में कोई चक्र नहीं होना चाहिए। इसे निर्देशित चक्रीय ग्राफ के रूप में भी जाना जाता है।<ref name="objectMentor">{{cite web |title=What Is Object-Oriented Design? |publisher=Object Mentor |url=http://www.objectmentor.com/omSolutions/oops_what.html |access-date=2007-07-03 |archive-url=https://web.archive.org/web/20070630045531/http://www.objectmentor.com/omSolutions/oops_what.html |archive-date=2007-06-30 |url-status=dead }}</ref> उदाहरण के लिए, संकुल सी संकुल बी पर निर्भर करता है, जो संकुल ए पर निर्भर करता है। यदि संकुल ए भी संकुल सी पर निर्भर करता है, तो आपके पास एक चक्र होगा। | ||
* [[समग्र पुन: उपयोग सिद्धांत]]: पक्ष बहुरूपता | * [[समग्र पुन: उपयोग सिद्धांत]]: पक्ष बहुरूपता वंशानुक्रम पर वस्तुओं की वस्तु संरचना।<ref name="gof"/> | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[वर्ग-जिम्मेदारी-सहयोग कार्ड]] | * [[वर्ग-जिम्मेदारी-सहयोग कार्ड]] | ||
Revision as of 15:55, 12 March 2023
 | This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. (October 2021) (Learn how and when to remove this template message) |
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन (OOD) एक सॉफ़्टवेयर समस्या को हल करने के उद्देश्य से ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की योजना बनाने की प्रक्रिया है। यह सॉफ्टवेर डिज़ाइन की एक विधि है।
वस्तु में एनकैप्सुलेशन डेटा और प्रक्रियाओं को एक इकाई का प्रतिनिधित्व करने के लिए एक साथ समूहीकृत किया जाता है। 'ऑब्जेक्ट इंटरफ़ेस' को परिभाषित करता है कि ऑब्जेक्ट के साथ कैसे इंटरैक्ट किया जा सकता है। वस्तु-उन्मुख कार्यक्रम का वर्णन इन वस्तुओं की परस्पर क्रिया द्वारा किया जाता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन ऑब्जेक्ट-ओरिएंटेड विश्लेषण के दौरान पहचानी गई और प्रलेखित समस्या को हल करने के लिए ऑब्जेक्ट्स और उनकी इंटरैक्शन को परिभाषित करने का अनुशासन है।
कक्षा आधारित प्रोग्रामिंग का विवरण इस प्रकार है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के वर्ग-आधारित उपसमुच्चय का विवरण इस प्रकार है, जिसमें प्रोटोटाइप-आधारित प्रोग्रामिंग सम्मलित नहीं है। ओरिएंटेड डिज़ाइन की एक विधि है जिसमें ऑब्जेक्ट-ओरिएंटेड अपघटन की प्रक्रिया सम्मालित है और डिज़ाइन के तहत प्रणाली के तार्किक और भौतिक दोनों के साथ-साथ स्थिती और गतिशील मॉडल दोनों को चित्रित करने के लिए संकेत चिन्ह होता है।
वस्तु-उन्मुख डिजाइन विषय
वस्तु-उन्मुख डिजाइन के लिए इनपुट (स्रोत)
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के लिए इनपुट ऑब्जेक्ट-ओरिएंटेड विश्लेषण और डिज़ाइन | ऑब्जेक्ट-ओरिएंटेड विश्लेषण के आउटपुट द्वारा प्रदान किया जाता है। एहसास करें कि ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के इनपुट के रूप में काम करने के लिए एक आउटपुट आर्टिफैक्ट को पूरी तरह से विकसित करने की आवश्यकता नहीं है; विश्लेषण और डिजाइन समानांतर में हो सकते हैं, और व्यवहार में एक गतिविधि के परिणाम दूसरे को पुनरावृत्त प्रक्रिया के माध्यम से एक संक्षिप्त प्रतिक्रिया चक्र में खिला सकते हैं। विश्लेषण और डिजाइन दोनों को वृद्धिशील रूप से किया जा सकता है, और कलाकृतियों को एक शॉट में पूरी तरह से विकसित करने अतिरिक्त लगातार विकसित किया जा सकता है।
वस्तु-उन्मुख डिज़ाइन के लिए कुछ विशिष्ट इनपुट कलाकृतियाँ हैं:
- वैचारिक मॉडल (कंप्यूटर विज्ञान): वस्तु-उन्मुख विश्लेषण का परिणाम, यह डोमेन (सॉफ्टवेयर इंजीनियरिंग) में अवधारणाओं को पकड़ता है। वैचारिक मॉडल को स्पष्ट रूप से कार्यान्वयन विवरण से स्वतंत्र होने के लिए चुना गया है, जैसे कि कॉन्करेंसी (कंप्यूटर साइंस) या डेटा स्टोरेज।
- उपयोग मामला: घटनाओं के अनुक्रमों का वर्णन, जो एक साथ लिया जाता है, एक प्रणाली को कुछ उपयोगी करने के लिए प्रेरित करता है। प्रत्येक उपयोग मामला एक या एक से अधिक परिदृश्य (कंप्यूटिंग) प्रदान करता है जो बताता है कि विशिष्ट व्यावसायिक लक्ष्य या कार्य को प्राप्त करने के लिए प्रणाली को अभिनेताओं नामक उपयोगकर्ताओं के साथ कैसे बातचीत करनी चाहिए। केस अभिनेता अंतिम उपयोगकर्ता या अन्य प्रणाली हो सकते हैं। कई परिस्थितियों में उपयोग के मामलों को आगे उपयोग केस आरेख में विस्तृत किया जाता स्थिति चित्र का उपयोग का उपयोग अभिनेता (उपयोगकर्ता या अन्य प्रणाली) और उनके द्वारा की जाने वाली प्रक्रियाओं की पहचान करने के लिए किया जाता है।
- प्रणाली अनुक्रम आरेख : एक प्रणाली सीक्वेंस डायग्राम (SSD) एक तस्वीर है, जो उपयोग के मामले के एक विशेष परिदृश्य के लिए, बाहरी अभिनेताओं द्वारा उत्पन्न होने वाली घटनाओं, उनके क्रम और संभावित इंटर-प्रणाली घटनाओं को दिखाती है।
- उपयोगकर्ता इंटरफ़ेस दस्तावेज़ीकरण (यदि लागू हो): दस्तावेज़ जो अंतिम उत्पाद के उपयोगकर्ता इंटरफ़ेस के स्वरूप और अनुभव को दर्शाता है और उसका वर्णन करता है। यह होना अनिवार्य नहीं है, लेकिन यह अंतिम उत्पाद की कल्पना करने में मदद करता है और इसलिए डिजाइनर की मदद करता है।
- संबंधपरक डेटा मॉडल (यदि लागू हो): एक डेटा मॉडल एक सार मॉडल है जो बताता है कि डेटा का प्रतिनिधित्व और उपयोग कैसे किया जाता है। यदि वस्तु डेटाबेस का उपयोग नहीं किया जाता है, तो रिलेशनल डेटा मॉडल आमतौर पर डिज़ाइन से पहले बनाया जाना चाहिए, क्योंकि ऑब्जेक्ट-रिलेशनल मैपिंग के लिए चुनी गई रणनीति OO डिज़ाइन प्रक्रिया का एक आउटपुट है। हालाँकि, रिलेशनल डेटा मॉडल और ऑब्जेक्ट-ओरिएंटेड डिज़ाइन कलाकृतियों को समानांतर में विकसित करना संभव है, और एक आर्टिफैक्ट की वृद्धि अन्य कलाकृतियों के शोधन को प्रोत्साहित कर सकती है।
वस्तु-उन्मुख अवधारणाएँ
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की पाँच बुनियादी अवधारणाएँ कार्यान्वयन स्तर की विशेषताएं हैं जो प्रोग्रामिंग भाषा में निर्मित होती हैं। इन सुविधाओं को अक्सर इन सामान्य नामों से जाना जाता है:
- ऑब्जेक्ट (कंप्यूटर साइंस)|ऑब्जेक्ट/क्लास: डेटा पर कार्य करने वाले तरीकों या कार्यों के साथ डेटा संरचनाओं का एक तंग युग्मन या जुड़ाव। इसे एक वर्ग, या वस्तु कहा जाता है (एक वर्ग के आधार पर एक वस्तु बनाई जाती है)। प्रत्येक वस्तु एक अलग कार्य करती है। यह इसके गुणों से परिभाषित होता है कि यह क्या है और यह क्या कर सकता है। एक वस्तु एक वर्ग का हिस्सा हो सकती है, जो समान वस्तुओं का एक समूह है।
- जानकारी छुपाना: वस्तु के कुछ घटकों को बाहरी संस्थाओं से बचाने की क्षमता। यह भाषा के खोजशब्दों द्वारा महसूस किया जाता है ताकि एक चर को निजी घोषित किया जा सके या स्वामी वर्ग के लिए संरक्षित किया जा सके।
- वंशानुक्रम (कंप्यूटर विज्ञान): एक वर्ग के लिए दूसरे वर्ग की कार्यक्षमता को बढ़ाने या ओवरराइड करने की क्षमता। तथाकथित उपवर्ग में एक पूरा खंड होता है जो सुपरक्लास से प्राप्त (विरासत में मिला) होता है और फिर इसके कार्यों और डेटा का अपना सेट होता है।
- इंटरफ़ेस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग): किसी विधि के कार्यान्वयन को स्थगित करने की क्षमता। उन्हें लागू किए बिना कार्यों या विधियों के हस्ताक्षर को परिभाषित करने की क्षमता।
- बहुरूपता (कंप्यूटर विज्ञान) (विशेष रूप से, उपप्रकार): किसी वस्तु को उसके उप-विषयों से बदलने की क्षमता। किसी वस्तु-चर की न केवल उस वस्तु को, बल्कि उसके सभी उप-वस्तुओं को समाहित करने की क्षमता।
अवधारणाओं को डिजाइन करना
- वस्तुओं की माताओं को परिभाषित करना, वैचारिक मॉडल (कंप्यूटर विज्ञान) से वर्ग आरेख बनाना: आमतौर पर इकाई को कक्षा में मैप करना।
- पहचान विशेषता (कंप्यूटिंग)।
- डिज़ाइन पैटर्न का उपयोग करें (यदि लागू हो): एक डिज़ाइन पैटर्न एक पूर्ण डिज़ाइन नहीं है, यह एक संदर्भ में एक सामान्य समस्या के समाधान का विवरण है।[1] डिज़ाइन पैटर्न का उपयोग करने का मुख्य लाभ यह है कि इसे कई अनुप्रयोगों में पुन: उपयोग किया जा सकता है। इसे किसी समस्या को हल करने के लिए एक टेम्पलेट के रूप में भी सोचा जा सकता है जिसका उपयोग कई अलग-अलग स्थितियों और/या अनुप्रयोगों में किया जा सकता है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पैटर्न आमतौर पर अंतिम एप्लिकेशन क्लासेस या ऑब्जेक्ट्स को सम्मालित किए बिना निर्दिष्ट किए बिना, कक्षाओं या ऑब्जेक्ट्स के बीच संबंध और इंटरैक्शन दिखाते हैं।
- आवेदन ढांचा को परिभाषित करें (यदि लागू हो): एप्लिकेशन फ्रेमवर्क आमतौर पर पुस्तकालयों या कक्षाओं का एक सेट होता है जो किसी विशिष्ट ऑपरेटिंग प्रणाली के लिए किसी एप्लिकेशन की मानक संरचना को लागू करने के लिए उपयोग किया जाता है। बड़ी मात्रा में पुन: प्रयोज्य कोड को एक ढांचे में बांधकर, विकासक के लिए बहुत समय बचाया जाता है, क्योंकि वह विकसित होने वाले प्रत्येक नए एप्लिकेशन के लिए बड़ी मात्रा में मानक कोड को फिर से लिखने के कार्य से बच जाता है।
- लगातार वस्तुओं / डेटा की पहचान करें (यदि लागू हो): उन वस्तुओं की पहचान करें जिन्हें एप्लिकेशन के एक रनटाइम से अधिक समय तक चलना है। यदि एक संबंध का डेटाबेस का उपयोग किया जाता है, तो ऑब्जेक्ट रिलेशन मैपिंग डिज़ाइन करें।
- दूरस्थ वस्तुओं को पहचानें और परिभाषित करें (यदि लागू हो)।
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का आउटपुट (डिलिवरेबल्स)
- अनुक्रम आरेख - प्रणाली घटनाओं को संभालने वाली विशिष्ट वस्तुओं को जोड़ने के लिए प्रणाली अनुक्रम आरेख का विस्तार करें।
- एक अनुक्रम आरेख दिखाता है, समानांतर लंबवत रेखाओं के रूप में, विभिन्न प्रक्रियाएं या ऑब्जेक्ट जो एक साथ रहते हैं, और, क्षैतिज तीरों के रूप में, उनके बीच संदेशों का आदान-प्रदान होता है, जिस क्रम में वे होते हैं।
- क्लास डायग्राम - एक क्लास डायग्राम एक प्रकार की स्टैटिक स्ट्रक्चर एकीकृत मॉडलिंग भाषा डायग्राम है, जो प्रणाली की कक्षाओं, उसकी विशेषताओं और कक्षाओं के बीच संबंधों को दिखाकर प्रणाली की संरचना का वर्णन करता है। अनुक्रम आरेखों के विकास के माध्यम से पहचाने गए संदेश और कक्षाएं प्रणाली के वैश्विक वर्ग आरेख के स्वत: निर्माण के लिए इनपुट के रूप में काम कर सकती हैं।
कुछ डिजाइन सिद्धांत और रणनीतियाँ
- निर्भरता अंतःक्षेपण : मूल विचार यह है कि यदि कोई वस्तु किसी अन्य वस्तु के उदाहरण पर निर्भर करती है तो आवश्यक वस्तु को आश्रित वस्तु में "इंजेक्ट" किया जाता है; उदाहरण के लिए, एक डेटाबेस कनेक्शन को आंतरिक रूप से बनाने अतिरिक्त कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) के तर्क के रूप में पारित किया जा रहा है।
- चक्रीय निर्भरता सिद्धांत: संकुल या घटक के निर्भरता ग्राफ (ग्रैन्युलैरिटी एक विकासक के लिए काम के दायरे पर निर्भर करता है) में कोई चक्र नहीं होना चाहिए। इसे निर्देशित चक्रीय ग्राफ के रूप में भी जाना जाता है।[2] उदाहरण के लिए, संकुल सी संकुल बी पर निर्भर करता है, जो संकुल ए पर निर्भर करता है। यदि संकुल ए भी संकुल सी पर निर्भर करता है, तो आपके पास एक चक्र होगा।
- समग्र पुन: उपयोग सिद्धांत: पक्ष बहुरूपता वंशानुक्रम पर वस्तुओं की वस्तु संरचना।[1]
यह भी देखें
- वर्ग-जिम्मेदारी-सहयोग कार्ड
- GRASP (ऑब्जेक्ट-ओरिएंटेड डिज़ाइन)
- ठोस
- आईडीईएफ4
- वस्तु-उन्मुख विश्लेषण और डिजाइन | वस्तु-उन्मुख विश्लेषण
- ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग
संदर्भ
- ↑ 1.0 1.1 Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. 1995. ISBN 0-201-63361-2.
- ↑ "What Is Object-Oriented Design?". Object Mentor. Archived from the original on 2007-06-30. Retrieved 2007-07-03.
 | This article includes a list of general references, but it lacks sufficient corresponding inline citations. (April 2009) (Learn how and when to remove this template message) |
बाहरी संबंध
- Object-Oriented Analysis & Design - overview using UML
- Larman, Craig. Applying UML and Patterns - Third Edition
- Object-Oriented Analysis and Design
- LePUS3 and Class-Z: formal modelling languages for object-oriented design
