सार वर्ग

"हैलो, अमीगो! हमारे पास एक आकर्षक नया विषय है।"

"आज सिर्फ आकर्षक विषयों का दिन है!"

"क्यों धन्यवाद!"

"आपका स्वागत है।"

"याद रखें जब हमने शतरंज के टुकड़ों के लिए सभी वर्गों को सरल बनाने के लिए ChessItem बेस क्लास की शुरुआत की थी?"

"हाँ।"

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

"हाँ।" बहुरूपता के बारे में जानने के बाद, मैं उनके प्रकार की परवाह किए बिना, सभी टुकड़ों के लिए रेंडर विधि को कॉल करने में सक्षम हो जाऊंगा। कुछ इस तरह:"

class ChessBoard
{
  public void drawAllChessItems()
  {
  //draw them regardless of their type.
  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 क्लास की ड्रॉ विधि से क्या होगा?"

"मुझे नहीं पता। शतरंज में ऐसा कोई टुकड़ा नहीं है। और इसका मतलब है कि इसका कोई दृश्य प्रतिनिधित्व नहीं है।"

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

इसके लिए जावा के पास एक विशेष वर्ग प्रकार है: सार वर्ग । अमूर्त कक्षाओं के बारे में याद रखने वाली तीन बातें यहां दी गई हैं।

1) एक सार वर्ग उन्हें लागू किए बिना विधियों की घोषणा कर सकता है। ऐसी विधि को अमूर्त विधि कहते हैं।

 public abstract class ChessItem
{
 public int x, y; //coordinates
 private int value; //the piece's "value"

 public int getValue() //an ordinary method, returns value
 {
   return value;
 }

 public abstract void draw(); //abstract method. There is no implementation.

}

2) सार पद्धति को कीवर्ड सार के साथ चिह्नित किया गया है ।

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

3) आप एक अमूर्त वर्ग की वस्तुएँ नहीं बना सकते। ऐसा करने का प्रयास करने वाला कोड संकलित नहीं होगा।

ChessItem item = new ChessItem();
item.draw();

ChessItem item = new Queen();
item.draw();

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

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

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

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

"मुझे अभी भी समझ नहीं आया कि हम अपने जीवन को इस तरह से जटिल क्यों बनाना चाहेंगे।"

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