OOP - dedicnost, abstrakce, rozhrani

Takže je samozřejmé, že každá věc se dá udělat více způsoby. Nicméně k tvému příkladu. Pokud se jedná skutečně jenom o to jak to máš tak je celkem jedno jestli použiješ jedničku nebo dvojku, ale obecně je potřeba se zamyslet o co nám v programu půjde. Budu-li chtít pracovat pouze s vedoucím a ředitelem, kteří mají něco společného a nebudu v programu potřebovat žádného zaměstnance, tak je vhodné využít první případ. Nicméně většinou je nutné využívat jednak zaměstnance jednak vedoucího a navíc ředitele, kteří mají jiné vlastnosti, takže zaměstnanec obsahuje něco co není potřeba u ředitelel a podobně ostatní. V tu chvíli je vhodné využít abstrakci.
Rozhraní bych do toho vůbec netahal, jednak sem ten tvůj přiklad s IPlatem a Idovolenou moc nepochopil a jednak si myslím, že interface nemá příliš velký význam v PHP. V Javě nebo v jiných jazycích je interface nutnou součástí, ale do PHP bych to moc netahal.
OOP chce hlavně tréning, až napíšeš 27 programů, tak už ti to vleze do krve a půjde ti to samo.

$Fred
Pokud by kazda trida mela defakto jine metody tak by snad abstraktni trida nebyla k nicemu ne? Mel sem vzato ze v abstraktni tride, se nadefinuji abstraktni metody, ktere se potom v odvozenych tridach prekryji jinym obsahem, ale budou mit vsechny metody z abstraktni tridy.
Jasně, tak sem to myslel, špatně jsem se vyjádřil, budou mít něco společného, ale každý něco navíc, pak je vhodná abstraktní třída, kde bude stovka abstraktních metod + další stovka dalších metod.
Musíš vždycky přemýšlet a vymýšlet co je specializací čeho, já bych si myslel, že ve firmě budou jednak normální zaměstnanci a k tomu ještě šéf, každý má svoje vlastnosti, ale dost toho mají společného. Pak to společné nadefinuju v nějaké nadtřídě. Pokud by však šéf byl specializací zaměstnance, pak vytvořím třídu zaměstnanec a z ní vydědím třídu boss.

$Fred
Prijde mi to defakto to same. Da se to s mensimi oklikami udelat jednim a tim zpusobem. Asi jsem to uplne nepochopil.
Tyto příklady mi přijdou natolik vyumělkované, že nejsou v praxi použitelné.

Muze mi nekdo rict kdy co mam pouzivat?
Opravdu záleží na situaci, na tom, čeho chceš docílit. A obecně se všechono kombinuje dohromady.

Bohužel se v těchto knížkách uvádí jako hlavní princip OOP zapouzdření (encapsulation) a dědičnost (inheritance). To se mi však zdá mylné. Se zapouzdřeností bych souhlasil, ale s dědičností ne. Podle mě je největší výhodou OOP možnost skládání (composition) a s ním spojená heslo "composition over inheritance" (něco jako skládání je více než dědičnost). Uvedu příklad s těmi zaměstnanci. Máš třídu Zamestnanec, jejíž každá instance reprezentuje jednoho zaměstnance. A teď potřebuješ ředitele. Je to taky samozřejmě zaměstnanec. Takže je logické, že by třída Reditel byla následníkem třídy Zamestnanec. Přidal bys jí fce jako snizitPlat(Zamestnanec $z), vyhodit(Zamestnanec $z)... No jo, ale teď bys měl místoředitele. Jejich náměstky. Atd. A představ si, že každou takovou funkci bys dědil ze Zamestnance a přidal ji každé nějakou fci (které by se navíc opakovali). Naprostý bordel. Navíc, představ si, že máš pole zaměstnanců, kteří jsou v práci, a potřebuješ někoho vyhodit. Nejdřív si potřebuješ zjistit, jaké všechny pozice ve firmě mohou někoho vyhodit (což nepůjde zrovna automaticky, protože např. v jedné zděděné třídě můžeš mít metodu pro vyhození definovanou pod jiným jménem než v druhé). Pak projíždíš celé pole a zjišťuješ, je-li některá z instancí instancí dané třídy mající oprávnění k vyhodění a definouvanou metdo vyhodit(...). Taky docela zmatek.

Teď bys ale měl třídy jako Pozice a Akce. Byly by abstraktní. Z nich by dědily Reditel, MistoReditel, RadovyZamestnanec atp. a SnizeniPlatu, Vyhazov atp. Zamestnanec bude místo dědění mít metodu urciPozici(Pozice $p) a vykonejAkci(Akce $a). Když zavoláš na instanci třídy Zamestnanec metodu vykonejAkci(Akce $a), tak se zeptá instance Pozice metodou mamOpravneniKAkci(Akce $a). A ta rozhodne, má-li oprávnění k vykonání akce. Má-li, instance Zamestnance zavolá na instanci Akce metodu udelejTo(), která vykoná požadovaný úkon (navíc může předat jako parametr sebe, což se může uložit do např. logu). Takže když chceš někoho vyhodit, akorát stačí projít pole s instancemi Zamestnance a vyvolávat na každém prvku metodu vykonejAkci(Vyhazov($z)) (kde $z je instance zaměstnance k vyhození), která při malých oprávněních vyvolá výjimku NemamDostatecnaOpravneni.

Skládání je tedy mnohem jednodušší, nemusíš si pamatovat, co kdo může udělat a lze velice jednoduše přidávat pozice i akce.

bukaj
Naprosto souhlasím. Dědičnost se často používá (zejména začátečníky) tam, kde buď nepatří nebo její použití je sporné až nepoužitelné a to často na základě toho, že na příkladu z normálního života (učebnicové příklady) nám to přijde logické.