जावा में अमूर्त कक्षाओं के ठोस उदाहरण

नमस्ते! आइए जावा में अमूर्त कक्षाओं के बारे में बात करते हैं।

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

आपको शायद याद होगा कि अमूर्तता क्या है - हमने पहले इसकी चर्चा की थी :) यदि आप भूल गए, कोई चिंता नहीं। याद रखें, यह एक ओओपी सिद्धांत है जो कहता है, कक्षाओं को डिजाइन करते समय और ऑब्जेक्ट बनाते समय, आपको केवल इकाई के मुख्य गुणों का प्रतिनिधित्व करना चाहिए और द्वितीयक गुणों को त्यागना चाहिए। उदाहरण के लिए, यदि हम एक 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 go() {
       // ...some logic
   }

   public  void brake() {
       // ...some logic
   }
}


public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // This is okay. The car is created.
   }
}

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

public abstract class Car {

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

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

   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();
   }
}

कंसोल आउटपुट:

Accelerating!

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

जावा में एकाधिक वर्ग वंशानुक्रम क्यों नहीं है

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

public class Toaster {


 public void on() {

       System.out.println("The toaster is on. We're toasting!");
   }

   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 Toster, NuclearBomb {

   public static void main(String[] args) {

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

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