A pritom je OOP tak strasne jednoduchy koncept.
Staci znat par pravidel a selsky rozum, objektovy je cely svet vukol.
A to je právě ta největší zrada - ono se to
tváří, že je to strašně jednoduché, protože objektový je celý svět vůkol. Jenže je objektový jinak, než jak je to potřeba k vytvoření
objektového modelu programu. Právě ta podvědomá snaha o 1:1 korespondenci reálných objektů a objektů programových je velice zákeřná past, do níž se chytí většina lidí. Reálný svět má mnohem komplikovanější vazby než IS a HAS a vzájemnou výměnu zpráv mezi blackboxy. Jedna a tatáž věc se dá klasifikovat z různých úhlů pohledu, podle různých kritérií. Například obyčejné
číslo - přirozené, racionální, reálné, sudé/liché, transcendentní... Ale v počítači mě spíš zajímá, kolik místa potřebuji na jeho uložení a jak s ním budu algoritmicky zacházet, což je klasifikace, která zrovna moc neodpovídá "světu vůkol", ale odpovídá světu uvnitř počítače.
Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.
V reálném světě je to nesmysl, ale v počítači je to rovnocenné a zvolit se musí varianta, která je přímočařejší z hlediska návrhu programu -
pen.draw(canvas) vs.
canvas.draw(pen) vs.
canvas.pen(draw) vs. ... Zákon schválnosti říká, že si člověk vybere nevhodnou variantu, což se projeví v okamžiku, kdy bude chtít rozšířit svůj model o nějakou prkotinu, která mu do toho vůbec, ale vůbec nebude zapadat, ale kdyby býval zvolil jiný model na začátku, krásně by to do sebe zapadlo. A blbé je, že v tom smolném případě OOP poslouží úplně stejně jako v tom šťastném - jako zesilovač: když to na začátku vymyslíte dobře, OOP vám ušetří spoustu práce; a naopak, bohužel.
Pak je potreba v ramci mozkoveho mysleni este urcit, ze v danem kontextu objet User zrejme nebude clovek, alebrz vstupni karticka, co se strka do pichacky a kterou se oteviraji dvere, ze je treba lepsi ten objekt pojmenovat AuthToken a tedy ze neni potreba do toho nasrat i cislo bot realneho Usera, to se klido strci do jineho objektu, co upravdu reprezentuje cloveka.
A nebo je třeba posoudit, zda ta kartička je zásadním objektem, nebo je to jen nějaký prostředek k autorizaci, či dokonce jeden z mnoha možných, pro daný program ne zcela podstatný, protože až někdo přijde s autorizací přes sítnici, začne se řešit, jak to napasovat na objekt kartička. Tedy zda jde o nějaký vrátný systém, pro nějž je badge/token to podstatné, a koho/co reprezentuje už není jeho starost, nebo naopak jde o nějaký systém zaměstnanců, kde zas není až tak podstatné jak se autorizoval, ale kdo se autorizoval.
A ano, knizky o OOP jsou vetsinou blbe, tam prave dedi trojuhelniky a ctverce z obecneho polygonu, aby ve zdedenem objektu vymenili sakuprask vsecko, tady je lepsi prosty interface.
Tohle bych nazval prvoplánové návrhové chyby. Který učební text je má, takový můžete rovnou zahodit. Jenže pak tu jsou ty "vyšší" chyby, které se dají jen těžko demonstrovat na malých příkladech, protože se začnou projevovat až později. Tím jsem nechtěl říci, že ty vaše příklady jsou špatně nebo dobře. Problém je, že bez znalosti kontextu se to nedá jednoznačně rozhodnout.
Marketingová hesla OOP byla
přehlednost, znovupoužitelnost, úspora psaní. Realita, na niž jsem celý život narážel, byla přesně opačná.
Poslední příspěvky