JavaRush /Java Blog /Random-TL /Mga abstract na klase sa Java na may mga partikular na ha...

Mga abstract na klase sa Java na may mga partikular na halimbawa

Nai-publish sa grupo
Kamusta! Sa nakaraang mga lektura, nakilala namin ang mga interface at naisip kung ano ang kailangan nila. Ang paksa ngayon ay magkakaroon ng pagkakatulad sa nauna. Pag-usapan natin ang mga abstract na klase sa Java. Mga abstract na klase sa Java na may mga konkretong halimbawa - 1

Bakit tinatawag na "abstract" ang mga klase

Marahil ay naaalala mo kung ano ang "abstraction" - nasaklaw na namin ito :) Kung bigla mong nakalimutan, okay lang, tandaan natin: ito ang prinsipyo ng OOP , ayon sa kung saan kapag nagdidisenyo ng mga klase at paglikha ng mga bagay, kinakailangan na i-highlight tanging ang mga pangunahing katangian ng isang entity at itapon ang mga pangalawa. Halimbawa, kung kami ay nagdidisenyo ng isang klase SchoolTeacher- isang guro sa paaralan - malamang na hindi namin kailangan ang katangiang " taas ". Sa katunayan: para sa isang guro ang katangiang ito ay hindi mahalaga. Ngunit kung lumikha tayo ng isang klase sa programa BasketballPlayer- isang basketball player - ang taas ay magiging isa sa mga pangunahing katangian. Kaya, ang abstract na klase ay ang pinaka-abstract, oh-so-approximate "blangko" para sa isang pangkat ng mga klase sa hinaharap. Ang paghahanda na ito ay hindi maaaring gamitin sa tapos na anyo nito - ito ay masyadong "hilaw". Ngunit inilalarawan nito ang isang tiyak na pangkalahatang estado at pag-uugali na magkakaroon ng mga klase sa hinaharap - mga tagapagmana ng abstract na klase -.

Mga Halimbawa ng Abstract na Klase ng Java

Tingnan natin ang isang simpleng halimbawa sa mga kotse:
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;
   }
}
Ito ang hitsura ng pinakasimpleng abstract na klase. Tulad ng nakikita mo, walang espesyal :) Ano ang maaaring kailanganin natin ito? Una sa lahat, inilalarawan niya ang entity na kailangan natin sa pinaka-abstract na paraan na posible - isang kotse. Ang salitang abstract ay narito para sa isang dahilan. Walang "mga makina lang" sa mundo. May mga trak, karera ng kotse, sedan, coupe, SUV. Ang aming abstract na klase ay isang "blueprint" lamang kung saan gagawa kami ng mga klase ng kotse.
public class Sedan extends Car {

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

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

}
Ito ay katulad ng napag-usapan natin sa mga lecture tungkol sa mana. Doon lang kami nagkaroon ng klase Carat ang mga pamamaraan nito na hindi abstract. Ngunit ang solusyon na ito ay may isang bilang ng mga disadvantages, na naitama sa mga abstract na klase. Una at pangunahin, ang isang instance ng abstract class ay hindi maaaring gawin:
public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Error! The Car class is abstract!
   }
}
Ang "panlinlang" na ito ay partikular na ipinatupad ng mga tagalikha ng Java. Muli, tandaan lamang: ang abstract na klase ay isang blueprint lamang para sa hinaharap na "normal" na mga klase . Hindi mo kailangan ng mga kopya ng drawing, tama ba? Kaya hindi na kailangang lumikha ng mga pagkakataon ng isang abstract na klase :) At kung ang klase Caray hindi abstract, madali naming magagawa ang mga bagay nito:
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 OK, the machine has been created
   }
}
Ngayon ay mayroon kaming kakaibang kotse sa aming programa - hindi isang trak, hindi isang karera ng kotse, hindi isang sedan, ngunit isang bagay sa pangkalahatan. Ang parehong "isang makina lamang" na hindi umiiral sa kalikasan. Ang parehong halimbawa ay maaaring ibigay sa mga hayop. Isipin kung may mga bagay na lumitaw sa iyong programa Animal- " hayop lang ". Anong uri ito, kung anong pamilya ito kabilang, kung anong mga katangian mayroon ito - hindi ito malinaw. Kakaiba na makita siya sa programa. Walang "mga hayop lamang" sa kalikasan. Tanging mga aso, pusa, fox, nunal at iba pa. Ang mga abstract na klase ay nagpapalaya sa amin mula sa " mga bagay lamang ". Binibigyan nila tayo ng pangunahing estado at pag-uugali. Halimbawa, ang lahat ng kotse ay dapat may modelo , kulay at pinakamataas na bilis , at dapat din silang makapag- gas at magpreno . Iyon lang. Ito ay isang pangkalahatang abstract scheme, pagkatapos ikaw mismo ang nagdidisenyo ng mga klase na kailangan mo. Pakitandaan: dalawang pamamaraan sa isang abstract na klase ay itinalaga rin bilang abstract , at hindi ito ipinatupad. Ang dahilan ay pareho: ang mga abstract na klase ay hindi gumagawa ng "default na pag-uugali" para sa "mga makina lamang". Sinasabi lang nila na dapat nilang gawin ang lahat ng mga kotse. Gayunpaman, kung kailangan mo pa rin ang default na pag-uugali, maaari mong ipatupad ang mga pamamaraan sa isang abstract na klase. Hindi ito ipinagbabawal ng Java:
public abstract class Car {

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

   public void gas() {
       System.out.println("Let's go!");
   }

   public abstract void brake();

   //getters and setters
}


public class Sedan extends Car {

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

}

public class Main {

   public static void main(String[] args) {

       Sedan sedan = new Sedan();
       sedan.gas();
   }
}
Output ng console: "Magpabilis!" Tulad ng nakikita mo, ipinatupad namin ang isang pamamaraan sa abstract na klase, ngunit hindi ipinatupad ang pangalawa. Bilang resulta, ang pag-uugali ng aming klase Sedanay nahahati sa dalawang bahagi: kung tatawagin mo ang isang pamamaraan dito gas(), ito ay "pull up" mula sa parent abstract class Car, at brake()muling tinukoy namin ang paraan sa klase Sedan. Ito ay naging napaka-maginhawa at nababaluktot. Pero ngayon hindi na abstract ang klase namin ? Pagkatapos ng lahat, sa katunayan, kalahati ng kanyang mga pamamaraan ay ipinatupad. Sa katunayan - at ito ay isang napakahalagang tampok - ang isang klase ay abstract kung kahit isa sa mga pamamaraan nito ay abstract . Hindi bababa sa isa sa dalawa, hindi bababa sa isa sa isang libong pamamaraan - hindi mahalaga. Maaari din nating ipatupad ang lahat ng mga pamamaraan at hindi mag-iwan ng anumang abstract. Magkakaroon ng abstract na klase na walang abstract na pamamaraan. Sa prinsipyo, posible ito, at ang tagatala ay hindi makagawa ng mga pagkakamali, ngunit mas mahusay na huwag gawin ito: ang salitang abstract ay mawawala ang kahulugan nito, at ang iyong mga kapwa programmer ay magugulat na makita ito :/ Bukod dito, kung ang isang pamamaraan ay minarkahan ng salitang abstract, dapat ipatupad o ideklarang abstract ang bawat descendant class. Kung hindi man ang tagatala ay magtapon ng isang error . Siyempre, ang bawat klase ay maaaring magmana mula sa isang abstract na klase lamang, kaya sa mga tuntunin ng pamana ay walang pagkakaiba sa pagitan ng abstract at regular na mga klase. Hindi mahalaga kung nagmana tayo mula sa abstract na klase o mula sa isang regular, maaari lamang magkaroon ng isang parent class.

Bakit walang multiple class inheritance sa Java?

Nasabi na namin na walang multiple inheritance sa Java, pero hindi namin talaga naisip kung bakit. Subukan natin ito ngayon. Ang punto ay kung ang Java ay may maraming mana, ang mga klase ng bata ay hindi makakapagpasya kung aling pag-uugali ang pipiliin. Sabihin nating mayroon tayong dalawang klase - Tosterat NuclearBomb:
public class Toster {


 public void on() {

       System.out.println("The toaster is on, the toast is getting ready!");
   }

   public void off() {

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


public class NuclearBomb {

   public void on() {

       System.out.println("Взрыв!");
   }
}
Tulad ng nakikita mo, parehong may pamamaraan on(). Sa kaso ng toaster, nagsisimula itong magluto ng toast, at sa kaso ng nuclear bomb, nagdudulot ito ng pagsabog. Oh :/ Ngayon isipin na nagpasya kang (hindi ko alam kung bakit biglang!) na lumikha ng isang bagay sa pagitan. At narito ang iyong klase - MysteriousDevice! Ang code na ito, siyempre, ay hindi gumagana, at ipinakita namin ito bilang isang halimbawa ng "kung paano ito maaaring maging":
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 a toast, or a nuclear apocalypse?
   }
}
Tingnan natin kung ano ang nakuha natin. Ang mahiwagang aparato ay nagmula sa parehong Toaster at Nuclear Bomb. Parehong may pamamaraan on(), at bilang resulta, hindi malinaw kung aling paraan on()ang dapat magpaputok sa bagay MysteriousDevicekung tawagin natin ito. Hindi ito mauunawaan ng bagay. Well, bilang isang cherry sa cake: ang Nuclear Bomb ay walang paraan off(), kaya kung mali ang hula namin, walang paraan upang i-off ang device. Mga abstract na klase sa Java na may mga konkretong halimbawa - 2 Ito ay tiyak na dahil sa pagkalito na ito, kapag ang isang bagay ay hindi malinaw kung aling pag-uugali ang dapat nitong piliin, na ang mga tagalikha ng Java ay inabandona ang maramihang pamana. Gayunpaman, naaalala mo na ang mga klase ng Java ay nagpapatupad ng maraming mga interface. Siyanga pala, nakatagpo ka na ng kahit isang abstract na klase sa iyong pag-aaral! Kahit na, siguro hindi ko napansin :)
public abstract class Calendar implements Serializable, Cloneable, Comparable<Calendar>
Ito ang dati mong klase ng kaibigan Calendar. Ito ay abstract at may ilang tagapagmana. Ang isa sa kanila ay GregorianCalendar. Nagamit mo na ito sa mga aralin tungkol sa mga petsa :) Mukhang malinaw na ang lahat, isang punto na lang ang natitira: ano ang pangunahing pagkakaiba sa pagitan ng mga abstract na klase at mga interface ? Bakit nila idinagdag pareho sa Java, at hindi nililimitahan ang kanilang sarili sa isa lang? Ito ay maaaring sapat na. Pag-uusapan natin ito sa susunod na lecture! Magkita tayo :)
Mga komento
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION