जावा में सार वर्गों के विशिष्ट उदाहरण

नमस्ते! पिछले पाठों में, हम इंटरफेस से मिले और पता लगाया कि वे किस लिए हैं। आज का विषय पिछले वाले को प्रतिध्वनित करेगा। आइए जावा में अमूर्त कक्षाओं के बारे में बात करते हैं।

कक्षाओं को 'सार' क्यों कहा जाता है

आपको शायद याद होगा कि 'अमूर्तता' क्या है — हम पहले ही इसके बारे में जान चुके हैं। :) अगर आप भूल गए, डरो मत। याद रखें: यह ओओपी का एक सिद्धांत है जो कहता है कि कक्षाओं को डिजाइन करते समय और वस्तुओं को बनाते समय, हमें केवल इकाई के मुख्य गुणों की पहचान करनी चाहिए और गौण को छोड़ देना चाहिए। उदाहरण के लिए, यदि हम एक SchoolTeacherवर्ग डिजाइन कर रहे हैं, तो हमें शायद ही ' ऊँचाई ' गुण की आवश्यकता है। दरअसल, यह संपत्ति एक शिक्षक के लिए अप्रासंगिक है। लेकिन अगर हम एक BasketballPlayerवर्ग बना रहे हैं, तो विकास एक महत्वपूर्ण लक्षण होगा। तो सुनिए। एक सार वर्गउतना ही अमूर्त है जितना वे आते हैं - भविष्य की कक्षाओं के समूह के लिए एक अधूरा 'रिक्त'। रिक्त का उपयोग इस रूप में नहीं किया जा सकता है। यह बहुत 'कच्चा' है। लेकिन यह कुछ निश्चित राज्य और सामान्य व्यवहार का वर्णन करता है जो कि भविष्य के वर्गों के पास होगा जो अमूर्त वर्ग को विरासत में मिला है।

सार जावा कक्षाओं के उदाहरण

कारों के साथ एक साधारण उदाहरण पर विचार करें:

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public abstract void gas();

   public abstract void brake();

   public String getModel() {
       return model;
   }

   public void setModel(String model) {
       this.model = model;
   }

   public String getColor() {
       return color;
   }

   public void setColor(String color) {
       this.color = color;
   }

   public int getMaxSpeed() {
       return maxSpeed;
   }

   public void setMaxSpeed(int maxSpeed) {
       this.maxSpeed = maxSpeed;
   }
}

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

public class Sedan extends Car {

   @Override
   public void gas() {
       System.out.println("The sedan is accelerating!");
   }

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

यह उससे काफी मिलता-जुलता है जिसके बारे में हमने वंशानुक्रम के पाठों में बात की थी। लेकिन उन पाठों में, हमारे पास एक Car क्लास थी और इसके तरीके अमूर्त नहीं थे। लेकिन उस समाधान में कई कमियां हैं जो अमूर्त कक्षाओं में तय की गई हैं। सबसे पहले और सबसे महत्वपूर्ण, आप एक सार वर्ग का उदाहरण नहीं बना सकते :

public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Error! The Car class is abstract!
   }
}

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

public class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       // Some logic
   }

    public void brake() {
       // Some logic
   }
}


public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Everything is fine. A car is created.
   }
}

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

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       System.out.println("Gas!");
   }

   public abstract void brake();

   // Getters and setters
}


public class Sedan extends Car {

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

public class Main {

   public static void main(String[] args) {

       Sedan sedan = new Sedan();
       sedan.gas();
   }
}

Sedanकंसोल आउटपुट : "गैस!gas() " अमूर्त मूल वर्ग तक 'उगता है' Car, लेकिन हम कक्षा brake()में विधि को ओवरराइड करते Sedanहैं। यह बहुत सुविधाजनक और लचीला निकला। लेकिन अब हमारी कक्षा इतनी सारगर्भित नहीं है ? आखिरकार, इसके आधे तरीके लागू हो गए हैं। यह वास्तव में एक बहुत ही महत्वपूर्ण विशेषता है - एक वर्ग सार है यदि इसकी कम से कम एक विधि सार है. दो तरीकों में से एक, या कम से कम एक हजार तरीकों में से एक - इससे कोई फर्क नहीं पड़ता। हम सभी विधियों को लागू भी कर सकते हैं और उनमें से किसी को भी सार नहीं छोड़ सकते। तब यह सार विधियों के बिना एक सार वर्ग होगा। सिद्धांत रूप में, यह संभव है, और संकलक त्रुटियों को उत्पन्न नहीं करेगा, लेकिन इससे बचना बेहतर है: सार शब्द अपना अर्थ खो देता है, और आपके साथी प्रोग्रामर बहुत आश्चर्यचकित होंगे: / उसी समय, यदि कोई विधि चिह्नित है सार शब्द के साथ, प्रत्येक बच्चे वर्ग को इसे लागू करना चाहिए या इसे सार के रूप में घोषित करना चाहिए। अन्यथा, कंपाइलर एक त्रुटि उत्पन्न करेगा। बेशक, प्रत्येक वर्ग केवल एक अमूर्त वर्ग को प्राप्त कर सकता है, इसलिए वंशानुक्रम के संदर्भ में सार और साधारण वर्गों के बीच कोई अंतर नहीं है। इससे कोई फर्क नहीं पड़ता कि हम एक अमूर्त वर्ग या एक सामान्य वर्ग को प्राप्त करते हैं, केवल एक मूल वर्ग हो सकता है।

जावा में कक्षाओं की एकाधिक विरासत क्यों नहीं है I

हम पहले ही कह चुके हैं कि जावा में एकाधिक विरासत नहीं है, लेकिन हमने वास्तव में क्यों नहीं खोजा है। आइए अब ऐसा करने का प्रयास करें। तथ्य यह है कि यदि जावा में एकाधिक विरासत होती है, तो बाल वर्ग यह तय करने में सक्षम नहीं होंगे कि उन्हें कौन सा विशिष्ट व्यवहार चुनना चाहिए। मान लीजिए हमारे पास दो वर्ग हैं - Toasterऔर NuclearBomb:

public class Toaster {


 public void on() {

       System.out.println("The toaster is on. Toast is being prepared!");
   }

   public void off() {

       System.out.println("The toaster is off!");
   }
}


public class NuclearBomb {

   public void on() {

       System.out.println("Boom!");
   }
}

जैसा कि आप देख सकते हैं, दोनों के पास एक on()तरीका है। टोस्टर के लिए, यह टोस्ट होना शुरू हो जाता है। परमाणु बम के लिए, यह एक विस्फोट करता है। उफ़: / अब कल्पना कीजिए कि आपने बीच में कुछ बनाने का फैसला किया है (मुझसे ऐसा क्यों न पूछें!) और इस प्रकार आपके पास एक MysteriousDeviceवर्ग है! यह कोड, निश्चित रूप से काम नहीं करता है, और हम इसे केवल एक उदाहरण के रूप में प्रदान करते हैं 'लेकिन यह हो सकता है':

public class MysteriousDevice extends Toaster, NuclearBomb {

   public static void main(String[] args) {

       MysteriousDevice mysteriousDevice = new MysteriousDevice();
       mysteriousDevice.on(); // So what should happen here? Do we get toast or a nuclear apocalypse?
   }
}

आइए देखें कि हमारे पास क्या है। रहस्यमय उपकरण एक साथ टोस्टर और न्यूक्लियरबॉम्ब को विरासत में मिला है। दोनों के on()तरीके हैं। नतीजतन, अगर हम विधि कहते हैं , तो यह स्पष्ट नहीं है कि वस्तु on()पर किसको लागू किया जाना चाहिए । MysteriousDeviceऐसा कोई तरीका नहीं है जिससे वस्तु कभी जान सके। और इन सबसे ऊपर: न्यूक्लियरबॉम्ब के पास कोई off()विधि नहीं है, इसलिए यदि हमने सही अनुमान नहीं लगाया, तो डिवाइस को अक्षम करना असंभव होगा। यह इस 'भ्रम' के कारण ठीक है, जहां वस्तु को पता नहीं है कि किस व्यवहार को प्रदर्शित करना है, कि जावा के रचनाकारों ने एकाधिक वंशानुक्रम को छोड़ दिया। हालाँकि, आपको याद होगा कि जावा कक्षाएं कई इंटरफेस को लागू कर सकती हैं। वैसे, अपनी पढ़ाई में, आप पहले ही कम से कम एक सार वर्ग का सामना कर चुके हैं!

public abstract class Calendar implements Serializable, Cloneable, Comparable<Calendar>

यह आपका पुराना मित्र है, Calendarवर्ग। यह अमूर्त है और इसके कई बच्चे हैं। उनमें से एक है GregorianCalendar। आप पहले ही तारीखों के बारे में पाठों में इसका उपयोग कर चुके हैं। :) सब कुछ पर्याप्त स्पष्ट लगता है. बस एक ही सवाल है: वैसे भी सार वर्गों और इंटरफेस के बीच मूलभूत अंतर क्या है? भाषा को केवल एक तक सीमित करने के बजाय उन्होंने जावा में दोनों को क्यों जोड़ा? आखिरकार, यह पूरी तरह से पर्याप्त होता। हम इसके बारे में अगले पाठ में बात करेंगे ! तब तक :)