#18 SVKSuli
Pokud si myslis, ze to vsechno znas tak se mrkni treba na github, tam je spousta projektu a knihoven v jave. Treba tohle vypadlo z googlu jako jeden z prvnich odkazu: https://github.com/iluwatar/java-design-patterns
Vetsina projektu bude mit nejaky adresar se zdrojaky a pak adresar s testy, bude to nejak logicky rozdelene, podle toho co ktera cast dela. Pokud se pouziva maven, tak tam bude pom.xml atd.
V dnesni dobe pokud aplikace nejakym zpusobem zobrazuje vysledky uzivateli, tak se pouziva MVC design pattern (model view controller), model jsou data, controller obsahuje logiku, ktera to ridi a view to zobrazuje uzivateli, v kodu pak najdes casti, ktere toto nejakym zpusobem implementuji.
Dost casto se dnes taky pouziva vrstvena architektura, tzn kod je rozdelen na ruzne vrstvy, ktere mezi sebou komunikuji, na nejnizsi vrstve mas DAO objekty (data access object), ktere maji na starost samotny pristup k datum, napr spusteni dotazu nad databazi, zapis do souboru.
Nad DAO muze (a nemusi) byt nejaka service, ktera obsahuje logiku, ktera s temi daty neco dela, nad tim muze byt facade vrstva (ale vetsinou neni), ktera ridi volani service. Pokud je kod rozdelen na vetsi kusy (moduly) tak se tam muze vyskytovat vrstva adapteru, ktera umoznuje modul odebrat a nahradit ho jinym no a pak tam muzou byt vrstvy, ktere se staraji o gui.
U vrstvene architektury se na zacatku stanovi pravidla, ktera rikaji kdo s kym muze komunikovat a to se pak striktne dodrzuje, napr. kdyz se nekdo pokusi z gui komponenty zavolat DAO tak by to but nemelo jit a nebo tam bude nekdo kdo mu da pres prsty.
U amaterskych programu se vetsinou o architekture neda moc mluvit, aby architektura vubec mohla vzniknout tak nejprve musim vedet co chci delat, pak jak to budu delat a z jakych casti se to bude skladat a z toho uz mi automaticky vyplynou nektere veci jako jake dao objekty tam budou, jake rozhrani budu muset navrhnout (protoze neco bude komunikovat s necim) atd.
Kdyz treba reknes, ze chces udelat kalkulacku s gui, tak bych ti rekl, aby jsi to rozdelil na tridu s main metodou, pak tridu co bude obsluhovat ksicht a tridu, ktera bude delat samotne pocitani. Pokud budes chtit vetsi funkcionalitu, treba menu, dialog s nastavenim, tak si takovy kod vyextrahujes do nove tridy / souboru a budes to volat z techto puvodnich trid. Obecne by jsi se mel vyhnout tomu, ze jedna trida dela prilis mnoho veci, idealne by mela delat jen jednu vec a z nazvu tridy by melo patrne co dela.
Napriklad kdyz pojmenuju AddressDAO a budou v ni metody, save, load a delete, tak je jasne co to asi bude delat - save mi ulozi objekt typu Address, load ho nacte, delete ho smaze. Rozhodne by takova trida nemela ukladat jine typy objektu, nedejboze treba hrabat do nejakeho GUI atd.
Prijde mi ale celkem zvlastni ze tvrdis, ze toho spoustu znas a neslysel jsi o collections a ztracis se v par tridach. Problem muze byt v tom, ze prectenim nejakeho jednoducheho prikladu clovek casto nabude iluzi, ze vi jak to funguje a pritom to vubec neni pravda. Takze bych si ty zaklady prosel znovu ale poradne na nejakych komplexnich prikladech