Autor Zpráva
Jcas
Profil *
Tak nějak nemohu proniknout do OOP.
Udělal jsem si takovou ukázkovou situaci.
http://zocschmoravskebranice.eu/DB-chovatelu/sklad/ukazka.png
Teoreticky by mohla být jedna metoda "print', druhá "nachystat data" a 3. "print form" (ta by se ještě dál větvila dle prvků formuláře.)
Mám pocit, že OOP je na to ideál, protože tam se tam vyskytují procesy, které by mohly být stejné pro různé instance.
(ps. Trochu mi to tam kazí přidání nového záznamu)

Ale já prostě nevidím rozdíl, když použiji obyč funkce. Případně funkce, která volá jinou funkci.
Jak by jste to řešili?


ps. Argument na údržbu jsem četl mockrát. Opět nevidím rozdíl, jestli udržuji obyč funkci, nebo metodu.
Jan Tvrdík
Profil
To, co navrhuješ, nemá s OOP nic společného, pro to tam taky nevidíš rozdíl oproti obyčejným funkcím. OOP není o tom, že funkce obalíš to třídy. Každá třída by měla mít ideálně jen jednu zodpovědnost a ta by měla být vyjádřena jejím jménem (tzv. Princip jedné odpovědnosti). Pro začátek ti doporučuji přečíst si něco o MVC (Model-View-Controller) architektuře. Mohlo by to vypadat třeba nějak takhle:

Jcas
Profil *
No, tak to nechápu.
MVC - pohybuju se pouze v jedné sekci a to "view".
Princip jedné odpovědnosti mám taky. Jedná se pouze a jenom o to, co zobrazím.
Jan Tvrdík
Profil
Je rozdíl mezi
1) vlastním zobrazováním
2) logikou, která rozhodné, co se má zobrazit na základě příchozího HTTP požadavku
3) logikou pro práci s daty
Jcas
Profil *
Jan Tvrdík:
Nemůžeš mi prosím uvést nějaký příklad, protože jinak to asi nepochopím.
Ad2 rozhodnu si co se má zobrazit a ad1 to zobrazím, potom pro ad1 nepotřubuji žádné OOP, protože už mám rozhodnuto co se má zobrazit, takže to prostě zobrazím.

Ad2: Také nepotřebuji OOP, protože by to byla jedna metoda, která rozhodne, co se má zobrazit.
Micruss
Profil
Tak proč řešíš "Přemýšlení v OOP" když to teda nepotřebuješ?
_es
Profil
Jcas [#5]:
OOP naozaj na nič nepotrebuješ. Je ho možné použiť na to, aby to bolo tak nejako z ľudského hľadiska zrozumiteľnejšie. Ak si však nepochopil základné princípy OOP, tak jeho použitím dosiahneš opak a len pridáš ďalšiu nadbytočnú obalovú vrstvu.
Jcas
Profil *
Právě proto to řeším. Chtěl bych tak nějak umět rozpoznat situaci, kdy ho použít, protože se hodí a kdy se naopak vůbec nehodí.
Joker
Profil
Jcas:
MVC - pohybuju se pouze v jedné sekci a to "view".
To bych rozporoval, většina toho grafu je v působnosti controlleru. View je v podstatě jen kostička „Print form“.

Graf popisuje nějakou entitu a je v něm vidět, že pro ní jsou třeba operace čtení, přidání a editace (což je běžné, když o něčem uchovávám data, budu obvykle potřebovat čtyři základní operace zvané „CRUD“, Create, Read, Update, Destroy).

Takže pokud bych to navrhoval jako MVC, nejspíš by to znamenalo vytvořit nějaký ZvireController s operacemi Create, Read, Update (Destroy se v grafu nezmiňuje).

Z toho grafu to jde těžko vidět, protože ten graf je nejspíš překreslený klasický strukturovaný skript.
Lepší by asi bylo si udělat něco na způsob use case z UML. Není to tak těžké, vlastně jde o to si udělat seznam, co všechno s aplikací má jít udělat a pro každou položku pak vypsat sekvenci toho, co se v daném případu užití musí udělat.

Podle grafu tedy mám entitu Zvíře. Uživatel může přidat zobrazit záznam, upravit, nebo přidat nový záznam.
UC1 Zobrazení záznamu:
1. Uživatel pro určitý záznam zvolí akci Zobrazit
2. Přes identifikátor záznamu se načtou data příslušného záznamu
3. Data se prezentují uživateli přes formulář xyz1

Alternativní tok událostí:
bod 2. Pokud záznam není nalezen, zobrazí se chybová hláška (…)

UC2 Přidání záznamu:
1. Uživatel zvolí akci Přidat záznam
2. Zobrazí se formulář xyz2
3. Uživatel odešle formulář
4. Validace formuláře
5. Je založen nový záznam se zadanými údaji
6. Uživateli se zobrazí informace o úspěšném uložení záznamu

Alternativní tok událostí:
Bod 3: Uživatel může místo odeslání přidání záznamu zrušit, pak je vrácen na seznam záznamů
Bod 4: Jestliže data nejsou platná, pokračuje se bodem 2. s tím, že uživateli jsou zobrazeny dříve zadané údaje a označeny chyby.
Bod 6. Jestliže se uložení nezdařilo, je uživateli zobrazena chybová hláška (…)

A tak dále.
(Poznámka, šlo spíš o znázornění podstaty, než vyrobit „teoreticky čistý“ use-case. Kdo by chtěl „teoreticky správně“ udělaný use-case, ať si najde literaturu k UML.)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: