Java मधील अमूर्त वर्गांची विशिष्ट उदाहरणे

हाय! मागील धड्यांमध्ये, आम्ही इंटरफेस भेटलो आणि ते कशासाठी आहेत ते शोधून काढले. आजचा विषय मागील विषयाचा प्रतिध्वनी करेल. जावा मधील अमूर्त वर्गांबद्दल बोलूया .

वर्गांना 'अमूर्त' का म्हणतात

तुम्हाला कदाचित आठवत असेल की 'अमूर्तता' म्हणजे काय - आम्ही आधीच त्यावर गेलो आहोत. :) विसरलात तर घाबरू नका. लक्षात ठेवा: हे OOP चे एक तत्व आहे जे असे सांगते की क्लास डिझाइन करताना आणि ऑब्जेक्ट्स तयार करताना, आम्ही फक्त घटकाचे मुख्य गुणधर्म ओळखले पाहिजे आणि किरकोळ टाकून द्यावे. उदाहरणार्थ, जर आपण SchoolTeacherवर्ग डिझाइन करत असाल तर आपल्याला ' उंची ' गुणधर्माची फारशी गरज नाही. खरंच, ही मालमत्ता शिक्षकासाठी अप्रासंगिक आहे. परंतु जर आपण एक BasketballPlayerवर्ग तयार करत आहोत, तर वाढ ही एक महत्त्वाची वैशिष्ट्य असेल. तर ऐका. एक अमूर्त वर्गते येतात तितकेच अमूर्त आहे - भविष्यातील वर्गांच्या गटासाठी अपूर्ण 'रिक्त'. रिकामा आहे तसा वापरला जाऊ शकत नाही. तो खूप 'कच्चा' आहे. परंतु हे अमूर्त वर्गाचा वारसा घेणार्‍या भविष्यातील वर्गांच्या ताब्यातील विशिष्ट स्थिती आणि सामान्य वर्तनाचे वर्णन करते.

अमूर्त Java वर्गांची उदाहरणे

कारसह एक साधे उदाहरण विचारात घ्या:

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!");
   }

}

हे आपण वारसाविषयक धड्यांमध्ये बोललो त्यासारखेच आहे. पण त्या धड्यांमध्ये, आमच्याकडे कार वर्ग होता आणि त्याच्या पद्धती अमूर्त नव्हत्या. परंतु त्या सोल्यूशनमध्ये अनेक कमतरता आहेत ज्या अमूर्त वर्गांमध्ये निश्चित केल्या आहेत. प्रथम आणि सर्वात महत्त्वाचे म्हणजे, तुम्ही अमूर्त वर्गाचे उदाहरण तयार करू शकत नाही :

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वर्ग ( अमूर्त प्राणी ). तो कोणत्या प्रकारचा प्राणी आहे, तो कोणत्या कुटुंबाचा आहे आणि त्याची कोणती वैशिष्ट्ये आहेत हे स्पष्ट नाही. आपल्या कार्यक्रमात ते पाहणे विचित्र होईल. निसर्गात 'अमूर्त प्राणी' नाहीत. केवळ कुत्रे, मांजर, कोल्हे, मोल इ. अमूर्त वर्ग आपल्याला अमूर्त वस्तूंपासून वाचवतात. ते आपल्याला मूलभूत स्थिती आणि वागणूक देतात. उदाहरणार्थ, सर्व कारचे मॉडेल , रंग आणि कमाल गती असावी आणि तुम्ही ते लागू करण्यास सक्षम असाल.गॅस आणि ब्रेक . बस एवढेच. ही एक सामान्य गोषवारा योजना आहे. पुढे तुम्ही तुम्हाला आवश्यक असलेले वर्ग डिझाइन करा. टीप: अमूर्त वर्गातील दोन पद्धती देखील abstract म्हणून नियुक्त केल्या आहेत आणि त्यांची कोणतीही अंमलबजावणी नाही. कारण एकच आहे: अमूर्त वर्ग अमूर्त कारसाठी डीफॉल्ट वर्तन तयार करत नाहीत. प्रत्येक कारला काय करता आले पाहिजे हे ते फक्त सूचित करतात. तथापि, जर तुम्हाला डीफॉल्ट वर्तनाची आवश्यकता असेल, तर तुम्ही अमूर्त वर्गात पद्धती लागू करू शकता. Java हे प्रतिबंधित करत नाही:

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ओव्हररॉड केली आहे. ही खूप सोयीस्कर आणि लवचिक आहे. पण आता आमचा वर्ग इतका अमूर्त नाही ? शेवटी, त्यातील अर्ध्या पद्धती लागू केल्या आहेत. खरं तर हे एक अतिशय महत्त्वाचे वैशिष्ट्य आहे - जर वर्ग त्याच्या पद्धतींपैकी किमान एक अमूर्त असेल तर तो अमूर्त असतो. दोन पद्धतींपैकी एक किंवा हजार पद्धतींपैकी किमान एक - याने काही फरक पडत नाही. आम्ही सर्व पद्धती अंमलात आणू शकतो आणि त्यापैकी एकही अमूर्त सोडू शकत नाही. मग तो अमूर्त पद्धतींशिवाय एक अमूर्त वर्ग असेल. तत्वतः, हे शक्य आहे, आणि कंपाइलर त्रुटी निर्माण करणार नाही, परंतु ते टाळणे चांगले आहे: अमूर्त शब्दाचा अर्थ गमावला आहे, आणि तुमचे सहकारी प्रोग्रामर खूप आश्चर्यचकित होतील :/ त्याच वेळी, जर एखादी पद्धत चिन्हांकित केली असेल तर अमूर्त शब्दासह, प्रत्येक बाल वर्गाने ते लागू केले पाहिजे किंवा ते अमूर्त म्हणून घोषित केले पाहिजे. अन्यथा, कंपाइलर त्रुटी निर्माण करेल. अर्थात, प्रत्येक वर्गाला फक्त एक अमूर्त वर्ग वारसा मिळू शकतो, म्हणून वारशाच्या बाबतीत अमूर्त आणि सामान्य वर्गांमध्ये फरक नाही. आपल्याला एखादा अमूर्त वर्ग किंवा सामान्य वर्ग वारसा मिळाला तरी काही फरक पडत नाही, फक्त एक पालक वर्ग असू शकतो.

Java मध्ये अनेक वर्गांचा वारसा का नाही

आम्ही आधीच सांगितले आहे की Java मध्ये एकाधिक वारसा नाही, परंतु आम्ही खरोखर का शोधले नाही. आता ते करण्याचा प्रयत्न करूया. वस्तुस्थिती अशी आहे की जर Java कडे एकापेक्षा जास्त वारसा असेल, तर बाल वर्ग त्यांना कोणते विशिष्ट वर्तन निवडायचे हे ठरवू शकणार नाहीत. समजा आपल्याकडे दोन वर्ग आहेत — 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. ऑब्जेक्ट कधीही कळू शकत नाही. आणि हे सर्व बंद करण्यासाठी: NuclearBomb कडे पद्धत नाही off(), म्हणून आम्ही योग्य अंदाज लावला नाही तर, डिव्हाइस अक्षम करणे अशक्य होईल. तंतोतंत या 'गोंधळ'मुळे, जिथे ऑब्जेक्टला कोणते वर्तन प्रदर्शित करावे हे माहित नसते, जावाच्या निर्मात्यांनी एकाधिक वारसा सोडला. तथापि, तुम्हाला आठवत असेल की Java क्लासेस अनेक इंटरफेस लागू करू शकतात. तसे, तुमच्या अभ्यासात, तुम्हाला आधीच किमान एक अमूर्त वर्ग आला आहे!

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

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