98
Kapitola 6 Základy objektové architektury
6.8 Druhy vytvářených objektů Při rozhodování o tom, jaký druh objektu pro daný účel vytvořit, je zřejmé, že pro objekty, jichž bude více, bychom měli definovat třídu. U objektů, které se budou v celé aplikaci vyskytovat jenom v jednom exempláři, je rozhodování těžší. Obecně máme v Pythonu tři možnosti:
● Definovat objekt jako modul. Tato možnost bude asi nejjednodušší, ale na druhou stranu není vhodné mít celou aplikaci rozbitou do záplavy drobných modulů. Má proto smysl popřemýšlet, jestli by v zájmu maximální přehlednosti aplikace nebylo výhodnější sloučit několik definic „sólistů“ do jednoho modulu.
● Definovat třídu, která nebude mít žádnou instanci a bude sama oním objektem.
Tato možnost by se mohla hodit ve chvíli, kdy bychom měli takovýchto „sólistů“ více a definice každého z nich by byla relativně jednoduchá, takže by se mohlo ukázat výhodné sloučit všechny do jednoho modulu.
● Definovat pro daný objekt třídu, která bude mít jedinou instanci – daný objekt. Po této možnosti sáhneme ve chvíli, kdy bychom tuto třídu mohli začlenit do dědické hierarchie a díky tomu zdědit implementaci některých funkcionalit. Tuto možnost zde nebudu rozebírat, ale v [11] je uvedeno několik možných způsobů realizace takovéto třídy.
6.9 Dva způsoby návrhu Pro řešení složitějších úloh existují obecně dva principiální přístupy: návrh shora dolů a naopak návrh zdola nahoru. V praxi se většinou používá nějaká jejich kombinace, ale zkusím vám je nejprve představit v jejich čisté podobě.
Návrh shora dolů Návrh metodou shora dolů (anglicky top-down design) vychází z přirozeného lidského postupu při řešení složitých problémů, který je označován jako dekompozice problému (problem decomposition) a je vlastně programátorskou aplikací známé římské zásady divide et impera neboli česky rozděl a panuj. I pro nás je velice výhodné rozdělit si složitý problém nejprve na řadu dílčích podproblémů, ty vyřešit a z jejich řešení pak sestavit řešení problému původního. Pokud se nám bude zdát některý z podproblémů stále příliš složitý, není nic přirozenějšího než jej opět rozdělit. Proto bývá tento přístup někdy označován jako postupný návrh (stepwise design). Po několika úrovních postupného zjemňování problému se nakonec musíme dostat do situace, kdy jednotlivé podproblémy budou již natolik jednoduché, že naprogramovat je bude pro nás hračkou, protože stačí vhodně poskládat hotové součásti. O tomto způsobu návrhu můžeme říci, že v každém okamžiku víme, co má prvek dělat, ale zpočátku netušíme, jak to bude dělat, jaká je jeho struktura. To se ujasní až v průběhu další analýzy a následného návrhu a kódování. 65_Python_NZ_ZLOM.doc; verze 1.04.8619_2021-01-16_so_14-41
Strana 98 z 272 Ukázka elektronické knihy, UID: KOS286732
6.9 Dva způsoby návrhu
99
Výhodou návrhu shora dolů je, že se můžeme od počátku tvářit, že je aplikace hotová, i když se budeme muset některým částem vyhýbat, anebo budou místo nich prozatím k dispozici pouze nějaké záslepky. Nevýhodou je naopak to, že máme delší dobu k dispozici pouze nějaký polotovar, v němž nic pořádně nefunguje, takže si při testech musíme dávat velký pozor, abychom nezabloudili do nějaké části, která je závislá na něčem, co ještě není hotové. Ve zbytku učebnice budeme vyvíjet jednoduchou textovou konverzační hru. V takovém případě bychom měli při návrhu shora dolů začít od modulu game a spouštět hned celou hru. Při tom bychom postupně objevovali, kterou část by bylo v danou chvíli optimální navrhnout. Tu část bychom se pokusili navrhnout, přičemž při jejím návrhu bychom postupovali obdobně.
Návrh zdola nahoru Při návrhu metodou zdola nahoru (anglicky bottom-up design) vycházíme z úplně jiné filozofie řešení. Můžeme ji interpretovat tak, že při ní nám naopak připadá, že instrukční soubor použitého procesoru neodpovídá řešené úloze a my se pokoušíme vytvořit nad tímto instrukčním souborem soubor nový: soubor instrukcí, které nám umožní řešit naši úlohu snáze. Při objektovém přístupu bychom začali návrhem objektů, které při své práci vystačí s objekty z dostupných knihoven a frameworků. Když je rozchodíme, začneme navrhovat objekty, které při své práci vystačí s objekty z knihoven a těmi již navrženými. Tak budeme pokračovat, dokud z hotových částí nesestavíme celou aplikaci. Při návrhu textové konverzační hry zmíněné v předchozí pasáži (zájemci najdou stručné zadání v podkapitole 7.2 Zadání na straně 103) bychom nejprve definovali třídu předmětů, s nimiž se ve hře manipuluje. Pak bychom definovali třídy prostorů, v nichž se dané předměty mohou vyskytovat, a třídu batohu, v němž hráč předměty přenáší. Poté bychom asi navrhovali svět tvořený těmito prostory a skončili bychom naprogramováním reakcí na zadávané příkazy. Nevím, jestli je z předchozího textu dostatečně zřejmé, že návrh metodou zdola nahoru vyžaduje dobrou znalost dostupných knihoven a současně předvídavost, jaké požadavky na právě vytvářené objekty (třídy, moduly, …) se v horních patrech návrhu mohou objevit. Osobně se domnívám, že pro začátečníky je vhodný pouze ve chvíli, kdy si pouze hrají a staví různé součásti bez přesného zadání, co má být cílem daného návrhu. Tak trochu podle hesla: „Ono se ukáže, k čemu to může být dobré.“
Porovnání Závěrečné srovnání obou přístupů uvádím v tabulce 6.1, kterou jsem převzal z [7]. Termínem základna je v ní míněn souhrn nástrojů, které má programátor k dispozici, tj. prostředky vlastního jazyka rozšířené o nástroje v dostupných knihovnách. Z tabulky můžete odvodit, kdy kterou z metod zvolit, případně jak je zkombinovat. Výše uvedený příklad se zákazníkem, jemuž nechceme se svým návrhem příliš brzy utéci za jeho mentální obzor, vede zcela zřejmě k přístupu shora dolů. 65_Python_NZ_ZLOM.doc; verze 1.04.8619_2021-01-16_so_14-41
Strana 99 z 272 Ukázka elektronické knihy, UID: KOS286732
100
Kapitola 6 Základy objektové architektury
Naopak při návrhu programů spolupracujících s nějakými zařízeními (např. s chytrou domácností), při němž si musíte nejprve ujasnit, co vše můžete po takovém zařízení chtít a jak toho dosáhnout, je evidentní, že výhodnější bude naopak postup zdola nahoru. My budeme při budování aplikace v následujících kapitolách používat metodu shora dolů a ukážeme si, jak při její aplikaci postupovat. Tabulka 6.1:
Porovnání metody shora dolů a zdola nahoru
Podstatou postupu je Nový prvek je nám Že nový prvek půjde nad danou základnou vytvořit
Shora dolů Analýza Prostředkem Nevíme jistě, spíše předpokládáme
Zdola nahoru Syntéza Cílem
Jaké bude mít nový prvek vlastnosti
Víme přesně
Jak bude nový prvek zkonstruován
Vyřešíme později
Konkrétní použití nového prvku
Známe
Předpokládaná aplikace Návratnost vynaložené námahy
V jednom projektu Brzká, jednorázová Požadujeme něco, co nepůjde naprogramovat nebo nebude efektivní
Přizpůsobíme to možnostem dostupných knihoven Musíme se tím zabývat hned Nezajímá nás (může být libovolné) V mnoha projektech Opožděná, postupná
Hlavní riziko
Víme jistě
Vytvoříme něco, co se nebude dostatečně využívat
6.10 UML diagramy Ve chvíli, kdy máme ujasněné účastníky s jejich schopnostmi a vlastnostmi včetně druhu objektu, který je bude reprezentovat, je vhodné dosavadní znalosti zobrazit ve tvaru, který je pro běžného člověka mnohem přehlednější a snáze zapamatovatelnější než text. Programátoři pro tyto účely používají UML diagramy, z nich pak především diagram tříd. Účastníci zmiňovaní v minulé podkapitole jsou většinou instancemi nějakých tříd, v Pythonu může být takovým účastníkem i modul. V diagramu je každá třída či modul zobrazen(a) obdélníkem, vztahy mezi nimi se zobrazují různými druhy čar a šipek. Stručný popis použitých součástí UML diagramů se objeví v podkapitole 14.1 Pravidla pro kreslení UML diagramů na straně 181 před prvním složitějším UML diagramem. Na podrobnější výklad UML diagramů zde není prostor. Zájemce o hlubší vhled do UML diagramů bych odkázal na vynikající knihu [3], resp. anglický originál [6].
6.11 Shrnutí
V této kapitole se nevyskytovaly žádné doprovodné programy. 65_Python_NZ_ZLOM.doc; verze 1.04.8619_2021-01-16_so_14-41 Ukázka elektronické knihy
Strana 100 z 272