Vlastnosti dědičnosti si ukážeme na následující třídě. Implementujeme si třídu, která bude popisovat majitele mobilního čísla. Nejdříve si zkusíme ukázat, jak by to vypadalo bez dědičnosti, poté ji zapojíme a porovnáme výsledky. Kód nebudeme rozepisovat do detailů, půjde nám pouze o myšlenku.

Co tedy bude hlavním ukolem? Musíme nějak oddělit zákazníky s předplacenou službou od tarifních zákazníků, kteří platí pravidelně za každé zúčtovací období paušální poplatek.

Dva konstruktory

První možností, jak daný úkol řešit, je použití jednoho druhu objektu pro oba typy zákazníků. Tedy budeme mít třídu Zakaznik a vytvoříme konstruktor. Vytvoříme dva konstruktory - jeden pro každý typ zákazníka.

package Zakaznik;
sub new_predplacena_sluzba {
    my($cislo, $id_majitele, $stav_konta, $cena_za_minutu) = @_;
}

sub new_tarifni_program {
    my($cislo, $id_majitele, $stav_konta, $pausal, $volnych_minut,
    $cena_za_minutu_po_vycerpani_volnych_minut) = @_;
}

Poznámka - Teoreticky by v takto zjednodušeném příkladě mohl být zákazník s předplacenou službou speciálním případem tarifního zákazníka s nulovým paušálem a bez volných minut. V tomto a následujících příkladech půjde hlavně o názornost.

Užití dvou konstruktorů samo o sobě není chybou. V našem případě je ale problém v tom, že nezůstane jen u toho. Co když budeme chtít vytvořit funkci, která počítá cenu za daný počet provolaných minut? Buď bychom museli uchovávat další atribut a složitě ošetřovat podmínky nebo bychom mohli napsat dvě zvláštní metody.

sub spocitej_cenu_u_predplacene_sluzby {...}
sub spocitej_cenu_u_tarifniho_programu {...}

Chybou je už to, že uživatel tohoto modulu musí po vytvoření objektu vědět, s jakým typem zákazníka pracuje. Pokud by zavolal funkci spocitej_cenu_u_predplacene_sluzby nad tarifním zákazníkem, došlo by k chybě. Uživatel by to musel pravděpodobně řešit podmínkou a to je znak špatně napsaného modulu.

Dalším problémem je, že funkcí typu spocitej_cenu, které fungují pro každý typ zákazníka na jiném mechanizmu by mohlo být mnohem více. Stejně tak pokud by přibyl další typ zákazníka - například program pro pracovníky mobilního operátora. Pak by nám počet metod vzrůstal lineárně. Takové řešení zdaleka není to pravé.

Dvě nezávislé třídy

Možnost vytvořit místo dosavadního řešení dva nezávislé moduly se zdá být poměrně moudrou myšlenkou. Rozeberme si podrobněji klady a zápory této volby.

package Zakaznik_predplacena_sluzba;
sub new {
    my($cislo, $id_majitele, $stav_konta, $cena_za_minutu) = @_;
}

sub spocitej_cenu {...}


package Zakaznik_tarifni_program;
sub new {
    my($cislo, $id_majitele, $stav_konta, $pausal, $volnych_minut,
    $cena_za_minutu_po_vycerpani_volnych_minut) = @_;
}

sub spocitej_cenu {...}

Rozdíl mezi oběma postupy je okamžitě patrný. Velká výhoda druhého řešení spočívá v tom, že neklade na uživatele modulu nutnost pamatovat si ke každému zákazníkovi i jeho typ a ani nebudeme muset řešit žádné podmínky. Tím odpadá největší problém prvního postupu.

Ovšem přijatelné toto řešení rozhodně není. Odstranění zmíněného problému s sebou přineslo problém jiný. Oba moduly mají společné některé některé atributy ($cislo, $id_majitele, $stav_konta) a metody (například dej_cislo, zmen_majitele, navys_stav_konta apod.). Co když přibude atribut $datum_zalozeni_uctu? Budeme muset upravit oba balíky. A co když nepůjde jen o 2 balíky, ale o 20 nebo více balíků? Jak vidíme, ani rozdělení do nezávislých modulů není elegantním řešením.

Abstraktní třída a dědičnost

Zopakujme si, čeho vlastně chceme docílit. Potřebujeme vytvořit objektově orientovaný modul mobilních zákazníků s těmito vlastnostmi.

• Modul nesmí svému uživateli klást jakékoliv nároky. Pokud nad objektem zavoláme metodu spocitej_cenu, modul ji spočítá bez ohledu na to, jestli uživatel ví, ke kterému balíku objekt patří.
• Atributy a metody, které jsou společné pro všechny typy zákazníků musí být definovány pouze na jediném místě, nehledě na to, o který typ zákazníka jde.

Protože tytéž atributy nesmějí být ve více třídách, budeme problém řešit pomocí abstraktní třídy. Půjde o to vytvořit třídu obecného mobilního zákazníka, který bude obsahovat jen vlastnosti společné všem zákazníkům. Soubor Zakaznik.pm vypadá takto.

package Zakaznik;
sub new {
    my($pkg, $cislo, $id_majitele, $stav_konta) = @_;
    my $o = {};
    bless $o, $pkg;
    $o->{"cislo"} = $cislo;
    $o->{"id_majitele"} = $id_majitele;
    $o->{"stav_konta"} = $stav_konta;
    return $o;
}

sub dej_cislo {...}
sub zmen_majitele {...}
sub navys_stav_konta {...}

Vše, co charakterizuje obecného zákazníka, je definováno zde.

Dále můžeme tvořit už konkrétní typy zákazníků. Nejdříve zákazníka s předplacenou službou (Zakaznik/PredplacenaSluzba.pm). Zde předefinujeme konstruktor tím způsobem, že nejprve vytvoříme objekt obecného zákazníka a poté ho upravíme.

package Zakaznik::PredplacenaSluzba;
use Zakaznik;
use vars qw(@ISA);
@ISA = qw(Zakaznik);

sub new {
    my($pkg, $cislo, $id_majitele, $stav_konta, $cena_za_minutu) = @_;
    my $o = $pkg->SUPER::new($cislo, $id_majitele, $stav_konta);
    $o->{"cena_za_minutu"} = $cena_za_minutu;
    return $o;
}

sub spocitej_cenu {...}

Ukažme si ještě, jak by mohl vypadat zákazník s tarifním programem (Zakaznik/TarifniProgram.pm).

package Zakaznik::TarifniProgram;
use Zakaznik;
@ISA = qw(Zakaznik);

sub new {
    my($pkg, $cislo, $id_majitele, $stav_konta, $pausal,
    $volnych_minut, $cena_za_minutu_po_vycerpani_volnych_minut) = @_;
    my $o = $pkg->SUPER::new($cislo, $id_majitele, $stav_konta);
    $o->{"pausal"} = $pausal;
    $o->{"volnych_minut"} = $volnych_minut;
    $o->{"cena_za_minutu_po_vycerpani_volnych_minut"} =
    $cena_za_minutu_po_vycerpani_volnych_minut;
    return $o;
}

sub spocitej_cenu {...}

Uživatel bude mít nyní k dispozici moduly Zakaznik::PredplacenaSluzba a Zakaznik::TarifniProgram, které lze do programu importovat pomocí use. Takto vypadá použití vytvořeného modulu.

my $zakaznik = Zakaznik::PredplacenaSluzba->new(...);
my $cena = $zakaznik->spocitej_cenu();

Splnili jsme tedy oba požadavky. Náš model je přijatelný z hlediska uživatele - ten s ním může intuitivně pracovat; i z hlediska programátora - neměl být velký problém s rozšiřováním modulu.