CodeGym /Java Course /All lectures for HI purposes /सार कक्षाएं

सार कक्षाएं

All lectures for HI purposes
स्तर 1 , सबक 566
उपलब्ध

1. सामान्य आधार वर्ग

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

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

यदि draw()विधि ChessItem बेस क्लास में थी, तो हम इसे पीस क्लास में ओवरराइड कर सकते हैं और इस तरह से एलिगेंट कोड लिख सकते हैं:

class ChessBoard
{
   public void drawAllChessItems()
   {
      // Add the pieces to the list
      ArrayList<ChessItem> items = new ArrayList<ChessItem>();
      items.add(new King());
      items.add(new Queen());
      items.add(new Bishop());

      // Draw them regardless of their type
      for(ChessItem item: items)
      {
         item.draw();
      }
   }
}

बेस क्लास की शुरुआत करके ChessItem, हम कोड को बहुत सरल बनाने में सक्षम थे: प्रत्येक वर्ग के तरीकों को अलग से कॉल करने की कोई आवश्यकता नहीं है, हम सभी वस्तुओं को एक ही संग्रह में आसानी से स्टोर कर सकते हैं, आदि।

लेकिन यहां एक दिलचस्प सवाल है: कक्षा draw()में सीधे घोषित विधि को ChessItemस्क्रीन पर क्या दिखाना चाहिए? आखिरकार, शतरंज में ऐसा कोई मोहरा नहीं होता, इसलिए खींचने के लिए कुछ भी नहीं है।

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


2. सार वर्ग

सार कक्षाएं

ऐसी स्थितियों के लिए, जावा में एक विशेष प्रकार का वर्ग है: अमूर्त वर्ग । वे प्रोग्रामर के लिए समान वर्गों के साथ काम करना आसान बनाने और उनमें डुप्लिकेट कोड की मात्रा को कम करने के लिए डिज़ाइन किए गए हैं।

अमूर्त कक्षाओं के बारे में जानने के लिए यहां तीन बातें हैं।

कार्यान्वयन के बिना विधि

एक सार वर्ग में कार्यान्वयन के बिना एक विधि घोषणा हो सकती है। यह वही है जो विधि को अमूर्त बनाता है। विधि निकाय को केवल अर्धविराम से बदल दिया जाता है। और मेथड के नाम से पहले हम abstractकीवर्ड लिखते हैं। उदाहरण:

public abstract class ChessItem
{
   public int x, y; // Coordinates
   private int value; // The piece's value
   public int getValue() // Ordinary method that returns value field
   {
      return value;
   }

   public abstract void draw(); // Abstract method. The implementation is missing.
}

सार वर्ग

कार्यान्वयन के बिना प्रत्येक विधि को सार कीवर्ड के साथ चिह्नित किया गया है। यदि किसी वर्ग में एक सार विधि भी है, तो कक्षा को भी abstractकीवर्ड के साथ चिह्नित किया जाता है।

वस्तुओं के निर्माण पर रोक लगाना

आप अमूर्त वर्ग के ऑब्जेक्ट नहीं बना सकते हैं । ऐसा कोड केवल संकलित नहीं होगा।

कोड विवरण
ChessItem item = new ChessItem();
item.draw();
यह कोड संकलित नहीं होता है :
ChessItem item = new Queen();
item.draw();
लेकिन आप ऐसा कर सकते हैं

एक अमूर्त वर्ग विरासत में मिला

यदि आपकी कक्षा को एक अमूर्त वर्ग विरासत में मिला है, तो आपको सभी विरासत में मिली अमूर्त विधियों को ओवरराइड करने की आवश्यकता है, अर्थात आपको उनके लिए एक कार्यान्वयन लिखने की आवश्यकता है। अन्यथा, आपकी कक्षा को भी सार घोषित करना होगा।

यदि किसी वर्ग में एक भी लागू नहीं की गई विधि को सीधे घोषित किया गया है या मूल वर्ग से विरासत में मिला है, तो वर्ग को सार माना जाता है।

और यह सब क्यों जरूरी है? अमूर्त कक्षाओं की आवश्यकता क्यों है? क्या इसके बजाय सामान्य लोगों का उपयोग करना संभव नहीं है? और सार विधियों के बजाय, क्या हम विधि निकाय के रूप में केवल दो खाली घुंघराले ब्रैकेट नहीं लिख सकते थे?

हम। लेकिन ये प्रतिबंध privateसंशोधक के समान हैं। हम निजी कीवर्ड का उपयोग जानबूझकर अन्य प्रोग्रामर को सीधे डेटा तक पहुंचने से रोकने के लिए करते हैं और उन्हें अपनी कक्षाएं लिखते समय केवल हमारे सार्वजनिक तरीकों का उपयोग करने के लिए मजबूर करते हैं।

अमूर्त वर्गों के साथ भी ऐसा ही है। एक अमूर्त वर्ग का लेखक नहीं चाहता कि वर्ग की वस्तुओं का निर्माण हो। इसके बजाय, लेखक को उम्मीद है कि अमूर्त तरीकों को अमूर्त वर्ग से विरासत में मिला होगा और फिर ओवरराइड किया जाएगा।

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


टिप्पणियां
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION