मेरे पिछले लेख के बाद, हम nil का उपयोग क्यों करते हैं, मुझे लगा कि अन्य चीजों के लिए भी यह सवाल पूछना एक अच्छा विचार होगा जिन्हें हम स्वाभाविक मान लेते हैं।
जैसे…
हम केवल एक विशाल बदसूरत कोड के ब्लॉब के बजाय क्लासेस का उपयोग क्यों करते हैं?
एक मौलिक स्तर पर, हम कोड और डेटा को तार्किक इकाइयों में व्यवस्थित करने के लिए क्लासेस का उपयोग करते हैं।
लेकिन इसमें इससे कहीं अधिक है।
एक क्लास आपको एक अमूर्तता बनाने की अनुमति देती है।
अमूर्तता क्या है?
आप हर एक दिन, हर एक मिनट अमूर्तता का उपयोग करते हैं।
वह कीबोर्ड जिस पर मैं यह टाइप कर रहा हूं, इसमें शामिल हैं:
- एक केबल
- चेरी MX ब्लैक स्विचेस
- प्लास्टिक का आवरण जो सब कुछ एक साथ रखता है
- सर्किट बोर्ड जो मेरे कंप्यूटर को विद्युत संकेत प्रसारित करता है
एक कीबोर्ड केवल एक अवधारणा है जो इन चीजों को सही तरीके से एक साथ रखने से उभरती है।
यह एक अमूर्तता है क्योंकि आपको यह जानने की आवश्यकता नहीं है कि यह आंतरिक रूप से कैसे काम करता है इसका उपयोग करने के लिए। आपको यह जानने की भी आवश्यकता नहीं है कि यह किन घटकों से बना है!
आप बस इसे प्लग इन करें और टाइप करना शुरू करें।
यही क्लासेस आपको करने की अनुमति देती हैं।
अमूर्तता महत्वपूर्ण क्यों है?
अमूर्तता आपको जटिलता प्रबंधित करने में मदद करती है।
जैसा कि स्टीव मैककोनेल कहते हैं:
"क्लास बनाने का एकमात्र सबसे महत्वपूर्ण कारण प्रोग्राम की जटिलता को कम करना है"
अमूर्तता यह कैसे पूरा करती है?
विवरण छिपाकर कि कोई चीज़ कैसे काम करती है और एक सार्वजनिक इंटरफेस के साथ इसकी सेवाओं को उजागर करके।
एक रूबी क्लास में इंटरफेस इसके पब्लिक मेथड्स से बना होता है। जबकि विवरण प्राइवेट मेथड्स के साथ छिपे होते हैं।

विवरण से मेरा मतलब है:
- इंस्टेंस वेरिएबल्स
- आंतरिक मेथड्स
- एल्गोरिदम और डेटा संरचनाएं
जब ये छिपे होते हैं तो आप उन्हें जब चाहें बदल सकते हैं, बिना अपने क्लास के उपयोगकर्ताओं को प्रभावित किए।
उदाहरण के लिए:
यदि आपके पास एक GPS क्लास है जो डेटा स्टोर करने के लिए एक सरणी का उपयोग करता है, और आपको पता होना चाहिए कि उस सरणी के इंडेक्स 0 पर आपको अक्षांश मिलेगा और इंडेक्स 1 देशांतर है, ये वे विवरण हैं जिन्हें आपको क्लास के उपयोगकर्ता के रूप में जानने की आवश्यकता नहीं होनी चाहिए।
एक अच्छी क्लास कैसे लिखें
अब, यह एक बड़ा विषय है।
एक अच्छी क्लास बनाने में बहुत सी चीजें शामिल होती हैं, जैसे SOLID सिद्धांतों का पालन करना।
लेकिन सबसे महत्वपूर्ण बात, आपकी क्लासेस की कोई न कोई भूमिका होनी चाहिए, और यादृच्छिक मेथड्स से नहीं बनी होनी चाहिए।
उदाहरण के लिए, आप व्यावसायिक तर्क (गणना, नियम) को प्रस्तुति तर्क (फॉर्मेटिंग) से अलग करना चाहते हैं क्योंकि वे अलग-अलग भूमिकाएं हैं।
इस कोड को देखें:
require 'rest-client' require 'nokogiri' class ImageCounter def initialize(url) @url = url end def find_images_and_report data = RestClient.get(@url).body html = Nokogiri::HTML.parse(data) images = html.css("img") report = "" report << "=" * 40 << "\n" report << "Found #{images.size} images on #{@url} \n" report << "=" * 40 << "\n" end end reporter = ImageCounter.new("rubyguides.com") report = reporter.find_images_and_report आप देख सकते हैं कि यह क्लास गणना और प्रस्तुति दोनों से संबंधित है। यदि आप एक "क्विक एंड डर्टी" स्क्रिप्ट लिख रहे हैं तो यह ठीक है, लेकिन अधिक गंभीर एप्लिकेशन के लिए आप उन्हें अलग करना चाहते हैं।
जब आप जिम्मेदारियों को अलग करते हैं तो आप एक अलग प्रस्तुति परत प्लग इन कर सकते हैं, या आप व्यावसायिक नियमों को बदल सकते हैं और उसी प्रस्तुति का पुन: उपयोग कर सकते हैं।
क्लासेस का यह कोड पुन: उपयोग पहलू उन्हें अधिक लिखने का एक और अच्छा कारण है।
बेहतर क्लासेस लिखने में आपकी मदद करने के लिए और भी विचार हैं।
यहां कुछ हैं जो आपको आगे खोजने में मदद करेंगे:
- <
- Cohesion & Coupling
- Tell, don't ask
- Law of Demeter
यह जानना कि हम पहली जगह में क्लासेस क्यों लिखते हैं, शुरू करने के लिए एक अच्छी जगह है, इसलिए अच्छा काम अगर आपने पूरा लेख पढ़ा!
सारांश
आपने सीखा कि हम क्लासेस क्यों लिखते हैं, अमूर्तता क्या है और यह क्यों महत्वपूर्ण है। आपने अच्छी क्लासेस लिखने के मूल सिद्धांतों और क्या पढ़ना है इसके बारे में कुछ संकेत भी सीखे।
जब तक आप नहीं चाहते कि आपका कोड बिग बॉल ऑफ मड बन जाए, इन अवधारणाओं को अभी लागू करना शुरू करें ताकि आप अपने क्लास डिज़ाइन को बेहतर बना सकें 🙂
अगर आपको यह लेख उपयोगी लगा तो इसे ट्विटर पर शेयर करना न भूलें!