आप सभी को जावा में ठोस सिद्धांतों के बारे में जानना चाहिए

की दुनिया में (OOP), कई डिजाइन दिशानिर्देश, पैटर्न या सिद्धांत हैं। इनमें से पांच सिद्धांत आमतौर पर एक साथ समूहीकृत किए जाते हैं और इन्हें संक्षिप्त SOLID द्वारा जाना जाता है। जबकि इन पांच सिद्धांतों में से प्रत्येक कुछ विशिष्ट का वर्णन करता है, वे भी ओवरलैप करते हैं जैसे कि उनमें से एक को अपनाने का मतलब है या दूसरे को अपनाने की ओर जाता है। इस लेख में हम जावा में SOLID सिद्धांतों को समझेंगे।

• जावा में SOLID सिद्धांतों का इतिहास
• S.O.L.I.D का अर्थ क्या है?

जावा में SOLID सिद्धांतों का इतिहास

रॉबर्ट सी। मार्टिन ने पांच ऑब्जेक्ट-ओरिएंटेड डिज़ाइन सिद्धांत दिए, और इसके लिए 'S.O.L.I.D' का उपयोग किया जाता है। जब आप संयुक्त रूप से S.O.L.I.D के सभी सिद्धांतों का उपयोग करते हैं, तो आपके लिए सॉफ्टवेयर विकसित करना आसान हो जाता है जिसे आसानी से प्रबंधित किया जा सकता है। S.O.L.I.D के उपयोग की अन्य विशेषताएं हैं:

• यह कोड बदबू से बचा जाता है।
• जल्दी से अपवर्तक कोड।
• अनुकूली या चुस्त सॉफ्टवेयर विकास कर सकते हैं।

जब आप अपने कोडिंग में S.O.L.I.D के सिद्धांत का उपयोग करते हैं, तो आप उस कोड को लिखना शुरू करते हैं जो कुशल और प्रभावी दोनों है।

S.O.L.I.D का अर्थ क्या है?

ठोस जावा के पाँच सिद्धांतों का प्रतिनिधित्व करते हैं जो हैं:

• एस : एकल जिम्मेदारी सिद्धांत
• या : खुला-बंद सिद्धांत
• एल : लिसकोव प्रतिस्थापन सिद्धांत
• मैं : इंटरफ़ेस अलगाव सिद्धांत
• डी : निर्भरता उलटा सिद्धांत

इस ब्लॉग में, हम जावा के सभी पाँच ठोस सिद्धांतों के बारे में विस्तार से चर्चा करेंगे।

जावा में एकल जिम्मेदारी सिद्धांत

यह क्या कहता है?

रॉबर्ट सी। मार्टिन इसका वर्णन करते हैं कि एक वर्ग के पास केवल और केवल एक ही जिम्मेदारी होनी चाहिए।

एकल जिम्मेदारी सिद्धांत के अनुसार, केवल एक कारण होना चाहिए जिसके कारण एक वर्ग को बदलना पड़ता है। इसका मतलब है कि एक वर्ग को एक काम करना चाहिए। इस सिद्धांत को अक्सर व्यक्तिपरक कहा जाता है।

सिद्धांत को एक उदाहरण से अच्छी तरह समझा जा सकता है। कल्पना कीजिए कि एक वर्ग है जो निम्नलिखित कार्यों को करता है।

• एक डेटाबेस से जुड़ा

  oracle pl sql त्रुटि सर्वोत्तम प्रथाओं से निपटने

• डेटाबेस टेबल से कुछ डेटा पढ़ें

• अंत में, इसे एक फाइल पर लिखें।

क्या आपने परिदृश्य की कल्पना की है? यहां कक्षा में परिवर्तन के कई कारण हैं, और उनमें से कुछ फ़ाइल आउटपुट, नया डेटा बेस अपनाने का संशोधन हैं। जब हम एकल सिद्धांत जिम्मेदारी के बारे में बात कर रहे हैं, तो हम कहेंगे कि वर्ग के बदलने के कई कारण हैं, इसलिए यह एकल जिम्मेदारी सिद्धांत में ठीक से फिट नहीं है।

उदाहरण के लिए, एक ऑटोमोबाइल वर्ग खुद को शुरू या बंद कर सकता है लेकिन इसे धोने का कार्य CarWash वर्ग का है। एक अन्य उदाहरण में, एक बुक क्लास में अपना नाम और पाठ संग्रहीत करने के लिए गुण होते हैं। लेकिन पुस्तक को प्रिंट करने का कार्य बुक प्रिंटर वर्ग का होना चाहिए। बुक प्रिंटर क्लास कंसोल या किसी अन्य माध्यम से प्रिंट हो सकती है, लेकिन ऐसी निर्भरताएं बुक क्लास से हटा दी जाती हैं

यह सिद्धांत आवश्यक क्यों है?

जब एकल जिम्मेदारी सिद्धांत का पालन किया जाता है, तो परीक्षण करना आसान होता है। एक ही जिम्मेदारी के साथ, कक्षा में कम परीक्षण मामले होंगे। कम कार्यक्षमता का अर्थ अन्य वर्गों के लिए कम निर्भरता भी है। यह बेहतर कोड संगठन की ओर जाता है क्योंकि छोटी और अच्छी तरह से purposed कक्षाएं खोज करने में आसान होती हैं।

इस सिद्धांत को स्पष्ट करने के लिए एक उदाहरण:

मान लीजिए कि आपको उपयोगकर्ता सेवा को लागू करने के लिए कहा गया है, जिसमें उपयोगकर्ता सेटिंग्स बदल सकता है, लेकिन इससे पहले उपयोगकर्ता को प्रमाणित करना होगा। इसे लागू करने का एक तरीका यह होगा:

सार्वजनिक वर्ग UserSettingService {public void changeEmail (उपयोगकर्ता उपयोगकर्ता) {if (checkAccess (उपयोगकर्ता)) {// बदलने का विकल्प}} सार्वजनिक बूलियन checkAccess (उपयोगकर्ता उपयोगकर्ता) {// सत्यापित करें यदि उपयोगकर्ता मान्य है। }}

सभी तब तक अच्छे लगते हैं, जब तक आप किसी अन्य स्थान पर चेकअसेट कोड का पुन: उपयोग नहीं करना चाहेंगे या आप उस तरीके से बदलाव करना चाहते हैं, जिस तरह से चेकआउट सफल हो रहा है। सभी 2 मामलों में आप एक ही वर्ग को बदलना चाहेंगे और पहले मामले में आपको एक्सेस के लिए जाँच करने के लिए UserSettingService का उपयोग करना होगा।
इसे सही करने का एक तरीका यह है कि UserSettingService को UserSettingService और SecurityService में विघटित कर दिया जाए। और SecurityService में CheckAccess कोड को स्थानांतरित करें।

सार्वजनिक वर्ग UserSettingService {सार्वजनिक शून्य परिवर्तन ई-मेल (उपयोगकर्ता उपयोगकर्ता) {अगर (SecurityService.checkAccess (उपयोगकर्ता)) {// परिवर्तन का विकल्प}}} सार्वजनिक वर्ग SecurityService {सार्वजनिक स्थैतिक बूलियन चेकअसे (उपयोगकर्ता उपयोगकर्ता) {// एक्सेस की जाँच करें। }}

जावा में खुला बंद सिद्धांत

रॉबर्ट सी। मार्टिन इसका वर्णन करते हैं कि सॉफ्टवेयर घटकों को विस्तार के लिए खुला होना चाहिए, लेकिन संशोधन के लिए बंद कर दिया जाना चाहिए।

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

• कक्षा से प्रवेश करना

• कक्षा से आवश्यक व्यवहारों को ओवरराइट करना

• कक्षा के कुछ व्यवहारों का विस्तार करना

ब्राउज़रों की मदद से खुले-बंद सिद्धांत का एक उत्कृष्ट उदाहरण समझा जा सकता है। क्या आपको अपने क्रोम ब्राउज़र में एक्सटेंशन इंस्टॉल करना याद है?

क्रोम ब्राउज़र का मूल कार्य विभिन्न साइटों को सर्फ करना है। क्या आप व्याकरण की जाँच करना चाहते हैं जब आप क्रोम ब्राउज़र का उपयोग करके एक ईमेल लिख रहे हैं? यदि हाँ, तो आप केवल व्याकरण विस्तार का उपयोग कर सकते हैं, यह आपको सामग्री पर व्याकरण की जाँच प्रदान करता है।

यह तंत्र जहां आप ब्राउज़र की कार्यक्षमता बढ़ाने के लिए चीजों को जोड़ रहे हैं वह एक विस्तार है। इसलिए, ब्राउज़र कार्यक्षमता का एक आदर्श उदाहरण है जो विस्तार के लिए खुला है लेकिन संशोधन के लिए बंद है। सरल शब्दों में, आप अपने ब्राउज़र पर प्लगइन्स को जोड़ / स्थापित करके कार्यक्षमता को बढ़ा सकते हैं, लेकिन कुछ नया नहीं बना सकते।

ऐसा क्यों है कि इस सिद्धांत की आवश्यकता है?

OCP महत्वपूर्ण है क्योंकि कक्षाएं तृतीय-पक्ष पुस्तकालयों के माध्यम से हमारे पास आ सकती हैं। यदि हम उन आधार वर्गों को हमारे एक्सटेंशन का समर्थन कर सकते हैं तो हमें चिंता किए बिना उन वर्गों का विस्तार करने में सक्षम होना चाहिए। लेकिन विरासत में उपवर्ग हो सकते हैं जो बेस क्लास कार्यान्वयन पर निर्भर करते हैं। इससे बचने के लिए, इंटरफेस का उपयोग करने की सिफारिश की जाती है। यह अतिरिक्त अमूर्त युग्मन ढीला कर देता है।

आइए बताते हैं कि हमें विभिन्न आकृतियों के क्षेत्रों की गणना करने की आवश्यकता है। हम अपने पहले आकार आयत के लिए एक वर्ग बनाने के साथ शुरू करते हैंजिसकी लंबाई 2 है& चौड़ाई।

सार्वजनिक वर्ग आयत {सार्वजनिक डबल लंबाई सार्वजनिक डबल चौड़ाई}

आगे हम इस आयत के क्षेत्र की गणना करने के लिए एक वर्ग बनाते हैंजिसका एक तरीका है गणना रेक्टेंगलएरेआजो आयत लेता हैएक इनपुट पैरामीटर के रूप में और इसके क्षेत्र की गणना करता है।

सार्वजनिक वर्ग AreaCalculator {सार्वजनिक डबल कैलकुलेरंगएरेला (आयत आयत) {रिटर्न आयत.लगाव * आयत.आविकास}}

अब तक सब ठीक है। अब हम कहते हैं कि हमें अपना दूसरा आकार मिला। इसलिए हम तुरंत एक नया वर्ग सर्किल बनाते हैंएक एकल विशेषता त्रिज्या के साथ।

सार्वजनिक वर्ग सर्किल {सार्वजनिक डबल त्रिज्या}

फिर हम क्षेत्रक को संशोधित करते हैंवर्ग एक नई विधि के माध्यम से चक्र गणना जोड़ने के लिए वर्ग गणना ()

सार्वजनिक वर्ग AreaCalculator {सार्वजनिक डबल कैलक्लेरआर्गेनएरिया (आयत आयत) {रिटर्न रेक्टेंगल.लिफ्ट * आयत.प्रक्रिया} पब्लिक डबल कैलक्लेक्लेरिया (सर्कल सर्कल) {रिटर्न (22/7) * सर्कल। ब्रैडियस * सर्कल.राडिएस}}

हालांकि, ध्यान दें कि हमने अपने समाधान को जिस तरह से डिजाइन किया था, उसमें खामियां थीं।

कहते हैं कि हमारे पास एक नया आकार पेंटागन है। उस स्थिति में, हम फिर से एरिया कैक्लकुलर क्लास को संशोधित करेंगे। जैसा कि आकार के प्रकार बढ़ते हैं, यह गड़बड़ हो जाता है क्योंकि एरियाकैकुलरेटर बदलता रहता है और इस वर्ग के किसी भी उपभोक्ता को अपने पुस्तकालयों को अपडेट करना जारी रखना होगा जिसमें एरियाकैकुलरेटर शामिल हैं। नतीजतन, निश्चित रूप से हर बार एक नया आकार आने के बाद, एरियाकैक्टर वर्ग को आधारभूत (अंतिम रूप) नहीं दिया जाएगा। इसलिए, यह डिज़ाइन संशोधन के लिए बंद नहीं है।

AreaCalculator को नए तरीकों में अपने संगणना तर्क को जोड़ते रहना होगा। हम वास्तव में आकृतियों के दायरे का विस्तार नहीं कर रहे हैं, बल्कि हम हर आकार के लिए टुकड़ा-भोजन (बिट-बाय-बिट) समाधान कर रहे हैं।

खुले / बंद सिद्धांत का पालन करने के लिए उपरोक्त डिजाइन का संशोधन:

आइए अब हम एक और अधिक सुंदर डिजाइन देखते हैं जो ओपन / बंद सिद्धांत का पालन करके उपरोक्त डिजाइन की खामियों को हल करता है। हम सबसे पहले डिजाइन को एक्स्टेंसिबल बनाएंगे। इसके लिए हमें पहले एक आधार प्रकार के आकार को परिभाषित करने की आवश्यकता है और सर्किल और आयत को आकृति इंटरफ़ेस लागू करना होगा।

सार्वजनिक इंटरफ़ेस आकार {सार्वजनिक डबल कैलक्लेअरआरे ()} पब्लिक क्लास रेक्टेंगल इम्प्लीमेंट्स शेप {डबल लेंथ डबल चौड़ाई पब्लिक डबल कैलक्एरेआ () {रिटर्न लेंथ * चौड़ाई}} पब्लिक क्लास सर्कल इम्प्लीमेंट्स शेप {पब्लिक डबल रेडियस पब्लिक डबल कैलक्लेरिया () {रिटर्न (22) / 7) * त्रिज्या * त्रिज्या}}

बेस इंटरफेस शेप है। सभी आकृतियाँ अब आधार इंटरफ़ेस शेप को लागू करती हैं। आकृति इंटरफ़ेस में एक अमूर्त विधि गणना है ()। सर्कल और आयत दोनों अपने स्वयं के गुणों का उपयोग करके गणना () विधि के अपने स्वयं के ओवरराइड कार्यान्वयन को प्रदान करते हैं।
हम विस्तार की एक डिग्री में लाए हैं क्योंकि आकार अब आकृति इंटरफेस का एक उदाहरण है। यह हमें व्यक्तिगत कक्षाओं के बजाय आकार का उपयोग करने की अनुमति देता है
ऊपर दिए गए अंतिम बिंदु इन आकृतियों के उपभोक्ता हैं। हमारे मामले में, उपभोक्ता AreaCalculator वर्ग होगा जो अब इस तरह दिखेगा।

सार्वजनिक वर्ग क्षेत्रसंपादित करें {सार्वजनिक दोहरा परिकलनशेयर (आकृति आकार) {लौटाने का आकार

यह क्षेत्रपालकक्लास अब हमारे डिज़ाइन किए गए दोषों को पूरी तरह से हटा देता है और एक साफ समाधान देता है जो ओपन-क्लोज्ड सिद्धांत का पालन करता है। जावा में अन्य ठोस सिद्धांतों के साथ चलते हैं

जावा में Liskov प्रतिस्थापन सिद्धांत

रॉबर्ट सी। मार्टिन इसका वर्णन करते हैं कि उनके प्रकारों के लिए व्युत्पन्न प्रकारों को पूरी तरह से प्रतिस्थापित किया जाना चाहिए।

Liskov प्रतिस्थापन सिद्धांत क्यू (एक्स) को एक संपत्ति मानता है, एक्स की संस्थाओं के बारे में सिद्ध होता है जो टाइप टी के अंतर्गत आता है। अब, इस सिद्धांत के अनुसार, क्यू (वाई) को उन वस्तुओं के लिए उपयुक्त होना चाहिए, जो टाइप एस से संबंधित हैं, और S वास्तव में T का एक उप प्रकार है। क्या आप अब भ्रमित हैं और नहीं जानते कि Liskov प्रतिस्थापन सिद्धांत का वास्तव में क्या मतलब है? इसकी परिभाषा थोड़ी जटिल हो सकती है, लेकिन वास्तव में, यह काफी आसान है। केवल एक चीज यह है कि प्रत्येक उपवर्ग या व्युत्पन्न वर्ग को अपने माता-पिता या आधार वर्ग के लिए स्थानापन्न होना चाहिए।

आप कह सकते हैं कि यह एक अद्वितीय वस्तु-उन्मुख सिद्धांत है। सिद्धांत को आगे किसी विशेष प्रकार के माता-पिता के बच्चे द्वारा सरल बनाया जा सकता है बिना किसी जटिलता या उड़ाने वाली चीजों में उस माता-पिता के लिए खड़े होने की क्षमता होनी चाहिए। यह सिद्धांत Liskov प्रतिस्थापन सिद्धांत से निकटता से संबंधित है।

ऐसा क्यों है कि इस सिद्धांत की आवश्यकता है?

यह वंशानुक्रम के दुरुपयोग से बचा जाता है। यह हमें '-ए' रिश्ते के अनुरूप होने में मदद करता है। हम यह भी कह सकते हैं कि उपवर्गों को आधार वर्ग द्वारा परिभाषित अनुबंध को पूरा करना होगा। इस अर्थ में, यह संबंधित हैअनुबंध द्वारा डिजाइनयह पहली बार बर्ट्रेंड मेयर द्वारा वर्णित किया गया था। उदाहरण के लिए, यह कहना आकर्षक है कि एक चक्र एक प्रकार का दीर्घवृत्त है, लेकिन मंडलियों में दो foci या प्रमुख / लघु अक्ष नहीं होते हैं।

एलएसपी को स्क्वायर और आयत उदाहरण का उपयोग करके लोकप्रिय रूप से समझाया गया है। अगर हम स्क्वायर और रेक्टेंगल के बीच ISA संबंध मानते हैं। इस प्रकार, हम कहते हैं 'स्क्वायर एक आयत है।' नीचे दिए गए कोड रिश्ते को दर्शाता है।

सार्वजनिक वर्ग आयत {निजी int लंबाई निजी int चौड़ाई सार्वजनिक int getLength () {वापसी लंबाई} सार्वजनिक शून्य setLength (int लंबाई) {this.length = लंबाई} सार्वजनिक int getBreadth () {वापसी चौड़ाई} सार्वजनिक शून्य setBreadth (int चौड़ाई) { this.breadth = breadth} सार्वजनिक int getArea () {इसे वापस लौटाएँ। इस * .breadth}}

नीचे स्क्वायर के लिए कोड है। ध्यान दें कि स्क्वायर आयत का विस्तार करता है।

दशमलव कनवर्टर जावा के लिए द्विआधारी

सार्वजनिक वर्ग स्क्वायर आयत {public void setBreadth (int चौड़ाई) {super.setBreadth (चौड़ाई) super.setLength (चौड़ाई)} public void setLength (int लंबाई) {super.setbength (लंबाई) super.setBreadth (लंबाई)}} को बढ़ाता है

इस मामले में, हम स्क्वायर और आयत के बीच आईएसए संबंध स्थापित करने की कोशिश करते हैं, जैसे कि कॉलिंग 'स्क्वायर एक आयत है' नीचे दिए गए कोड में अप्रत्याशित रूप से व्यवहार करना शुरू कर देंगे यदि स्क्वायर का एक उदाहरण पारित हो जाता है। 'क्षेत्र' के लिए जाँच करने और 'चौड़ाई' की जाँच करने के मामले में एक जोरदार त्रुटि डाली जाएगी, हालाँकि कार्यक्रम की जाँच विफल हो जाएगी क्योंकि क्षेत्र की जाँच में विफलता के कारण फेंक दिया गया है।

सार्वजनिक वर्ग LSPDemo {सार्वजनिक शून्य गणना (आयत r) {r.setBreadth (2) r.setLength (3) मुखर r.getArea () == 6: PrintError ('क्षेत्र', r) मुखर r.getLength () == 3: PrintError ('लंबाई', r) मुखर r.getBreadth () == 2: PrintError ('चौड़ाई', r)} निजी स्ट्रिंग PrintError (स्ट्रिंग errorIdentifer, आयत r) {वापसी 'का अप्रत्याशित मान' + errorIdentifer + ' उदाहरण के लिए '+ r.getClass ()। getName ()} सार्वजनिक स्थैतिक शून्य मुख्य (स्ट्रिंग [] args) {LSPDemo lsp = new LSPDemo () // आयत का एक उदाहरण lsp.calculateArea (नया आयत) () उत्तीर्ण किया गया है। // स्क्वायर का एक उदाहरण lsp.calculateArea (नया स्क्वायर ())} है

वर्ग Liskov प्रतिस्थापन सिद्धांत (LSP) प्रदर्शित करता है सिद्धांत के अनुसार, आधार कक्षाओं के संदर्भों का उपयोग करने वाले कार्यों को यह जानने के बिना व्युत्पन्न वर्ग की वस्तुओं का उपयोग करने में सक्षम होना चाहिए।

इस प्रकार, नीचे दिखाए गए उदाहरण में, फ़ंक्शन गणना 'एरेक्टैंगल' के संदर्भ का उपयोग करती है, जो वर्ग के रूप में व्युत्पन्न वर्ग की वस्तुओं का उपयोग करने में सक्षम होना चाहिए और आयत परिभाषा द्वारा उत्पन्न आवश्यकता को पूरा करना चाहिए। यह ध्यान रखना चाहिए कि आयत की परिभाषा के अनुसार, नीचे दिए गए डेटा को हमेशा सही रखना चाहिए:

1. लंबाई हमेशा विधि, सेटलिफ्ट के इनपुट के रूप में पारित लंबाई के बराबर होनी चाहिए
2. चौड़ाई को हमेशा विधि, सेटब्रेडथ के इनपुट के रूप में पारित चौड़ाई के बराबर होना चाहिए
3. क्षेत्र को हमेशा लंबाई और चौड़ाई के उत्पाद के बराबर होना चाहिए

यदि हम स्क्वायर और रेक्टैंगल के बीच आईएसए संबंध स्थापित करने की कोशिश करते हैं, जिसे हम 'स्क्वायर आयत है' कहते हैं, तो उपरोक्त कोड अप्रत्याशित रूप से व्यवहार करना शुरू कर देगा यदि स्क्वायर का एक उदाहरण पारित किया जाता है, तो क्षेत्र और चेक के मामले में जोर त्रुटि को फेंक दिया जाएगा। चौड़ाई के लिए, हालांकि कार्यक्रम समाप्त हो जाएगा क्योंकि क्षेत्र की जांच में विफलता के कारण जोर दिया गया है।

स्क्वायर वर्ग को सेटब्रेड्थ या सेटलॉग्रैथ जैसे तरीकों की आवश्यकता नहीं होती है। LSPDemo वर्ग को फेंकने की त्रुटि से बचने के लिए आयत (जैसे कि स्क्वायर) के व्युत्पन्न वर्गों के विवरण को उचित रूप से कोड करने की आवश्यकता होगी। मौजूदा कोड में परिवर्तन पहली बार में खुले-बंद सिद्धांत को तोड़ता है।

इंटरफ़ेस अलगाव सिद्धांत

रॉबर्ट सी। मार्टिन इसका वर्णन करते हैं कि ग्राहकों को अनावश्यक तरीकों को लागू करने के लिए मजबूर नहीं किया जाना चाहिए जो वे उपयोग नहीं करेंगे।

के अनुसारइंटरफ़ेस अलगाव सिद्धांतएक क्लाइंट, चाहे वह किसी भी इंटरफ़ेस को लागू करने के लिए मजबूर न हो, जिसे वह उपयोग नहीं करता है या क्लाइंट को किसी भी विधि पर निर्भर होने के लिए बाध्य नहीं किया जाना चाहिए, जो उनके द्वारा उपयोग नहीं किया जाता है। मूल रूप से, इंटरफ़ेस अलगाव के सिद्धांत जैसा कि आप पसंद करते हैं। इंटरफेस, जो अखंड और बड़े इंटरफ़ेस के बजाय छोटे लेकिन क्लाइंट विशिष्ट होते हैं। संक्षेप में, आपके लिए क्लाइंट को एक निश्चित चीज़ पर निर्भर होने के लिए मजबूर करना बुरा होगा, जिसकी उन्हें ज़रूरत नहीं है।

उदाहरण के लिए, लॉग लिखने और पढ़ने के लिए एकल लॉगिंग इंटरफ़ेस डेटाबेस के लिए उपयोगी है, लेकिन कंसोल के लिए नहीं। रीडिंग लॉग कंसोल कंसोल के लिए कोई मतलब नहीं है। जावा लेख में इस ठोस सिद्धांतों के साथ आगे बढ़ना।

ऐसा क्यों है कि इस सिद्धांत की आवश्यकता है?

बता दें कि एक रेस्तरां इंटरफ़ेस है जिसमें ऑनलाइन ग्राहकों, डायल-इन या टेलीफोन ग्राहकों और वॉक-इन ग्राहकों से ऑर्डर स्वीकार करने के तरीके शामिल हैं। इसमें ऑनलाइन भुगतान (ऑनलाइन ग्राहकों के लिए) और इन-व्यक्ति भुगतान (वॉक-इन ग्राहकों के साथ-साथ टेलीफोन ग्राहकों के लिए जब उनका ऑर्डर घर पर दिया जाता है) से निपटने के तरीके भी शामिल हैं।

अब हम रेस्तरां के लिए एक जावा इंटरफेस बनाते हैं और इसे रेस्तरांइंटरफेस.जवा नाम देते हैं।

सार्वजनिक इंटरफ़ेस भोजनालयइंटरफेस {सार्वजनिक शून्य स्वीकार करेंऑनलाइनरडर () सार्वजनिक शून्य टेकटेलफ़ोनरडर () सार्वजनिक शून्य भुगतानऑनलाइन () सार्वजनिक शून्य चलनाइन्कॉर्टरऑर्डर () सार्वजनिक शून्य भुगतानकर्ता ()}

रेस्तरांइंटरफेस में परिभाषित 5 विधियां हैं जो ऑनलाइन ऑर्डर को स्वीकार करने, टेलिफोनिक ऑर्डर लेने, वॉक-इन कस्टमर से ऑर्डर स्वीकार करने, ऑनलाइन भुगतान स्वीकार करने और व्यक्ति में भुगतान स्वीकार करने के लिए हैं।

हमें OnlineClientImpl.java के रूप में ऑनलाइन ग्राहकों के लिए रेस्तरांइंटरफेस लागू करके शुरू करते हैं

सार्वजनिक वर्ग OnlineClientImpl लागू करता है RestaurantInterface {सार्वजनिक शून्य स्वीकार करेंऑनलाइनऑर्डर () {// ऑनलाइन ऑर्डर देने के लिए तर्क} सार्वजनिक शून्य takeTelephoneOrder () {// ऑनलाइन आदेश के लिए लागू नहीं है ऑनलाइन} public void walkInCustomerOrder () {// ऑनलाइन ऑर्डर के लिए लागू नहीं है नया UnsupportedOperationException ()} सार्वजनिक शून्य payInPerson () {// नहीं लागू ऑनलाइन ऑर्डर के लिए लागू होता है नए UnoedOperationException ()}}

• चूंकि उपरोक्त कोड (OnlineClientImpl.java) ऑनलाइन ऑर्डर के लिए है, इसलिए UnsupportedOperationException को फेंक दें।

• ऑनलाइन, टेलीफ़ोनिक और वॉक-इन क्लाइंट उनमें से प्रत्येक के लिए विशिष्ट रेस्तरांइंटरफेस कार्यान्वयन का उपयोग करते हैं।

• टेलिफोनिक क्लाइंट और वॉक-इन क्लाइंट के कार्यान्वयन वर्गों में असमर्थित विधियां होंगी।

• चूंकि 5 विधियां रेस्तरांइंटरफेस का हिस्सा हैं, इसलिए कार्यान्वयन कक्षाओं को उनमें से सभी 5 को लागू करना होगा।

• कार्यान्वयन कक्षाओं में से प्रत्येक के तरीके UnsupportedOperationException को फेंक देते हैं। जैसा कि आप स्पष्ट रूप से देख सकते हैं - सभी तरीकों को लागू करना अक्षम है।

• रेस्तरांइंटरफेस के किसी भी तरीके में कोई भी बदलाव सभी कार्यान्वयन वर्गों के लिए प्रचारित किया जाएगा। कोड का रखरखाव तब वास्तव में बोझिल होने लगता है और परिवर्तनों का प्रतिगमन प्रभाव बढ़ता रहेगा।

• RestaurantInterface.java एकल जिम्मेदारी सिद्धांत को तोड़ता है क्योंकि भुगतान के लिए तर्क के साथ-साथ ऑर्डर प्लेसमेंट के लिए एकल इंटरफ़ेस में एक साथ समूहीकृत किया जाता है।

उपर्युक्त समस्याओं को दूर करने के लिए, हम उपरोक्त डिज़ाइन को रिफलेक्टर करने के लिए इंटरफ़ेस सेग्रीगेशन सिद्धांत लागू करते हैं।

1. पेमेंट और ऑर्डर प्लेसमेंट फंक्शनलिटीज को दो अलग-अलग लीन इंटरफेस, पेमेंटइंटरफेस.जवा और ऑर्डरइंटरफेस.जवा में अलग करें।

2. प्रत्येक क्लाइंट पेमेंटइंटरफेस और ऑर्डरइंटरफेस में से प्रत्येक के एक कार्यान्वयन का उपयोग करता है। उदाहरण के लिए - OnlineClient.java OnlinePaymentImpl और OnlineOrderImpl का उपयोग करता है।

3. सिंगल रिस्पांसिबिलिटी सिद्धांत अब पेमेंट इंटरफेस (PaymentInterface.java) और ऑर्डरिंग इंटरफेस (ऑर्डरइंटरफेस) के रूप में संलग्न है।

4. आदेश या भुगतान इंटरफेस में से किसी एक में परिवर्तन दूसरे को प्रभावित नहीं करता है। वे अब स्वतंत्र हैं। किसी भी डमी कार्यान्वयन को करने की आवश्यकता नहीं होगी या एक UnsupportedOperationException को फेंकना होगा क्योंकि प्रत्येक इंटरफ़ेस में केवल विधियां हैं जो इसका हमेशा उपयोग करेगी।

ISP लगाने के बाद

निर्भरता उलटा सिद्धांत

रॉबर्ट सी। मार्टिन इसका वर्णन करते हैं क्योंकि यह अमूर्तता पर निर्भर करता है न कि सहमति पर। इसके अनुसार, उच्च-स्तरीय मॉड्यूल को कभी भी निम्न-स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। उदाहरण के लिए

आप कुछ खरीदने के लिए एक स्थानीय स्टोर पर जाते हैं, और आप अपने डेबिट कार्ड का उपयोग करके इसके लिए भुगतान करने का निर्णय लेते हैं। इसलिए, जब आप भुगतान करने के लिए अपना कार्ड क्लर्क को देते हैं, तो क्लर्क यह जाँचने के लिए परेशान नहीं होता है कि आपने किस तरह का कार्ड दिया है।

यहां तक ​​कि अगर आपने वीज़ा कार्ड दिया है, तो भी वह आपके कार्ड को स्वाइप करने के लिए वीज़ा मशीन नहीं देगा। क्रेडिट कार्ड या डेबिट कार्ड का प्रकार जो आपको भुगतान करने के लिए है, इससे कोई फर्क नहीं पड़ता कि वे बस इसे स्वाइप करेंगे। इसलिए, इस उदाहरण में, आप देख सकते हैं कि आप और क्लर्क दोनों क्रेडिट कार्ड के अमूर्त पर निर्भर हैं और आप कार्ड की बारीकियों के बारे में चिंतित नहीं हैं। यह एक निर्भरता उलटा सिद्धांत है।

ऐसा क्यों है कि इस सिद्धांत की आवश्यकता है?

यह एक प्रोग्रामर को हार्डकोडेड निर्भरता को हटाने की अनुमति देता है ताकि एप्लिकेशन शिथिल रूप से युग्मित और विस्तार योग्य हो जाए।

पब्लिक क्लास स्टूडेंट {निजी एड्रेस एड्रेस पब्लिक स्टूडेंट () {एड्रेस = नया एड्रेस ()}}

उपरोक्त उदाहरण में, छात्र वर्ग को एक एड्रेस ऑब्जेक्ट की आवश्यकता होती है और यह एड्रेस ऑब्जेक्ट को शुरू करने और उपयोग करने के लिए जिम्मेदार है। अगर भविष्य में एड्रेस क्लास को बदला जाता है तो हमें स्टूडेंट क्लास में भी बदलाव करने होंगे। यह स्टूडेंट और एड्रेस ऑब्जेक्ट्स के बीच की कड़ी युग्मन को बनाता है। हम निर्भरता व्युत्क्रम डिजाइन पैटर्न का उपयोग करके इस समस्या को हल कर सकते हैं। अर्थात पता ऑब्जेक्ट को स्वतंत्र रूप से लागू किया जाएगा और छात्र को तब प्रदान किया जाएगा जब छात्र कंस्ट्रक्टर-आधारित या सेटर-आधारित निर्भरता व्युत्क्रम का उपयोग करके त्वरित किया जाता है।

इसके साथ, हम जावा में इस SOLID सिद्धांतों के अंत में आते हैं।

इसकी जाँच पड़ताल करो 250,000 से अधिक संतुष्ट शिक्षार्थियों के एक नेटवर्क के साथ एक विश्वसनीय ऑनलाइन शिक्षण कंपनी, एडुरेका द्वारा, दुनिया भर में फैली हुई है। एडुर्का के जावा जे 2 ईई और एसओए प्रशिक्षण और प्रमाणन पाठ्यक्रम उन छात्रों और पेशेवरों के लिए डिज़ाइन किया गया है जो जावा डेवलपर बनना चाहते हैं। पाठ्यक्रम आपको जावा प्रोग्रामिंग में एक शुरुआत देने के लिए डिज़ाइन किया गया है और आपको हाइबरनेट और स्प्रिंग जैसे विभिन्न जावा फ्रेमवर्क के साथ कोर और उन्नत जावा अवधारणाओं दोनों के लिए प्रशिक्षित करता है।

क्या आप हमसे कोई प्रश्न पूछना चाहते हैं? कृपया इसे 'जावा में ठोस सिद्धांतों' के टिप्पणी अनुभाग में उल्लेख करें और हम जल्द से जल्द आपके पास वापस आ जाएंगे।

जावा में शब्दकोश डेटा संरचना