OOPS Concepts in C# with Examples

OOPS Concepts in C# with Examples: C# एक Pure Object Oriented Programming Language है, इसलिए एक Simple “Hello World” Displaying Program Create करने के लिए भी हमें Class Define करना जरूरी होता है और पिछले सभी Chapters में हमने जिन विभिन्न Programming Concepts व Constructs के बारे में जाना है, उनमें से ज्यादातर Constructs व Concepts C/C++ व Java जैसी विभिन्न Programming व Scripting Language में Use किए जाने वाले Basic Concepts हैं, जो कि लगभग सभी Programming Languages में Mostly Common होते हैं।

Class किसी भी Object Oriented Programming Language का आधार होता है और OOPS के Basic Concepts के बारे में भी हमने “C# – The Core Constructs” Chapter के अन्तर्गत Detail से Discuss किया है। लेकिन क्योंकि .NET Framework पूरी तरह से OOPS Concepts पर आधारित है और C# Programming Language को मूल रूप से .NET Framework को ही पूरी Power के साथ Use करने के लिए Design किया गया है, इसलिए बिना OOPS Concepts को Involve किए हुए हम C# को समझ ही नहीं सकते।

अत: ये Chapter और आगे आने वाले कुछ और Chapters पूरी तरह से Object Oriented Programming System के Concepts को ही बेहतर तरीके से समझने पर आधारित हैं, क्योंकि बिना इन OOPS Concepts को समझे हुए हम .NET Framework को ठीक से Use नहीं कर सकते और .NET Framework द्वारा C# को Provide की जाने वाली सुविधाओं को उपयुक्त तरीके से उपयोग में नहीं ले सकते।

Object Oriented Programming System (OOPS) वास्तव में एक Software Design Pattern है, जो कि किसी भी स्तर के छोटे या बडे Software को आसानी से Develop करने, Debug करने, Deploy करने, Manage करने व Extend करने से सम्बंधित Concepts या Rules Provide करता है, जिन्हें Follow करके हम हमारे Application Software को ज्यादा आसानी से Handle करने की क्षमता प्राप्त करते हैं।

Object Oriented Programming System व Object Oriented Programming Language में अन्तर है। OOPS वास्तव में ज्यादा Easy to Manage and Extend Software Design करने से सम्बंधित Rules या Concepts का समूह है, जो कि पूरी तरह से Theoretical है। जबकि Object Oriented Programming Language वह Programming Language होती है, जिसमें Object Oriented Programming System के सभी Theoretical Rules को आसानी से Implement करने की सुविधा Provide की गई होती है।

वर्तमान समय में जितनी भी Programming या Scripting Languages हैं, वे सभी Object Oriented Programming System पर आधारित Object Oriented Programming Languages या Object Oriented Scripting Languages ही हैं, क्योंकि OOPS एक Proved and Perfect Software Design Pattern है। इसलिए जिन Programming Languages में OOPS के Concepts को अच्छी तरह से Implement किया गया है, उन Programming Language को Object Oriented Programming Language कहा जाता है और Java तथा C# Pure Object Oriented Programming Languages के Examples हैं, क्योंकि इनमें कोई भी Program बिना OOPS Concepts को Follow किए हुए Create नहीं किया जा सकता। जबकि C++ एक Hybrid Programming Language है, क्योंकि C++ में यदि हम चाहें तो Object Oriented Design Pattern Follow करते हुए Object Oriented Programs भी Create कर सकते हैं और यदि हम चाहें तो Procedural Design Pattern Follow करते हुए Procedural Programs भी Create कर सकते हैं।

OOPS के Rules को Object Oriented Programming Languages में हमेंशा Class Construct द्वारा Implement किया जाता है, जो कि C# का एक User Defined Reference Type होता है। लेकिन इससे पहले कि हम C# Class Implement करना सीखें, पहले इस बात को समझ लेना हमारे लिए उपयोगी होगा कि आिखर Class बनाया ही क्यों जाता है। यानी OOPS Design Pattern को Develop ही क्यों किया गया जबकि C Language एक Perfect Procedural Programming Language थी। OOPS Design Pattern तथा Class Construct की उपयोगिता को समझने के लिए हमें Software Development का थोडा इतिहास जानना होगा।

जब सबसे पहले Computer को Use किया जाना सम्भव हो सका, तो Computer के शुरूआती दिनों में Business Purpose Applications नहीं बना, जाते थे, बल्कि उन शु:आती दिनों में Computer का उपयोग मूल रूप से Scientific Calculations Perform करने के लिए ही किया जाता था। इसलिए उस समय Computer को Program करने के लिए केवल Machine Language ही उपलब्‍ध थी, जिसे केवल Engineers व Scientist लोग ही अपने Research से सम्बंधित Calculations को Perform करने के लिए Use करते थे।

धीरे-धीरे Computer का और विकास हुआ तो वैज्ञानिकों ने महसूस किया कि Machine Language में किसी Computer को Program करने में काफी समय लगता है और एक मामूली सी Mistake होने पर Computer को फिर से Reprogram करना पडता है। इसलिए कोई ऐसा तरीका बनाया जाए, जिससे Computer को Program करना थोडा आसान हो सके। परिणामस्वरूप वैज्ञानिकों ने Assembly Language का विकास किया।

हालांकि Assembly Language, Machine Langue की तुलना में सरल Programming Language थी, लेकिन फिर भी इस Language को भी केवल Scientist व Mathematician लोग ही Use करते हुए अपने Computer को Program कर सकते थे, जबकि Assembly Language का विकास होने के साथ ही Computer को Business Applications Develop करने के लिए भी Use किया जाने लगा था।

साथ ही Assembly Language Codes पूरी तरह से Computer Hardware Architecture पर Depend होते थे, इसलिए जो Application Software जिस Computer के लिए Develop किया जाता था, वह Application Software केवल उसी Computer पर Execute होता था। इसलिए Portability की जरूरत को महसूस किया गया, ताकि Develop किया गया Program विभिन्न प्रकार के Computers पर Run हो सके। परिणामस्वरूप “B” Language का विकास हुआ और इसकी कुछ कमियों को Resolve करते हुए “C” Language का विकास हुआ।

“C” Language एक High Level Programming Language थी और इसका विकास होने के बाद Computer Programming में काफी तेजी से विकास हुआ क्योंकि अब Computer द्वारा किसी Specific Type की Business Requirement को पूरा करने हेतु Computer को Program करने हेतु Engineers की जरूरत नहीं होती थी। बल्कि सामान्‍य Education वाला व्‍यक्ति भी Computer को Program कर सकता था और विभिन्न प्रकार कर Business Requirements को पूरा करने के लिए विभिन्न प्रकार के Application Software Develop कर सकता था।

साथ ही वे Application Software Portable भी होते थे, जिससे उन्हें विभिन्न प्रकार के Computers पर समान रूप से Run किया जा सकता था। परिणामस्वरूप Computer Software Development का एक नया Field विकसित हुआ और ऐसे Professionals तैयार होने लगे जो विभिन्न प्रकार की Business Requirements को पूरा करने के लिए Computer Software ही तैयार करते थे।

Professional Developers तैयार होने के साथ ही Software Development की मांग बढने लगी, जिससे Computers की Speed व Storage को बढाया जाने लगा, ताकि विभिन्न प्रकार की Business Requirements को पूरा किया जा सके।

Computer की Speed व Storage के साथ ही लोगों की Requirement भी बढने व बदलने लगी। यानी लोग Computer Games व Multimedia Develop करने लगे। जिससे बना, जाने वाले Application Programs की Size बडी होने लगी और Application Software की Size बडी होने के साथ ही Software Developers को अपने Software को Develop करने, Debug करने, Deploy करने, Manage करने व Extend करने में परेशानी आने लगी। क्योंकि उस समय तक Software Developers, Software Design करने के लिए किसी तरह के Design Pattern का प्रयोग नहीं करते थे। बल्कि उनके सभी Software वास्तव में Instructions की एक बडी List हुआ करते थे, जिसे Computer One by One Run करके Appropriate Results Generate करता था।

यानी Pascal, C, Basic, Fortran जैसी Languages में लिखा गया हर Program वास्तव में Instructions का एक समूह होता था और Program का प्रत्येक Statement Computer को कुछ काम करने का Order देता था, जिसे Computer Follow करता था और Appropriate Result Generate करता था। इस प्रकार का Program Create करने वाली Programming Languages को Procedural Languages कहा जाता था तथा इन Languages में Create किए जाने वाले Programs को Procedural Programs कहा जाता था।

Procedural Languages में छोटे Programs के लिए किसी भी अन्‍य प्रकार के Software Design Pattern की आव”यकता नही होती थी। Programmer, Computer द्वारा Execute होने के लिए Instructions की एक List बनाता था और Computer उन Instructions की List को One by One Run करता है। लेकिन जब प्रोग्राम काफी बडे व जटिल हो जाते थे, तब Instructions की ये List यानी Procedural Languages में लिखे गए Programs काफी परेशानी पैदा करने लगते थे। क्योंकि इस तरह के Programs को Extend करना यानी पहले से बने हुए Programs की Functionalities को Increase करना अथवा समान जरूरत को पूरा करने के लिए किसी अन्‍य Program के Code को नए Program में Reuse करना काफी जटिल काम हो जाता था। इसलिए शुरूआत हुई Software Application Develop करते समय किसी Design Pattern को Follow करने की और सबसे पहले Design Pattern के रूप में हमें Modular Design Pattern को विकसित किया गया।

Modular Design Pattern के अन्तर्गत एक बडे Procedural प्रोग्राम या Instruction की List को कई छोटे-छोटे Sub-Programs में कर दिया जाता था जिन्हें Functions कहा जाता है। Functions को दूसरी अन्‍य भाषाओं में Subroutine, Subprogram या Procedure कहा जाता है।

एक बडे प्रोग्राम को छोटे-छोटे Functions में विभाजित करने से पूरा Program Functions का एक समूह बन जाता था, जिसे Module कहा जाता है। लेकिन ये Modules भी Procedural Programming के अन्तर्गत ही आते थे, क्योंकि सभी Functions में Statements की एक List ही होती थी और सभी Functions मिल कर पूरा Program बनाते थे, जिससे पूरा Program Functions की एक List बन जाता था, जो कि स्वयं Instructions की एक List होते थे। इस तरह से फिर से पूरा Program एक बहुत बडी Instructions की List बन जाता था। Procedural Languages के शुरूआती दौर में इसी Design Pattern का प्रयोग करके Program Develop किए जाते थे। यानी Program को छोटे-छोटे Functions में Divide किया जाता था और समान Category के Functions को एक Single File के रूप में Define कर लिया जाता था, जिसे Module कहते थे।

“C” भी एक Procedural Languages ही थी और जब “C” भाषा का विकास हुआ था, तब Programmers अन्‍य सभी भाषाओं को छोड कर “C” में ही अपने Software Develop करने लगे थे। लेकिन समय व आव”यकता के अनुसार जब Program Complex होने लगे, तब Programmers को इस भाषा में Software Develop करने में परेशानी आने लगी। परिणामस्वरूप Developers ने महसूस किया कि इस “C” Language में भी कुछ सुधार की आव”यकता थी ताकि “C” Programming Language ज्यादा सरल व अधिक उपयोगी बन सके। “C” Programming Language सरल व अधिक उपयोगी बन सके इसके लिए इसका वास्तविक जीवन यानी Real World के समान होना जरूरी था। यानी हम हमारे सामान्‍य जीवन में जिस प्रकार से व्‍यवहार करते हैं, इस भाषा का भी वैसा ही होना जरूरी था, ताकि Programmers इसमें अधिक सरलता व सफलता से Program बना सकें। भाषा वास्तविक जीवन के अनुसार हो, यही Concept Object Oriented Programming यानी OOPS का आधार बना।

“C” भाषा की इन कमियों को पहचाना गया और इसमें सुधार किया गया। फलस्वरूप हमें “C” भाषा का एक नया संस्करण “C++” प्राप्त हुआ। चलिए, समझने की कोशिश करते हैं कि “C” भाषा में ऐसी कौनसी कमियां थीं, जिनमें सुधार की आव”यकता महसूस की गई और हमें Object Oriented Programming System नाम का Software Design Pattern प्राप्त हुआ?

Procedural Languages में Operations के Perform होने का महत्व था Data का नहीं। यानी Procedural Languages में Instructions की एक List Create किया जाता था, जिनमें Computer के लिए विभिन्न प्रकार के Instructions होते थे। जैसे:

• Keyboard से Data Input किया जाए।
• Data पर Processing की जाए।
• Errors को Check किया जाए।
• परिणाम को Display किया जाए। आदि …

Functions में भी Operations के इसी महत्व को जारी रखा गया। Functions ठीक उसी प्रकार से कोई काम करते हैं, जिस प्रकार से साधारण Statements का समूह करता है। Functions कोई जटिल काम भी कर सकते हैं, लेकिन इनमें भी काम के होने का ही महत्व था। यानी पूरे Program में Data पर कोई ध्‍यान नहीं दिया जाता था, जबकि पूरे प्रोग्राम का मूल आधार Data ही होता है। यानी किसी Inventory के Program में इस बात का कोई ज्यादा महत्व नहीं होता है कि Data को किस प्रकार से Display किया जा रहा है या एक Function किस प्रकार से Corrupt Data को Check कर रहा है, बल्कि इस बात का होता है कि “Data क्या है और वह किस प्रकार से Program में काम आ रहा है।”

उदाहरण के लिए, किसी Inventory के Program में किसी Inventory Data File को जब Memory में Load किया जाता है, तब ये File एक Global Variable की तरह होती है, जिसे कोई भी Function Directly Access व Manipulate कर सकता है। ये Functions, Data पर विभिन्न प्रकार के Operations Perform करते हैं। यानी

• ये Data को Read करते है।
• Analyze करते हैं।
• Update करते हैं।
• Rearrange करते हैं।
• Display करते हैं और वापस
• Disk पर Write करते हैं

अब मानलो कि इस Inventory के Program के Data को किसी खास तरीके से Analyze करने के लिए एक नए Programmer को एक Function लिखने के लिए कहा गया। लेकिन प्रोग्राम की गूढता से अनभिज्ञ Programmer एक ऐसा Function बनाता है, जो कि Execute होते ही अचानक किसी महत्वपूर्ण Inventory Data को नष्‍ट कर देता है।

ऐसा होना काफी आसान है क्योंकि Procedural Language में सारा Data Global होता है और Global Data को कोई भी “C” Language Function, Directly Access व Manipulate कर सकता है। Global Data को हम कुछ ऐसा ही समझ सकते हैं जैसे कि आप अपने Personal कागजात (Data) को Telephone Directory (Global Area) पर रख दें, जहां कभी भी कोई भी (Function) पहुंच सकता है, उससे छेडछाड कर सकता है और उसे नष्‍ट कर सकता है।

Procedural Languages की दूसरी कमी ये थी कि एक ही Data को कई Functions Use कर सकते थे, इसलिए Procedural Languages में Data को Store करने का तरीका काफी जटिल हो जाता था। क्योंकि समान Data को Use कर रहे सभी Functions को Modify किए बिना, Data में किसी प्रकार का कोई परिवर्तन नहीं किया जा सकता था।

उदाहरण के लिए यदि आप एक नया Inventory Structure में Data Add करते हैं, तो उन सभी Functions को Modify करना होता था, जो कि Data को use कर रहे हैं ताकि ये सभी Functions Add किए गए नए Data को Use कर सकें। ये पता करना कि कौन-कौन से Functions, Data करे Use कर रहे हैं और सभी को बिल्कुल सही तरीके से Modify करना काफी कठिन होता था।

Procedural Programs को Design करना काफी मुश्किल होता था। समस्या ये होती थी कि इनका Design वास्तविक जीवन से Related नहीं होता था। जैसे कि, यदि आप एक Graphics User Interface में Menu Window के लिए Code लिखना चाहें, तो आपको ये तय करना मुश्किल होता था कि आपको कौनसा Function Use करना चाहिए? कौनसा Data Structure (Array, Stack, Queue, Linked List, etc…) Use करना चाहिए। आदि।

Procedural Programs की सबसे बडी परेशानी यही थी कि Programming Language Real World Problems को Model करने में सक्षम नहीं थी। यानी हम Procedural Languages का प्रयोग करके किसी Real World Problem को Computer में Exactly उसी तरह से Modal नहीं कर सकते, जिस तरह से वह समस्या Real World में Exist होती है।

Procedural Languages में भी Real World Objects को एक नए Data Type या Type की तरह ही Represent किया जाता था। लेकिन समस्या ये होती थी कि ये User Defined Data Type किसी Real World Problem को Exactly उसी तरह से Computer में Represent नहीं करते थे जिस तरह से वे समस्याऐं Real Word में Reflect होती थीं और न ही ये User Defined Types Exactly उस तरह से Behave करते थे, जिस तरह से Predefined या In-Built Data Types जैसे कि int, float, double, char आदि Behave करते हैं।

उदाहरण के लिए मानलो कि हम Complex Numbers के साथ कोई Processing करना चाहते हैं या Two-Dimensional Coordinates के साथ काम करना चाहते हैं या Date के साथ कुछ काम करना चाहते हैं।

चूंकि Built-in Data Type इन Complex Values को आसानी से Handle नहीं कर सकते हैं। क्योंकि Built-In Types हमेंशा केवल एक Single Value के साथ ही उपयुक्त तरीके से काम कर सकते हैं। जबकि Complex Values या Coordinates या Date ऐसी Values हैं, जो कि एक से ज्यादा Predefined Types जैसे कि int, char, float, double आदि का Combination हैं। इसलिए हमें हमारी आवश्‍यकतानुसार स्वयं के Data Type बनाने की जरूरत होती है, जो कि इन Complex Values, Coordinates या Date Type की “Group of Multiple Primary Type” Values को Built-In Data Type की तरह Use करने की सुविधा Provide कर सकें।

लेकिन Procedural Language में स्वयं के Data Type बना कर हम उन्हें Exactly Built-in Data Type की तरह Use नहीं कर सकते। यानी Procedural Language इतने उन्नत नहीं थे, कि हम Complex Values, Coordinates, Date Type आदि को बिना जटिल तरीकों को अपना, हुए सामान्‍य तरीके से ठीक उसी तरह से उपयोग में ले सकें, जिस तरह से Predefined Primary Types को उपयोग में लेते हैं।

उदाहरण के लिए हम दो Integer Values p व q को आपस में जोडने के लिए p + q; Statement Use करते हैं। लेकिन Procedural Programming Languages में हम User Defined Types के माध्‍यम से जो Complex, Coordinates, Date, Time, Watch, etc… Type Define करते हैं, उन User Defined Types के दो Instances जैसे कि Watch Type के दो Instances hmt व sonata के Time को आपस में जोडने के लिए hmt + sonata; Statement Use नहीं कर सकते। क्योंकि Procedural Languages हमें User Defined Types के Variables को Exactly उसी तरह से Use करने की पूरी सुविधा Provide नहीं करते, जिस तरह से हम Predefined Types या Primary Data Types के Variables को Use करते हैं।

यानी Procedural Programming Languages द्वारा Provide किए जाने वाले Modular Software Design Pattern का प्रयोग करके हम किसी Real World Problem को Computer में Logically उसी तरह से Represent नहीं कर सकते, जिस तरह से वह Problem Real World में Exist होती है। क्योंकि Procedural Languages के User Define Types किसी Real World Problem से सम्बंधित Objects को Computer में Built-In Types (int, float, char, etc…) की तरह Model करने में पूरी तरह से सक्षम नहीं थे।

इसके अलावा Modular Design Pattern की एक कमी ये थी कि हम Modular Design Pattern का प्रयोग करके Design किए गए Software Codes को पूरी तरह से Reuse नहीं कर सकते थे। यानी Modular Design Pattern के आधार पर किसी एक Application Software के लिए Create किए जाने वाले User Defined Types व Codes को किसी दूसरे Application Software की Exactly समान प्रकार की जरूरत को पूरा करने के लिए भी फिर से Perfect तरीके से Reuse नहीं किया जा सकता था। क्योंकि Modular Design Pattern में सभी Codes एक Function के रूप में लिखे जाते थे, जो कि Globally Created User Defined Types को Access व Manipulate करते थे। इसलिए एक Application के लिए जो भी Codes लिखे जाते थे, वे Codes पूरी तरह से उसी Application के लिए Working होते थे। जबकि उन Codes को किसी अन्‍य Application में Use करने के लिए हमें Functions व User Defined Types को Copy-Paste करना होता था और नए Application की जरूरत के अनुसार इन Codes को फिर से Modify करना होता था, जिसकी वजह से नए Bugs Create होते थे, जिन्हें फिर से Debug करना होता था।

यानी Procedural Languages की दूसरी सबसे बडी कमी यही थी, कि समान प्रकार की जरूरतों को पूरा करने के लिए लिखे गए Codes को भी किसी अन्‍य Application में फिर से ज्यों का त्यों Reuse नहीं किया जा सकता था और इस कमी का भी मुख्‍य कारण यही था कि Procedural Languages में Data Types Real World Object को Computer में Logically समान प्रकार से Represent नहीं करते थे।

Modular Software Design Pattern व इन पर आधारित Procedural Languages की इन्हीं मुख्‍य कमियों की वजह से एक नए Design Pattern को विकसित करने की जरूरत महसूस की गई, जिसकी मुख्‍य Requirements निम्नानुसार थीं:

• Code Reusability आसान हो, ताकि समान प्रकार की जरूरतों को पूरा करने के लिए बार-बार समान प्रकार के Codes न लिखने पडे और Copy-Paste तकनीक का प्रयोग करके पहले से लिखे गए Codes को नए Program की जरूरत के अनुसार फिर से Modify व Debug न करना पडे।

• Programming Language किसी Real World Problems को Computer में Exactly उसी तरह से Represent करने में सक्षम हो, जिस तरह से वह Problem Real World में Practically Exist है।

• Real Word Problem से सम्बंधित विभिन्न Objects, Computer में Exactly उसी तरह से Behave करें, जिस तरह से किसी भी Programming Language के Predefined Data Type करते हैं।

परिणामस्वरूप जो Design Pattern विकसित किया गया, उसे Object Oriented Programming System यानी OOPS नाम दिया गया और OOPS से सम्बंधित Rules को जिस किसी भी Programming Language में पूरी तरह से Implement करने की सुविधा Provide की गई, उस Programming Language को Object Oriented Programming Language कहा गया।

OOPS के अन्तर्गत जब किसी Real World Problem को Computer Program के रूप में Design करना होता है, तब हमें Program को Functions में नहीं बल्कि Objects में Divide करना होता है।

यानी हमें ये पता लगाना होता है कि हमारी समस्या से सम्बंधित मुख्‍य Objects कौनसे हैं और वे सभी Objects आपस में किस तरह से एक दूसरे के साथ Communication करते हुए किसी Real World Problem को Solve करते हैं।

जब हम कोई Practical Software Develop करते हैं, तो हमारा सबसे पहला काम यही होता है कि हम हमारे Application की Requirements के आधार पर ये तय करें कि हमारे Software के मुख्‍य हिस्से कौन-कौन से हैं, जिनकी Information को हमें Computer द्वारा Manage करना है।

उदाहरण के लिए यदि हम कोई Banking Software Create करना चाहें, तो हम समझ सकते हैं कि एक Bank कई तरह के काम करता है और हर काम को करने के लिए Bank का एक विशेष हिस्सा अपना अलग Role Play करता है। जबकि Bank के विभिन्न हिस्सों में से कुछ द्वारा Perform किए जाने वाले मुख्‍य काम निम्नानुसार हो सकता है:

• Payment Deposit
• Payment Withdrawal
• New Account Opening
• Loan Sanction

अब मानलो कि हम Banking के इन चार मुख्‍य कामों को करने वाले चारों Departments से सम्बंधित मुख्‍य Objects को Identify करना चाहते हैं, तो किसी भी Department से सम्बंधित मुख्‍य Objects को Identify करने का Best तरीका ये है कि हम उस Department के काम करने के तरीके को समझें। जब हम Department के काम करने के तरीके को समझेंगे, तो हमें अपने आप पता चल जाएगा कि किसी Department से सम्बंधित मुख्‍य Objects कौन-कौन से हैं, जो कि समस्या से सम्बंधित हैं। इस प्रक्रिया को Software Development की भाषा में System Analysis करना कहा जाता है और जब किसी Department के काम करने के तरीके को एक Diagram द्वारा Represent किया जाता है, जिसे Data Flow Diagram कहते हैं।

चलिए, हम एक उदाहरण द्वारा अपने Banking Software के Payment Deposit Department के काम करने के तरीके के आधार पर उस Department से सम्बंधित उन मुख्‍य Objects को Identify करने की कोशिश करते हैं, जो कि हमारे Computer Program में उस Department को Logically Represent करने के लिए से मुख्‍य Role Play करेंगे।

Payment Department का मुख्‍य काम किसी Customer द्वारा आने वाले Amount को उसके Account में जमा करना होता है। यानी जब किसी Customer Object को अपने Bank A/c Object में कोई Amount Data Deposit करना होता है, तो वह एक Deposit Form Object को विभिन्न प्रकार की Bank A/c व Amount की Information से Fill करता है और Amount के साथ उस Payment Deposit Form Object को Cashier Object को देता है।

Cashier Object उस Deposit Form Object व Amount के आधार पर Data को Validity के लिए Test करता है और यदि सबकुछ ठीक होता है, तो Amount को अपने Cash Object में Store करता है तथा Deposit होने वाले Amount की Information को Customer Object के Bank A/c Object में Update करता है।

इस तरह से हम समझ सकते हैं कि Payment Deposit करने में मूल रूप से निम्न Objects आपस में Communication करते हैं:

• Customer Object
• Deposit Form Object
• Cashier Object
• Bank A/c Object

Object Oriented Programming Languages में किसी Real World Object को हमेंशा Class Construct द्वारा Represent किया जाता है।

यानी यदि हम हमारे Banking Software के Payment Deposit Part को Computer Program में Logically Represent करना चाहें, तो हमें वास्तव में Customer, Deposit Form, Cashier व Bank A/c नाम के चार User Defined Types बनाने होंगे, जो कि पूरी तरह से एक Real World Problem पर आधारित हैं, क्योंकि हमने एक Real World Problem के उदाहरण द्वारा ही इन चार Objects को Identify किया है।

जब हम एक बार किसी Real World Problem Related Objects को Identify कर लेते हैं, तो हर Object को Computer Program में एक Class के माध्‍यम से Represent किया जा सकता है क्योंकि Object Oriented Programming Language में Class Construct एक User Defined Type होता है, जो किसी Real World Object को Computer Program में Logically Represent करने की सुविधा देता है।

Real World Problem Related जो Object हमें प्राप्त होता है, वह हर Object अपनी कुछ Characteristics के माध्‍यम से ही किसी अन्‍य Object से अलग Identify होता है। उदाहरण के लिए Customer Object व Bank A/c Object दोनों की अपनी अलग Characteristics है। उदाहरण के लिए Customer Object को उसके Name Characteristic से Identify किया जाता है जबकि Bank A/c Object को उसे Account Number Characteristic से Identify किया जाता है।

किसी भी Object की विभिन्न प्रकार की बहुत सारी Characteristics हो सकती हैं। लेकिन Current Problem से सम्बंधित जरूरी Characteristics को अन्‍य बिना जरूरी Characteristics से अलग करने की प्रक्रिया को Object Oriented Programming System में Abstraction के नाम से जाना जाता है।

उदाहरण के लिए किसी Customer Object की विभिन्न Characteristics, जो कि उसे किसी भी अन्‍य Object से अलग बनाती हैं, निम्नानुसार हो सकती हैं:

• Name
• Father Name
• Mother Name
• Height
• Color
• Cast
• Residential Address
• Date of Birth
• City
• State

लेकिन एक Bank में Account Open करवाने के लिए Bank Administer को इन सभी Characteristics की जरूरत नहीं होती। बल्कि वे Characteristics जो कि Bank A/c Open करने के लिए जरूरी होती हैं, निम्नानुसार हो सकती हैं:

• Name
• Father Name
• Cast
• Residential Address
• Date of Birth
• City
• State

हम समझ सकते हैं कि हालांकि एक Customer Object की बहुत सारी Characteristics हो सकती हैं, जो उसे किसी भी अन्‍य Object से अलग Identify करने के लिए उपयोगी होती हैं। लेकिन Bank में Account Open करवाने के लिए Bank Administer को केवल उपरोक्त 7 Characteristics की ही जरूरत होती है। जबकि Customer की Height, Color व Mother Name Characteristics की जरूरत Bank Account Open करने के लिए नहीं है।

इसलिए जब हम किसी Real World Object की Current Problem से Related जरूरी Characteristics को अन्‍य बिना जरूरी Characteristics से अलग करते हैं, तो इस प्रक्रिया को Object Oriented Programming System के अन्तर्गत Abstraction के नाम से जाना जाता है। जिस तरह से हम Customer Object को Abstract कर सकते हैं, उसी तरह से हम Bank A/c Object को भी Abstract कर सकते हैं और एक Bank A/c को Abstract करने पर हमें Bank A/c से सम्बंधित निम्न मुख्‍य बातें प्राप्त होती हैं:

• Account Number
• Account Type
• Account Holder Name
• Transaction Date
• Transaction Type
• Balance

हर Object विभिन्न प्रकार की Characteristics का Collection मात्र ही नहीं होता, बल्कि Real World में हर Object किसी न किसी तरह का Operation भी Perform करता है। इसलिए यदि हम Bank A/c Object द्वारा Perform किए जा सकने वाले Operations को Describe करें, तो एक Bank A/c Object निम्न Operations Perform कर सकता है:

• Bank A/c Object में Amount को Deposit किया जा सकता है।
• Bank A/c से Amount को Withdraw किया जा सकता है।

Current Problem Related हर Real World Object, Real World में जिन Operations को Perform करता है, उन Operations को Object Oriented Programming System के अन्तर्गत Object का Behavior कहा जाता है और Object Oriented Programming Language में Methods द्वारा Represent किया जाता है। इसलिए यदि हम सरल शब्दों में कहें, तो Current Problem Related हर Real World Object वास्तव में Characteristics व Behaviors का एक Combined Unit अथवा Encapsulated Unit होता है और Object Oriented Programming System में किसी Real World Object की Characteristics व Behaviors को एक Unit के रूप में Combine करने की प्रक्रिया को Encapsulation के नाम से जाना जाता है।

OOPS का Encapsulation एक ऐसी स्थिति को Represent करता है, जिसमें कोई Object केवल स्वयं ही किसी Operation के माध्‍यम से अपनी ही किसी Characteristics की स्थिति में परिवर्तन कर सकता है। उदाहरण के लिए एक Bank A/c Object Withdraw Operation को Perform करके केवल अपने ही Bank A/c से Amount Withdraw कर सकता है, किसी अन्‍य के Bank A/c से नहीं।

और ज्यादा आसान उदाहरण द्वारा Encapsulation को समझें, तो हमारा Computer भी एक Real World Object है और हर Real World Object की तरह ही ये भी एक Encapsulated Unit है। इसलिए जब हम हमारे Computer को Start करने के लिए इसे Switch-On करने का Operation Perform करते हैं, तो Computer के Screen की स्थिति में परिवर्तन होता है और वह Blank Screen के स्थान पर Desktop Show करने लगता है।

इसी तरह से Car भी एक Real World Object होने की वजह से एक Encapsulated Unit है। जिसके Accelerator को Press करने का Operation Perform करने पर Speed की स्थिति में परिवर्तन होता है। यानी हर Encapsulated Unit कुछ Characteristics व Operations का समूह होता है और जब हम किसी Operation को Perform करते हैं, तो वास्तव में हम उस Encapsulated Unit के किसी Characteristic की स्थिति में परिवर्तन ही कर रहे होते हैं।

दूसरे शब्दों में कहें, तो Encapsulation के माध्‍यम से हम किसी Object की Characteristics व उन Characteristics की State में जरूरत के अनुसार परिवर्तन करने वाले Operations के समूह को एक Unit के रूप में Combine करते हैं और जब हमें उस Object की किसी Characteristic की State में परिवर्तन करना होता है, तो हम किसी Appropriate Operation को Perform करते हैं।

Encapsulated Unit की विशेषता ये होती है कि कोई Object Internally किस तरह से काम करते हुए हमारी किसी Requirement को पूरा कर रहा है, इस बात से हमें कोई मतलब नहीं होता। बल्कि हमें हमारी किसी जरूरत को पूरा करने के लिए एक Well Defined Interface Provide करवा दिया जाता है और हम उस Interface को Use करते हुए अपनी किसी Specific Requirement को पूरा कर लेते हैं।

यानी हमें ये जानने की जरूरत नहीं है कि Computer का Desktop Display होने तक Computer के अन्दर Internally क्या-क्या Operation Perform हो रहे हैं या Car के Accelerator को Press करने पर Car की Speed बढाने के लिए Car का Engine किस तरह से काम कर रहा है। बल्कि Computer या Car बनाने वाली Company द्वारा हमें Switch-On Button या Accelerator के रूप में एक Well-Defined User Interface Provide करवा दिया गया है, जिसका प्रयोग करके हम Computer को On कर सकते हैं अथवा Car की Speed को बढा सकते हैं।

Computer किस तरह से Start होकर Desktop Display करता है या Car का Accelerator Press करने पर Car की Speed किस तरह से बढती है, ये बात हमसे पूरी तरह से Hidden रहती है और हमें इस बात का पता नहीं होता कि Computer Start होते समय Computer के कौनसे Parts की स्थिति में क्या परिवर्तन होता है या Car के Engine की किस स्थिति में परिवर्तन होता है। Object Oriented Programming System में इस प्रक्रिया को Data Hiding के नाम से जाना जाता है।

Computer को Start करने के लिए हमें Switch-On Button को Press करना ही होगा, क्योंकि Computer को On करने का यही एकमात्र तरीका है। इसी तरह से Car की Speed को बढाने के लिए हमें Car के Accelerator को Press करना ही होगा, क्योंकि Car की Speed बढाने का एकमात्र तरीका यही है। यानी किसी Encapsulated Object की स्थिति में परिवर्तन करने के लिए हमें हमेंशा किसी Well-Defined User Interface Operation को ही Perform करना होता है। हम किसी भी अन्‍य तरीके से न तो Computer को On कर सकते हैं, न ही Car की Speed बढा सकते हैं।

ठीक इसी तरह से जब हम Computer Program में किसी Problem Related Object को Class Construct द्वारा Represent करते हैं, तो बना, जाने वाले इस नए User Defined Type द्वारा भी हम Object Oriented Programming System के इन सभी Concepts को Implement करते हैं। यानी Problem Related Object की सभी जरूरी Characteristics को Class में Data Members या Fields के रूप में Specify किया जाता है, जबकि Object द्वारा Perform किए जाने वाले Operations को Methods द्वारा Represent करते हैं। इसलिए इस Concept के आधार पर यदि हम हमारे Bank A/c Object की Characteristics को Data Members की तरह Represent करें, तो हमारी बनने वाली Class का Structure कुछ निम्नानुसार हो सकता है:

class BankAccount
{
  Account Number
  Account Type 
  Account Holder Name
  Transaction Date
  Transaction Type
  Balance
}

चूंकि C# में किसी भी Variable के नाम में Space नहीं हो सकताए साथ ही सभी Data Members के नाम की शु:आत Small Letter से करनी चाहिए। इसलिए यदि इन दोनों नियमों को उपरोक्त Construct पर Apply करें, तो हमारा Class Construct कुछ निम्नानुसार होगा:

class BankAccount
{
  accountNumber
  accountType
  accountHolderName
  transactionDate
  transactionType
  balance
}

चूंकि सभी Objects की Properties में किसी न किसी तरह का Data ही Store होता है। इसलिए जिस Data Member में जिस तरह का Data Store हो सकता है, उसे उसी Type का Declare करने पर हमारा Class Construct कुछ निम्नानुसार बनेगा:

class BankAccount
{
  string accountNumber
  string accountType
  string accountHolderName
  DateTime transactionDate
  string transactionType
  double balance
}

साथ ही यदि हम Object द्वारा Perform किए जाने वाले Operations को Methods की तरह इसी Class Construct में Define कर दें, तो हमारा उपरोक्त Code कुछ निम्नानुसार बनेगा:

class BankAccount
{
  string accountNumber;
  string accountType;
  string accountHolderName;
  DateTime transactionDate;
  string transactionType;
  double balance;

  void Deposit();
  void Withdraw();
}

इस तरह से ये जो Class Construct Create हो रहा है, वह एक ऐसा Definition है, जो कि Real World के Bank A/c Object को Computer Program में एक Logical Bank A/c Object की तरह Represent कर रहा है।

चूंकि जिस Customer का Bank A/c होता है, वही Customer उस Bank A/c की Information को Access कर सकता है। जबकि अन्‍य कोई भी Real World Object किसी दूसरे व्‍यक्ति के Bank A/c की Information को Access नहीं कर सकता। ठीक यही व्‍यवस्था Computer Program में Define किए गए हमारे Bank A/c Object में भी होनी चाहिए। इसलिए इस व्‍यवस्था को प्राप्त करने के लिए हमें हर Data Member के साथ private Keyword को Use करना होता है, जबकि सभी Methods को public रखना होता है, ताकि कोई भी अन्‍य Object यदि Customer के Account की Information को Access करना चाहे, तो उसी Customer Object के माध्‍यम से कर सके, जिसका Account है।

यानी सरल शब्दों में कहें, तो एक Object एक घर की तरह होता है, जिसमें सामान के रूप में विभिन्न प्रकार के Data Stored होते हैं और उस घर के सामान को केवल उसी घर का मालिक ही Directly Access कर सकता है। जबकि यदि कोई अन्‍य व्‍यक्ति जैसे कि आपका पडौसी आपके घर के अन्दर रखे किसी सामान को Access करना चाहता है, तो बिना आपकी अनुमति लिए हुए वह आपके घर के सामान को Access नहीं कर सकता।

अथवा यदि आपका पडौसी आपके घर में रखे हुए सामान को Access करना चाहता है, तो उस व्‍यक्ति को आप Directly अपने घर में आने की Permission नहीं देते, बल्कि उसे जिस सामान की जरूरत होती है, आप स्वयं अपने घर में जाकर वह सामान लाते हैं और उस व्‍यक्ति को Use करने के लिए देते हैं। इस स्थिति में आपका घर एक Object है, जिसमें रखे हुए विभिन्न प्रकार के सामान Data Members हैं और उन Data को केवल आप ही Directly Access कर सकते हैं, इसलिए आप अपने घर के Method हैं।

चूंकि Real World में दो Objects आपस में इसी तरह से Communicate करते हैं, इसलिए Object Oriented Programming Languages में भी दो Objects आपस में एक दूसरे के Methods को Call करते हुए इसी तरह से Communication करते हैं। जब कोई एक Class का Object किसी दूसरे Class के Object के किसी Method को Call करता है, तो इस प्रक्रिया को Object Oriented Programming System में Message Pass करना कहते हैं। यानी एक Object किसी दूसरे Object के Method को Call करके उसे एक प्रकार का Message देता है कि वह उस दूसरे Object के किस Data को Access करना चाहता है। ठीक उसी तरह से जिस तरह से आपका पडौसी Object आपके घर के किसी सामान को Access करने के लिए आपको Call करता है और उसे आपके घर के जिस सामान यानी Data की जरूरत है, आपको उस सामान की Instruction Message देता है।

इस तरह से Object Oriented Programming System Concepts के अनुसार हमारा Computer Program किसी Real World समस्या से सम्बंधित विभिन्न Real World Objects को ठीक उसी तरह से Represent करता हैं, जिस तरह से वह Object Real World में Exist होता है और हमारे Computer Program में भी वह Object Exactly उसी तरह से Behave करता है, जिस तरह से वह Object Real World में Behave करता है।

जबकि Object Oriented Programming Language में OOPS Design Pattern के आधार पर किसी Real World Object को हमेंशा Class Construct द्वारा Represent किया जाता है, इसलिए विभिन्न प्रकार के OOPS Concepts को Class पर ही Apply किया जाता है, जिनके बारे में हम आगे विस्तार से समझेंगे कि किस प्रकार से Real World Problems को Solve करने के लिए Real World Object को Computer Program में Exactly उसी प्रकार से Represent व Behave करवाने की क्षमता प्राप्त की जाती है, जिस प्रकार से वह Object Real World में Represent होता है और Behave करता है।

साथ ही ये भी जानेंगे कि किस प्रकार से हम Class Construct का प्रयोग करके Define किए जाने वाले User Defined Class Type को अपने Computer Program में OOPS Design Patterns के Overloading Concepts का प्रयोग करते हुए ठीक उसी प्रकार से Use कर सकते हैं, जिस प्रकार से Programming Language के Primary Data Types जैसे कि int, float, double, char आदि को Use करते हैं।

इनके अलावा हम ये भी जानेंगे कि Class Type पर OOPS Design Pattern के Inheritance व Polymorphism Concepts को Follow करते हुए Create किए जाने वाले Class Type के Codes को किस तरह से बिना किसी तरह का Modification किए हुए समान प्रकार की जरूरतों को पूरा करने के लिए विभिन्न प्रकार के Applications में Reuse कर सकते हैं।