znáte z PPA1 (kapitola 7.2 "Třída jako datový typ" v materiálech na PPA1)

třída realizuje zapouzdření (v terminologii OOP), to znamená, že

příklad napoví

příslušný kód je uložen v souborech Person.java a Customer.java, všiměte se části "Customer extends Person"

dědičnost má řadu výhod

u dědičnosti je běžné, že při návrhu software vznikne netriviální hierarchie objektů (odpusťte autorovi obrázku, že zapoměl nakreslit šipky -- všechny by směřovaly vzhůru)

základem polymorfismu je virtuální metoda

překrývání metod -- overriding

uvažujme třídu odeděděnou od Customer

public class NobleCustomer extends Customer {
  String title; // sir, baron, knight, lord, duke, princ, king
  public String toString() { 
    return " Account number: " + accountNumber + 
           "\n Honorable account holder: " + title + " " + name + 
           "\n Address: " + address + "\n"; 
  } 
}

podívejme se teď na to jaké metody jsou kdy volány

public class Test { 
  public static void main(String args[]) { 
    Customer c; 
    NobleCustomer nc; 
    c = new Customer(); 
    c.name = "Ondrej Rohlik"; 
    c.address = "Pilsen"; 
    c.accountNumber = 420820;

    System.out.println(c.toString()); 
    // Vypíše očekavané: 
    // Account number: 420820 
    // Account holder: Ondrej Rohlik 
    // Address: Pilsen
    nc = new NobleCustomer(); 
    nc.name = "Albert II"; 
    nc.address = "Monaco"; 
    nc.accountNumber = 111777; 
    nc.title = "prince";
    
    System.out.println(nc.toString()); 
    // Vypíše očekavané: 
    // Account number: 111777 
    // Honorable account holder: prince Albert II 
    // Address: Monaco 

    c = nc; // to je BTW pěkný trik: podtřídu lze "uložit" do proměnné typované jako nadtřída 

    System.out.println(c.toString());
    // Díky polymorfismu vypíše:
    // Account number: 111777
    // Honorable account holder: prince Albert II 
    // Address: Monaco 
}

toString() je virtuální metoda (ono vlastně všechny metody v Javě jsou virtuální -- narozdíl od některých jiných jazyků jako např. C++, kde je třeba explicitně uvést které metoda je virtuální a které je obyčejná/nevirtuální)

selský rozum říká, že když voláme c.toString() a c je typu Customer, výpis by měl být

Account number: 420820 
Account holder: Ondrej Rohlik 
Address: Pilsen 

trik je právě v polymorfismu volání virtualních metod; JVM si "všimne", že objekt na který referenční proměnná c ukazuje je typu NobleCustomer a tedy zavolá příslušnou metodu toString(), tak jak je definovaná v NobleCustomer nikoliv tu, která je definovaná v Customer

tato vlastnost se jmenuje polymorfismus

pozn.: samozřejmě že kdyby žádná toString() v NobleCustomer definovaná nebyla, JVM zavolá metodu toString() definovanou v Customer

příklad z praxe: třída JMenuItem definuje metodu updateUI(); její podtřída JCheckBoxMenuItem má jinou implementaci metody updateUI()

někdy je výhodné deklarovat ve třídě virtuální metodu, ale nechat jí nedefinovanou tj. nenapsat jí kód těla

Třída GrObj2D má abstraktní metodu a proto musí být také definovaná jako abstraktní

public abstract class GrObj2D { 
  int x;
  int y;
  public abstract int getArea();
}

Třída Circle metodu implementuje

public class Circle extends GrObj2D { 
  int radius;
  public int getArea() { 
    return Math.round(radius*radius*3.14f); 
  } 
}

Třída Rectangle také

public class Rectangle extends GrObj2D { 
  int width; 
  int height; 
  public int getArea() { 
    return width*height; 
  } 
}            

Instanciace a demostrace použití abstraktní metody

public class Test { 
  public static void main(String args[]) { 
    GrObj2D[] list = new GrObj2D[2]; 
    Circle    c = new Circle(); 
    Rectangle r = new Rectangle(); 
    c.radius = 10; 
    r.width  = 10; 
    r.height = 20; 
    list[0] = c; // list[0] je typovaný na GrObj2D, takže do něj můžeme vložit Circle
    list[1] = r; // i do list[1] lze vložit libovolného potomka
    for (int i=0; i<2; i++) { 
      System.out.println("Area: " + list[i].getArea()); 
    } 
  } 
}

Vytiskne:

Area: 314 
Area: 200

Takže jaká je situace?

Třídě, které má nějakou (jednu nebo více) abstraktní metodu se říká abstraktní třída

v dalším textu budu z pedagogických důvodů používat termín interface, i když i český překlad rozhraní je zcela běžně používaný (i když méně často než interface)

interface je "něco jako třída, jejíž všechny operace jsou abstraktní" tj. "něco jako abstraktní třída, jejíž všechny operace jsou abstraktní"

ukažme si použití interface na příkladě bankovní aplikace která modeluje

a mějme následující problém

nejprve si ukážeme, špatné řešení -- tzv. object-based programování (bez použití interface):

při naivním řešení problému se aplikace poskládá jako množina interagujících objektů

část třídy Customer může vypadat třeba takto:

a Archiver takto:

metoda doArchive() uloží stav aplikace (tj. stav všech objektů v aplikaci); zpracovává tři typy objektů: Customer, Branch a Account

Customer[] customerList; 
Branch[]   branchList;
Account[]  accountList; 
void doArchive() { 
  // zpracuj data klientu 
  for (all items c in customerList) { 
    name = c.getName();
    address = c.getAddress(); 
    account = c.getAccount(); 
    . . . // zapis jmeno, adresu a ucet do archivniho souboru 
  } 
  // zpracuj data pobocek 
  for (all items b in branchList) { 
  . . . 
  // zpracuj data uctu 
  for (all items a in accountList) { 
  . . . 
}
              

instanciace aplikace pak může vypadat nějak takto

Archiver archiver = new Archiver(); // vytvor archivare 

Customer c1 = new Customer(); // vytvor objekty (instance) klientu 
Customer c2 = new Customer();
. . . 
Customer cn = new Customer(); 

Branch b1 . . . // vytvor objekty (instance) pobocek 

Account a1 . . . // vytvor objekty (instance) uctu

archiver.addCustomer(c1); 
archiver.addCustomer(c2); 
. . . // nahraj objekty (instance) klientu jeden po druhem do archivare
archiver.addBranch(b1); 
. . . // nahraj objekty (instance) pobocek jeden po druhem do archivare
archiver.addAccount(a1); 
. . . // nahraj objekty (instance) uctu jeden po druhem do archivare

archiver.doArchive(); // trigger archive 

toto řešení má řadu nevýhod

Lepší řešení našeho bankovního problému je následující

definujeme interface, které zapouzdří operace archivovatelných objektů které Archiver potřebuje volat

tím oddělíme Archiver a archivovatelné třídy, takže už na sobě nebudou závislé -- změna jedné třídy tak nevynutí změnu třídy Archiver (a to je pro softwarevé inženýry velmi cenná vlastnost)

toto oddělění (anglicky decoupling) se realizuje prostrřednictvím interface Archivable, které budou Customer, Branch a Account implementovat ("jakoby dědit" .. je to stejné jako dědičnost, ale v případě interface se neříká "dědit" ale "implementovat")

kód Archivable je:

Interface Archivable {
  public String getArchiveImage();
}

kód Archiveru pak vypadá takto (je teď mnohem elegantnejší):

Class Archiver { 
  Archivable[] list; // mame jen 1 seznam (už ne 3) 
  void doArchive() { // zpracuj archivable objekty 
    for (all items a in list) { 
      string = a.getArchiveImage(); // a je typu Archivable 
      soubor.println(string) // zapis do souboru retezce vraceneho metodou getArchiveImage()  
    } 
  } 
  void addArchivable(Archivable newItem) { 
    list.add(newItem); 
  } 
} 

A instanciační kód je:

Archiver archiver = new Archiver(); // create archiver 

Archivable c1 = new Customer(); // create customer objects 
. . . 
Archivable cn = new Customer(); 

Archivable b1 . . . // create branch objects 

Archivable a1 . . . // create account objects 

archiver.addArchivable(c1); . . . // load customer objects 
archiver.addArchivable(cn); . . . // load customer objects 
archiver.addArchivable(b1); . . . // load branch objects 
archiver.addArchivable(a1); . . . // load account objects 

archiver.doArchive(); // trigger archiver

Archivable je opravdu a doslova definice "rozhraní", která se třídy Customer, Branch a Account zavazují splnit (chcete-li poskytovat). Archiver se tak může spolehnout, že když zavolá metody getArchiveImage() dostane relevantní data (tedy nejaky smysluplny String).

Říkáme, že rozhraní Archivable je (tj. funguje jako) smlouva (contract) mezi Archiver a třídami Customer, Branch a Account (odtud slavné "design by contract").

Všiměte se, jak se nám aplikace zlepšila z hlediska její údržby. Když nyní (po letech bezproblémového provozu) potřebujeme vyměnit část aplikace Customer za novější a lepší verzi (řekněmě NobleCustomer), nemusíme nijak editovat, překládat a testovat třídu Archiver. To je velká úspora času programátorů.

Příklad z praxe: interface Observable (http://java.sun.com/j2se/1.4.2/docs/api/java/util/Observable.html) je pro vývoj grafického uživatelského rozhraní naprosto nepostradatelná; probereme jej na třetí přednášce.

http://java.sun.com/docs/books/tutorial/java/concepts/object.html

http://java.sun.com/docs/books/tutorial/java/concepts/class.html

http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

http://java.sun.com/docs/books/tutorial/java/IandI/subclasses.html

http://java.sun.com/docs/books/tutorial/java/IandI/createinterface.html