OMO Flashcards

Question

Systemu nevhodne pro OOP (ale spis funckionalni pristup)

Answer 1

Takove, kde vypocet je pouze sekvence operaci nad vstupnimi daty podle navratovych hodnot nebo vstupu - treba nejaky pipelinie flow - jako vyhodnoceni neuronovych siti - tam, kde prijde nejaka hodnota a ted se nad ni provede hodne opearci a vrati jeden vysledek - je to jako vyrobni pas transofmraci na vstupni hodnoty - na poradi funkci nezalezi OOP to nezvladne efektivne, protoze by zbytecne hromadilo tridy na kazdy mozny krok, zatimco bychom to mohli napsat jako jeden radek agregaci funkci

Answer 2

1. Creator - vytvari zcela novy objekt datoveho typu - muze ale nemusi mit parametr jineho typu - nesmi mit parametr STEJNEHO typu jako ten, co vytvari - t* -> T - treba new Integer() 2. Producer - vytvari novy objekt ze starych - tedy jako arguemtn uz potrebuje stejny typ, a treba i jiny typ - T+, t* -> T - treba operce nad stringy v Jave -> string je immutable, takze treba append musi vytvorit novou kopii rozsirenou, bere ale stary string jako parametr 3. Observer - "pozoruje" jeden Typ a vraci jiny typ - potrebuje parametr jeden typ, a treba i jiny - vraci jiny typ - T+, t* -> t - treba size(), len() je observer 4. Mutator - meni objekt urciteho typu, ktery dostante - bere objekty typu T a meni ho - T+, t* -> void | t | T - treba add() v riapde lsitu, remove() kde + je alespon jeden vyskyt, * je jakekoliv opakvoani i 0, | je nebo

Answer 3

int je primitivní datový typ. int je immutable, nemá tedy žádné mutators. § creators: čísla 0 , 1 , 2 , … § producers: arithmetické operátory + , - , * , / § observers: porovnávací operátory == , != , < , > § mutators: nemá List je typ pro reprezentaci listu. List je mutable. List je také interface, což znamená, že ho implementují ostatní třídy, např. ArrayList a LinkedList . § creators: ArrayList a LinkedList konstruktory, Collections.singletonList § producers: Collections.unmodifiableList § observers: size , get § mutators: add , remove , addAll , Collections.sort String je typ pro reprezentaci řetězce. String je immutable. § creators: String konstruktory § producers: concat , substring , toUpperCase § observers: length , charAt § mutators: nemá

Answer 4

1. Je lepsi mit mensi mnozinu jednoduchych operaci, nez velkou slozitou 2. Operace musi fungovat ve 100% vyuziti - sum() nema smysl pro List Stringu 3. ADT poskytuje vsechny operace - odstranuju operace a koukam, zda je potreba 4. ADT neposkytuje vic nez potrebuju - redundanrni operace 5. Nekombinuje genereicke a specificke vlastnosti

Answer 5

Treba pridanim checkInvariant() kontroly pri kazde urpave ADT, nebo pokusu o upravu private, final, getter/setter, spolu se zakazem kopii, nebo checkInvariant

Answer 6

Vlastnost, ktera je v ramci ADT splnena vzdy za vsech podminek Treba invariant Stringu - je immutable Invariant Listu -> drzi poradi prvku.. Dobry ADT si drzi vlastni invarianty a kontroluje je

Answer 7

Je ohrozeni viditelnosti vnitrnim atributy tridu - kdyz jsou public -> jsou videt a jsou nastavitelne zvne

Answer 8

1. Creational 2. Structural 3. Behavioral

Answer 9

Z pohledu ulozeni a navratu k datum: 1. Ephemeral DS - nepersistentni, neukladaji data vubec - jako linked list jednosmerny, pouze hodnota a ukazatel na dalsi element 2. Castecne perzistentni - uklada lienarni seznam verzi D S, ale updatovat muzu pouze posledni aktualni verzi - pridam k elementu polozky Modifications, kam zaznamenavam vsechny urpravy na tomto elementu 3. Plne perzistentni - muzu se dotazovat i updatovat starsi verze, pri updatu starsi verze se musi zalozit nova vetev (abych neprepsal vsechno co se stalo potom), stromovita struktura - Zpětné reference – víme, kdo na koho odkazoval v jaké verzi. - Rozdělení uzlů (splitting) – při plném mods logu dělíme uzel a přelinkujeme strukturu. - Správa verzí – umožňuje větvení historie, backtracking a správu změn mezi verzemi. 4. Merge perzistentni - je to plne perzistentni model, ktery anvic podporuje merge vetvi do jednoho vysledku 5. Funkcni perzistence - muzu se dotazovat i updatovat starsi verze, ale pri jakekoliv uprave se vytvori zcela nova cela kopie cele DS - jako funkcionalni programovani 6. Retroaktivni perzistence - uprava starsich verzi se propise do budoucnosti a ovlvni tak vsechny nasledujici stavy, pokud zmenim verzi minulou, tak se tato zmena propise do vsech nasledujicich verzi v aktualni vetvi

Answer 10

Lazy loading je přístup při kterém odkládáme nahrání objektu z nějakého repository až do doby, kdy ho potřebujeme. Lazy loading použijeme v případě, že nahrávání objektů z repository je náročné nebo nahrávané objekty zabírají nezanedbatelnou část v paměti. Používají se čtyři druhy implementací lazy loadingu: ● Virtual proxy ● Lazy initialization ● Ghost ● Value holder

Answer 11

🧳 Virtuální proxy (lazy loading přes zástupný objekt) 🔁 Vytvořím jiný objekt (proxy), který se chová jako skutečný objekt, ale místo něj ho jen „zastupuje“ do doby, než je potřeba. 🧠 Proxy drží pouze referenci nebo data potřebná k pozdějšímu vytvoření reálného objektu (např. jméno souboru, ID z DB). 📦 Když někdo zavolá metodu (např. getCustomers()), proxy zjistí, že nemá ještě reálný objekt: vytvoří ho (např. načte z DB), uloží si ho a přepošle volání při dalším volání už používá reálný objekt ➡️ Proxy obaluje skutečný objekt zvenku, takže okolí nepozná rozdíl ✅ Vhodné, když je vytváření samotného objektu drahé (např. new Image("path")), a chceme ho odložit - hlavne funguje navenek, tedy tvari se jako real objekt ale s prazdnymi daty, jakmile ho nekdo zavola, tak se aktualizuje na skutecny objekt s nactenymi daty

Answer 12

🐢 Lazy inicializace (lazy loading uvnitř objektu) 🔁 Odkládá vytvoření nákladných dat do okamžiku, kdy jsou skutečně potřeba. 🧠 Uvnitř objektu si nastavím atribut (např. customers) na None, protože k datům možná ani nikdy nedojde → šetří paměť a zrychluje start. 📦 V metodě jako getCustomers() zkontroluju, zda už jsou data načtena: pokud None, načtu z databáze, uložím, vrátím pokud už dříve načteno, rovnou vrátím ➡️ Typicky implementováno jako if self._data is None: load() ✅ Funguje přímo uvnitř objektu (bez dalších tříd nebo obalů) - funguje hlavne uvnitr RealObjektu, tedy netvari se jako dummy, ale je to skutecna trida, ktera jen docasne ma prazdne atributy

Answer 13

Ghost (duch) v Lazy Loading je technika, kde objekty nejsou úplně načteny při inicializaci, ale místo toho se načítají pouze jejich identifikátory (ID). Skutečné objekty jsou načítány až tehdy, když je opravdu potřebujeme. 🧠 Co to znamená? Místo kompletního načítání celého objektu (např. uživatele a jeho objednávek) se uloží pouze ID těchto objektů. Skutečné objekty jsou "dotahovány" později na základě těchto ID, jakmile se na ně přistoupí. 🛠️ Použití v praxi (ORM nástroje): ORM nástroje jako Hibernate používají ghost loading pro načítání grafů objektů z databáze. Při inicializaci se místo celých entit načtou jen jejich identifikátory. Kompletní objekty se načtou až při přístupu k jejich metodám nebo vlastnostem. ✅ Výhody: Úspora paměti: Nezbytné objekty se načítají jen při potřebě. Rychlost: Při inicializaci se nenačítají všechna data najednou, což zrychluje start. class User { private List orderIds; // ID objednávek místo objektů public List getOrders() { if (this.orders == null) { this.orders = loadOrdersByIds(orderIds); // Načítání objednávek podle ID } return this.orders; } }

Answer 14

Object pool je de facto zásobárna přepoužitelných ”resources”, které jsou náročné na vytvoření a proto si je po vytvoření raději ponecháme pro další použití místo toho, abychom je likvidovali a vytvářeli znovu a znovu. Příklady jsou pooly databázových spojení, file handles, proxy na provolání externí služby, java objekty vašeho programu, které jsou náročné na vytvoření a přitom se dají přepoužívat. Pooling těchto resources poskytuje výrazné zlepšení performance zejména v případech, kdy se jsou náročné na vytvoření a používají se velmi masivně. Výhoda pooling je také, že máte predikovatelný čas a memory footprint při práci se zdroji. Object pool má parametry, kterými dále ladíme propustnost vašeho programu, maximalizujete memory footprint atd.: ● Maximální počet resources - množství resources je omezeno shora => maximalizace memory footprint ● Minimální počet resources - množství resources je omezeno zdola => resources se vytvoří dopředu, takže nemusíte čekat ani při prvních voláních, kdy ještě nejsou resources vytvořeny ● Doba nepoužívání po které se resource likviduje => zamezujete tomu, aby v poolu byly drženy nepoužívané resources Treba dopredu vytvorim 10 pripojeni do databaze a uz nemusim cekat ani na prvni potrebne volani, jen vezmu pripojeni, pouzivam ho, vratim do poolu dalsi ukazkou je THread Pool

Answer 15

Cache použijeme v případě, že chceme načíst resource nebo data jednou, ale používat vícekrát. Jedná se o další design pattern, který se hojně používá pro zlepšení performance. Cache funguje takto: Aplikace požaduje data z cache pomocí klíče. Pokud klíč není nalezen, aplikace načte data z externího zdroje dat (pomalého) a vloží je do cache. Další požadavek na klíč je obsluhován z cache. Cache nalezneme na různých vrstvách (Java, Databáze, UI) systému, většinou se používá několik cache najednou (jedna na každé vrstvě) Pozn.: Design pattern object pool se liší od cache v tom, že spravuje řádově menší množství resources, resources se od sebe neliší a de facto je zapůjčují klientským threadům dokud ty je nevrátí. Tedy Pool uchovava rychly pristup k TOOLS ktere pracuji nad daty, naopak cahce uchovav primo DATA a mnohem vic nez toolu Hit/Miss rate, eviciton policy stejne jako APO... Cacheovatelny objekt pri praaci s databazi pak mohu oznacit jako @Cacheable @CacheEvict - oznaci, ze pri odstraneni teto entity, se ma smazat i z cache, aby nevracela zastarala data, kdyz uz realne nejsou v systemu

Answer 16

Je to uzitecny API nastroj pro NPE - Null Point Exception Je to oznaceni parametru, ktery pokud je v runtime = Null, tak se automaticky vlozi osetrujici kod, ktery misto padu systemu vyhodi vyjimku treba: foo(@NonNull parametr1) do something... Se pri prekladu prelozi na: foo(parametr1) if (parametr = Null) -> throw exception... else -> do something() Tedy je to uzitecne oznaceni mista v kodu, kde se ma provest NotNull kontrola, aniz bychom ji museli psat rucne a zneprehlednovat kod Podobny pristup je pomoci assert(notNull), nebo pomoci zakalndni Object.metody -> Object.reuriedNoNull(parametr1) - nebo pomoci Optional

Answer 17

Monáda = obal na hodnotu s bezpečným řetězením (Optional, Stream) 🔹 Lambda = (x) -> x + 1 – anonymní funkce 🔹 Stream API = zpracování kolekcí jako proudu dat list.stream() .filter(x -> x > 0) .map(x -> x * 2) .collect(Collectors.toList()); 🔹 Řetězení s kontrolami (Optional) Optional.of(user) .map(User::getAddress) .map(Address::getCity) .orElse("Unknown"); 🔹 Function.andThen Function f = String::trim; f = f.andThen(String::toUpperCase); f.apply(" ahoj "); // "AHOJ" ✅ Funkcionální styl: bezpečný, čitelný, bez nulových kontrol

Answer 18

Vyuziva funkcionalniho pristupu pro abstraktni flow dat -> vytvori se pipelina ze streamu dat, kde hromadenim funkci aplikujeme na jednotliva data sze streamu Je to elegantnejsi zpusob nez rucni iterovani pres smycky, filtrovani podle jednoho predikatu atd..., nebo i pomoci teratu Je to elegantni funkcionalni zpusob jak pouhou agreagaci funkci a lambda funkcecmi a predikaty zachazet s proudem dat, kde vsechna funkconalita uz je naimplementovana pod kapotou a nam stai pouze vedet co chceme, jaka je na to funkce a jak ji zavolat

Answer 19

proud dat, ktery vytvari jakousi pipelinu na osetreni jednotlibych elementu - konecna posloupnost operaci aplikovana na nejaky stream = pipeline Terminalni operace - takova, ktera nad daty z proudu provede nejaky agregacni vypocet a vrati jednu jedinou hodnotu, stream se uzavre - treba sum() Neterminalni operace - takvoa, ktera zmodifikuje stream a pokracuje dal jako stream, treba filter(), map() Stream muzu vytvorit z liboolvne kolekce, nebo ho zalozit from scratch nebo induktivne Stream muzu zavest i jako paralelni - vsechny neterminalni operace (treba map) jsou lazy - provedou se az v moment potreby

Answer 20

Předpokládejme, že existuje třída Person s atributy name (jméno), age (věk), city (město). Dále mějme kolekci nějakých lidí uloženou v kolekci people. Chceme najít jméno nejstaršího člověka z Washingtonu: String name = people // převést na stream .stream() // dál propustit pouze lidi z Washingtonu .filter(p -> p.getCity().equals("Washington")) // seřadit podle věku sestupně .sorted(Comparator.comparingInt((Person p) -> p.getAge()).reversed()) // najít první takovou osobu .findFirst() .get() // získat jméno osoby .getName();

Answer 21

Obycejny fold z funkcionalniho programovani...

Answer 22

Operace Popis filter filtruje prvky podle zadaného predikátu map převádí prvky na jiné pomocí zadaného zobrazení groupBy Seskupení podle vybraného atributu reduce generická operace redukce terminální max konkrétní operace redukce terminální limit omezí maximální délku streamu na zadaný počet prvků terminální sorted prvky v streamu budou do dalších operací předávány seřazené findFirst vezme první prvek z streamu count spočítá prvky v streamu flatMap jako flatten, tedy vnitrni listy spoji do jednoho forEach poskytnutou funkci provede na kazdy prvek, jako map ale uz terminalni

Answer 23

double avgAge = people // převést na proud .stream() // od osoby získat její věk .mapToInt(p -> p.getAge()) // z čísel vypočítat průměr .average() .getAsDouble();

Answer 24

Objekt, ktery agreguje prvky a vrati v nejake typove kolekci // sesbírá jména lidí do seznamu List list = people.stream().map(Person::getName).collect(Collectors.toList()); Kolektor je třída, která agreguje prvky ze streamu. Existují kolektory, které prvky jednoduše uloží do seznamu, provedou seskupení podle nějakého kritéria a tyto skupiny uloží do mapy, a podobně. Lze vytvářet i vlastní kolektory. // seskupí osoby do mapy podle města, kde žijí Map> personByCity = people .stream() .collect(Collectors.groupingBy(Person::getCity)); // do mapy uloží počet osob v každém městě Map peoplePerCity = people .stream() .collect(Collectors.groupingBy(Person::getCity, Collectors.counting()));

Answer 25

Motivace Cílem je: ▪ Nebýt omezen datovými typy ▪ Typ Object komplikuje/znemožňuje datovou kontrolu ▪ Rozšíření typové kontroly ▪ Využít kód opakovaně s různými datovými typy Chci mit spojovy seznam treba pro ruzne typy a neprepisovat celou implementaci Definuju jako class Node, kde vsude kde bych psal treba int, budu psat T. Pak dekalruju jako Node node = new Node(4)... Vetsinou uz pouzivam defaultne, treba kdyz vytvarim list, tak specifikuju jaky ty: List list = new ArrayList<>(); Generikcy typ je presna parametrizace vstupnich parametru pomoci abstraknit generiky . Genericky typ nemuze byt instanciovan primitivnim typem, nejde tedy udelat: List list = new ArrayList<>();, musim udelat Genericky parametrizovat muzeme i objekt, kdy do konstruktoru posleme typ T, typu T jsou i atributy, ktere se nastavi v konstruktoru Type erasure = generické typy fungují jen v čase kompilace. V čase běhu je nahradí syrové typy (raw types) jako List. Tedy v kompilaci pracujeme s generickymi typy, ale v runtime uz se vynuti konkretni implementace. v runtime uz nemuzeme pouzivat genericke typy, protoze v ten moment se uz musi znat konkrentni typ

Answer 26

class Animal {} class Dog extends Animal {} class Puppy extends Dog {} 🟢 ? extends T – Pouze čtení (read-only) List dogs = List.of(new Puppy(), new Dog()); // dogs.add(new Dog()); // ❌ NELZE přidat – nevíme přesný typ Dog d = dogs.get(0); // ✅ Lze číst – víme, že je to Dog nebo jeho potomek 📌 Použití: Když chceš číst objekty z kolekce, ale nechceš do ní přidávat (např. List) - tedy je to MUZU CIST OBJEKTY ODE ME A NIZ - nesmim ale zapisovat, protoze to zakladam treba jako new PuppyList - tedy zalozim list NEKONKRETNIHO TYPU - ale INTERVALOVEHO od Dog a niz - tedy pokud mam nekonkretni List -> tak tam nemuzu vlozit konkretni typ, protoze to endava smysl - muzu ale bezpecne cist jako get Dog, protoze ten interval zacina od Dog a niz a vsude kde muzu pouzit DOg tak muzu pouzit i jeho potomky diky polymorfismu - je to kovariance (read only) 🔴 ? super T – Pouze zápis (write-only) List animals = new ArrayList(); animals.add(new Dog()); // ✅ Lze přidat Dog i Puppy // Dog d = animals.get(0); // ❌ Nelze bezpečně přečíst – může být Animal Object o = animals.get(0); // ✅ Lze číst jen jako Object 📌 Použití: Když chceš přidávat objekty určitého typu a jeho potomků, ale číst jen jako Object. - tedy ase zavedu intervalovy typ ale od Dog a vys - tedy muzu bezpecne vkladat objekty, ktere mi muzou zastoupit Dog, takze jeho potmoci Puppy atd. - nemuzu cist, protoze ten List muze mit typ Animal a ja nemuzu do typu Dog priradit typ Animal - je to kontravariance 🧠 Shrnutí: Deklarace Vkládat Číst jako List ❌ Ne ✅ Dog List ✅ Dog, Puppy ❌ jen Object

Answer 27

Předchází chybám – dobrá specifikace jasně dokumentuje předpoklady, na kterých staví klient i implementátor. Chyby často vznikají z nesprávně pochopeného rozhraní a specifikace tomuto přechází. Používání strojem kotrolovaného popisu ve specifikaci jako typová kontrola a použití výjimek může ještě více redukovat chyby § Srozumitelnost - krátká jednoduchá specifikace je mnohem více srozumitelná než vlastní implementace. Ostatní vývojáři nemusí studovat kód, aby mohli rozhraní využít § Připravenost na změny - specifikace zavádí kontrakt mezi různými částmi kódu. Tyto části se mohou, pokud dodrží kontrakt rozhraní rozvíjet nezávisle Klient-friendly popis kodu. Je to obousmerny konkratk mezi vyvojarem a klientem, jako textovy popis systemu s jeho chovanim, aby vyvojari dodrzovali pozadavky a klient vedel, co se k cemu a jak pouziva Muzou se vyvjet nezavisle, tedy kazda uprava kodu se nemusi znovu distribuovat, prtooze pokud splnuje specifikaci, tak klienta to odstinuje od detailu jak to funugje uvnitr

Answer 28

Pokud dva kodu se chovaji stejne a jsoy tedy zamenitelne v ruznych kontextech - roli hraje vstupni aprametry - vystupni hodnoty - kontext ve kterem bezi kod specifiakceby proto mela obsahovat: Precondition - zavazek pro klienta, podminky pro vstupni hodnoty Postconditions - zavazek pro implementatora, popis samotne implementace funkce, tedy co ma kod v JavaDocu treba konkretne udelat a co vratit - dohromady popisuyji kod a porovnavame ho s jinym popisem jineho kodu - obecne to enni testovatelny 1. Reflexni 2. Symetricka 3. Transitivini - relace ekvivalence

Answer 29

s2 je silnejsi nebo stejna jako s1 kdyz: - preconditions pro s2 jsou slabsi nebo stejne jako pro s1 - zaroven postcondtions pro s2 jsou silnejsi nebo stejna jako pro s1 - tedy povolili jsme vice vstupu, ale konkretizovali implementaci - tedy je to obecnejsi kod na parametry, ale konkretnejsi na implementaci => silnejsi specifiakce V takovem pripade muzeme pouzit s2 vsude tam, kde se puvodne pouzivala s1, protoze splnuje jeji pozadavky ale navic povoluje i vice parametru vstupnich

Answer 30

Deterministic - specifiakce, ktera presne stanovi implementaci - treba vrat 1. vyskyt hodnoty v poli Undetermined - programator ma volnost vyberu, jen malo omezene specifiakci - treba vrat jakykoiv vyskyt hodnoty v poli

Answer 31

Operativni - stanovuje sekvenci kroku, co se ma provest v tele funkce Deklarativni - stanovuje mnoziinu vstupu a podle toho logiku vystupu - je to vic prefereovany zpusob - funkce je black-box co bere a vyplivne nezavisle na implementaci - je to odstineni

Answer 32

§ Specifikace je klíčový kontrakt mezi implementátorem a klientem § Měla by být srozumitelná § Měla by být koherentní – metody by měly mít vždy jednu jasně definovanou zodpovědnost § Návratová hodnota by měla nést jasnou a jednoznačnou informaci § Specifikace by měla využívat abstraktní typy § Zabraňuje chybám při volání rozhraní způsobených různým výkladem rozhraní § Připravena na změny

Answer 33

Representational State Transfer - specifiakce API, z roku 200 - vetsinou vazany na HTTP - navrzen na zaklade resources systemu, kte kterym s euzivatele mohou dotazovat pomoci URI - jednoznacny odkaz pres http://... - pouziva hlavne json format zprav - jednotny interface komunikace se serverem pomoci GET, PUT, POST, DELETE, PATCH - bezestavovy model - orientace na data, nikoliv procedoruy GET = read PUT = update POST = create DELETE = delete Uzivatel posle HTTP pozadavek na nas system - REST API/endpoint to zachyti - zpracuje - posle reponse ve forme JSNO/XML zpravy s definovanym kodem

Answer 34

Webove application programming interface na serveru - server ma endpointy - komunikace pomoci request-response - json nebo xml - soap vs rest - vetsinou http kodu a komunikace

Answer 35

SOAP - zakladni vrstva komunikace mezi webovymi sluzbami - popis pomoci WSDL - web service description language WSDL popisuje - abstrakci - datove tyoy XML, zpravy, orpace - prenosoovy protokol - konkretni popis formatu a endpointu

Answer 36

Nejzyuzivanejsi specifiakce pro navrh web rest API, zameruje se na vytvoreni a zkvalitnovani formatu a popisu Definuje standard pro popsis rest api, nezavisle na prog. jazyku - umoznuje pouze z popisu porozume sluzbam API aniz by clovek musel rozebirat kod - dobre navrzena specifiakce umoznuje nasazovat kod bez znalosti - muze byt pouzita pro generovani klientskeho i serveroveho kodu - generovani testovacih scenaru - generovani dokumetncae - validovani zprav

Answer 37

Framework pro definici rozhrani podle specifikace openAPI - pokryva cely zivotni cyklus vyvoje systmeu - navrh, dokumentace, testovnai, deploy Swagger editor - navrh - codegen - build - inspector - testovani - ui - dokumentace

Answer 38

podobny nastroj jako Swagger pro definici rozhrani - editor strukturovnaeho popisu rozhrani - dokumetnace - testovani Insomnia, Postman...

Answer 39

SOAP § Je to protokol, kdy 2 počítače komunikují sdílením XML dokumentu § Pouze XML § Čtení nemůže být cachované § Je jako běžná desktop aplikace úzce spojená se serverem § Je pomalejší než REST REST § Běží na HTTP § Rest je architektonická služba a design pro síťově orientovanou softwarovou architekturu § Podporuje mnoho datových formátů § Čtení může být cachované § Klient je jako prohlížeč – ví, jak standardizovat metody a aplikace musí sedět § Je rychlejší než SOAP § Užívá HTTP hlavičku pro držení metadat

Answer 40

Efektivni nastupce REST API - facebook, github, pinterest, shopify... - dotazovaci jazyk na urovni aplikacni vrstvy pro API - umoznuje klientuvm si vyzadat presne ta data, ktera poterbujia nic navic - operace totiz vraci objektovy graf a muzu si specifikovat, do jake hloubky chci ten graf a jak hluboko potrebuju atributy - muzu specifikovat mnozinu vracenych atributu - podporuje strankovani - cachovani odpovedi pripomina OOP svymi datovymi typy - lepsi vykon pri vyssi zatezi - efektivnejsi komunikace se serverem

Answer 41

🔄 REST API Struktura: Mnoho endpointů (např. /users, /posts) Pevná data: Server určuje, co klient dostane Více požadavků: Pro složená data je často třeba více volání ✅ Výhody: Jednoduché, známé, dobře cachovatelné (HTTP cache) Vhodné pro jednoduché CRUD operace ❌ Nevýhody: Neflexibilní (overfetching/underfetching) Více požadavků pro složitá data 🧪 Příklad: GET /users/1 → { "id": 1, "name": "Alice", "email": "a@example.com" } 🧠 GraphQL Struktura: Jeden endpoint (/graphql) Flexibilní dotazy: Klient si řekne, co přesně chce Jedno volání: I složená data v jednom requestu ✅ Výhody: Přesně definovaná data Méně dotazů = rychlejší pro složené UI ❌ Nevýhody: Složitější na implementaci a cachování Nutnost udržovat schéma 🧪 Příklad: query { user(id: 1) { name email } } → { "data": { "user": { "name": "Alice", "email": "a@example.com" } } } 🔍 Klíčové rozdíly: REST GraphQL Endpointy Více Jeden (/graphql) Data struktura Server určuje Klient určuje Výkon Více requestů často Jeden komplexní dotaz Caching Snadné (HTTP cache) Těžší Vývoj klienta Méně flexibilní Vysoce flexibilní

Answer 42

Microservisní architektura je o redukci komplexity pomocí dekompozice systému na moduly, které jsou dobře ohraničené z hlediska fungování a účelu. V business termínech by microservice měla realizovat jednu business capabilitu (schopnost či dovednost) Microservice nemá nic společného s velikostí, ale je o maximálním respektování Single Responsibility Principle (SOLID) Microservisy fungují zcela samostatně a autonomně. Microservice preferuje, aby měla vlastní databázi do které napřímo nepřistupuje žádný další systém (či microservice), tyto databaze mohou byt naprostor ruzne - objektove, relacni, grafove nezavisle na ostatnich... Dvě microservisy mohou sdílet data a odpovědnost. Děje se tak přes třetí subjekt. Závislost je však co nejmenší a nejvolnější.

Answer 43

✅ API Gateway – co to je: Jednotná vstupní brána (gateway) do systému, která: Přijímá všechny externí HTTP požadavky Přesměrovává (deleguje) je na správné mikroservisy Často zajišťuje další funkce jako autentizaci, rate limiting, logging, caching, transformaci da Rozkládání zátěže

Answer 44

Kdyz mikroservisy maji vlastni databaze - muze dojit k nekonzistenci dat - treba zalozim Order s ID uzivatele, ktery neexistuje v jine datazbi Clients - je potreba tedy porad zarizovat kontrolu dat - nevyhoda - potreba synchronizace a kontroly - vyhody - ruzne druhy databazi, nezavisle na sobe, lokalni priostupy, nic se nemeni pod rukama, rychly pristup... Shared Databaze - mikroservisy sdileji databazi - nemuze dojit k nekonzistencim - splnuje ACID vlastnosti - vyhody - zajistena konzistence - nevyhody - sdileni pameti, pomalejsi, zmeny pod rukama... Kombinace sdileni databaze pro mikroservisy ktere logicky se sebou souvisi a naopak vlastni databaze pro nezavisle mikroservisy

Answer 45

🧠 Pojem: Orchestrace Centrální služba (orchestrátor) koordinuje více mikroservis – řídí jejich volání, pořadí, závislosti. ✳️ Otázka: „Co kdybych potřeboval službu, která volá jiné služby ve správném pořadí a spojuje výsledky?“ ✅ Řešení: Použiješ orchestraci – centrální „řídící“ službu. 🧪 Příklad: Máš tyto služby: UserService (vrací uživatele) OrderService (vrací objednávky) PaymentService (vrací platby) Orchestrátor volá: 1. GET /user/123 2. GET /orders?userId=123 3. GET /payments?userId=123 → vrátí sjednocenou odpověď Řídící logika je v orchestrátoru – mikroservisy o sobě navzájem neví.

Answer 46

🔄 Pojem: Agregace Klient (nebo API Gateway) volá více mikroservis paralelně nebo nezávisle a sám kombinuje výsledky. ✳️ Otázka: „Co kdybych potřeboval stránku, která zobrazí data z více služeb současně?“ ✅ Řešení: Použiješ agregaci – např. v API Gateway, frontend klientu nebo BFF (Backend-for-Frontend). 🧪 Příklad: Frontend potřebuje: uživatele (/user/123) jeho objednávky (/orders?userId=123) jeho platby (/payments?userId=123) Frontend pošle 3 požadavky paralelně a sám sestaví odpověď do UI. Logika je v klientovi – mikroservisy nejsou nijak závislé, ani neví, že jsou kombinovány.

Answer 47

Change Data Capture PROBLÉM: V jedné microservise chci reagovat na změny v datech spravovaných druhou mikroservisou nebo chci jako eakci přímo měnit obsah svých dat. CDC nástroj je napojen na úložiště dat, konkrétně na jeho transakční logy, aby výkonově nezatěžoval datové úložiště a přetváří změny v datech v eventy. Ty je pak možné aplikovat jinde – např. Provoláním operace na jiné mikroservise nebo změnou dat v jiném datovém úložišti. Příkladem technologie umožňující CDC je Kafka Debezium nebo Oracle Golden Gate

Answer 48

Greenfield - novy projekt, kde si jak na zelene louce muzu zakladat nove elementy a mikroservisy Brownfield - system, ve kterem uz neco funguje (vetsinou v rpaxi hodne zastarale komponenty) a ja do toho musim neco pridat noveho - mikroservisu Jak vyresit problem komunikace - nepodporovnay treba starym systemem? - reseni pridanim Anticorruption layer Anticorruption Layer - prechodna pomocna prekladaci vrstva mezi novymi servisami a starym/monolitickym systemem - slouzi jako tlumocnik - predava API pozadavky a data mezi dvema svety v ruznych jazycich - klasicky preklad REST <-> SOAP - novy system by nikdy nemel komunikovat primo se starym, protoze vetsina osetrovaci a kontrolne logiky je implementovana prave v ACL Strangler - Skrtic - metoda, jak z rozsahleho monolitu POSTUPNE prejit k mikroservisam - jednorazove stepeni je prilis slozite a mohlo by zanest nedohledatelne chyby - proto z monolitu vzdy postupne "uskrtime" jednu logickou cast a prohglasime ji za novou servisu - mezitim ale zachovavame puvodni funkcni monolit + nova servisa - klient by tedy nemel mit preruseni - nevi o tomto procesu v podstate - postupne tak jak z testa na estoviny uskrtime dalsi a dalsi logicky jednotky - casem prechod na mikroservisy

Answer 49

Docasna nekonzistence systemu - z technickych nebo business duvodu nejde zarucit 100% konzistenci systemu 24/7 - proto system navrhuju tak, aby byl pouzitelny i v nekonzistentnim stavu - tedy aby byl funkcni i s treba docasnym vypadkem nejake komponenty - treba rozbity eskalator se da furt pouzit

Answer 50

🔄 Co je Saga (v mikroservisách)? Saga je design pattern pro zajištění datové konzistence v distribuovaném systému (např. mikroservisách), kde není možné použít klasickou databázovou transakci napříč službami 📌 Problém: Eventuální konzistence V mikroservisách: Každá služba má vlastní databázi Nelze provést ACID transakci přes více služeb Potřebujeme, aby data byla nakonec konzistentní (→ eventual consistency) Pokud nějaký krok selže, musíme předchozí "vrátit zpět" ✅ Řešení: Saga Saga rozděluje jednu velkou transakci na sekvenci malých lokálních transakcí. Každá má: kompenzační operaci (undo), která se spustí při selháni Saga umožňuje udržet konzistenci v mikroservisách bez globálních transakcí. Při chybě se provedou kompenzační kroky – systém se vrátí do konzistentního stavu. Je to na ukor user-expirience, kdy uzivatel mezitim ceka na potvrzeni a anteni objednavky, ale tytyo kroky jsou nutne pro zajisteni spravnsoti systemu Tedy system se nejakou dobu pohybuje v nekon. stavu, saga to mezitim kontroluje a resi, uzivatel je blokovan

Answer 51

Pattern/obalujici sluzba mikroservis, ktera zajisit, ze pri nadmerne zatezi servisy (treba podle poctu pozadavku, CPU vykonu, dostupnych zdroju...) se muze uzavrit a tim prestane dostavat nove pozadavky do urcene doby nebo dokud se sama neotevre Je to uroven nad servisou, ktera hlida jeji poctvou nebo HW zatez a uzivateli ihned vrati zpravu o nedostupnsoti, aniz by user musel cekat na timeout OPEN - servisa funguje, prijima vsechno HALF OPEN - serivsa prijima jen omezeny pocet pozadavku, treba po 1 CLOSED - servisa pretizena, neprijima zadne nove pozadavky Predejde to treba DoS utokum, kdy vytezenou jednu servisu zavreme - tim neni blokovany cely system Muzeme ho pozuit i jako ochranu proti selhavajicim operacim, aby nedoslo ke kaskadovemu zachvatu systemu - v pripade chyby servisy -> odpoji se a resetuje treba

Answer 52

Mechanismus, kdy služby, které jsou volány mají nastavené bezpečnostní limity - např. 1000 volání za sekundu, 1GB za sekundu, 30000 volání za sekundu. Nastavení může být různé podle důležitosti služby. Ostatní volání jsou zahozeny a klientovi se vrací chyba 🧠 Shrnutí větou: Throttling = „Je vás moc, zpomalte.“ Circuit Breaker = „Tahle část je rozbitá, přerušuji spojení.“ 🚦 Throttling Omezuje rychlost požadavků – brání přetížení systému z důvodu příliš mnoha požadavků. 🧠 Účel: Zabránit přetížení služby nebo infrastruktury Chrání zdroje (např. CPU, databázi, API limity) 🔧 Jak funguje: Nastaví se limit (např. 100 požadavků za minutu) Nadlimitní požadavky se: odmítnou (429 Too Many Requests) nebo zpozdí

Answer 53

Back Pressure je strategie, jak automaticky zpomalit přetížení systému tím, že o něm dáme vědět co nejblíž ke zdroji zátěže. Pomáhá zachovat dostupnost celého systému i při lokálním zahlcení. kterým přetížená služba dává vědět předchozí vrstvě (např. klientovi nebo jiné službě), že nestíhá, a tím zpomaluje příchozí tok požadavků. Mikroservisy jsou volány v řetězu. Když jedna z nich nestíhá, chceme: Zastavit/zpomalit volání co nejblíž ke zdroji (např. u API Gateway) Ne až u přetížené služby, protože tam už může být pozdě

Answer 54

pattern, kdy systemA nemeni primo stavy systemuB, ale existuje mezivrstva/fronta zmen, do kterych systemA zapisuje a z teto fronty se pak propisujou do systemuB Event Sourcing = ukládáme všechny události, které změnily stav, a stav získáme jejich přehráním, místo uložení jen aktuálního výsledku. 🏗️ Jak to funguje: Uživatel/akce vyvolá událost (např. OrderCreated, ItemAdded, PaymentProcessed) Událost se uloží do tzv. event store Aktuální stav se rekonstruuje zpětně přehráním všech událostí ✅ Výhody: Výhoda Popis 🕓 Historie Máš kompletní auditní stopu všech změn ↩️ Možnost návratu v čase Lze zrekonstruovat stav k libovolnému bodu ⚡ Integrace s event-driven systémy Události můžeš rovnou použít pro messaging, notifikace 💥 Nenávratné akce jako data Události jsou faktické, neměnné – zdroj pravdy ⚠️ Nevýhody: Nevýhoda Popis 🧩 Složitost rekonstrukce stavu Musíš přehrávat eventy nebo dělat snapshoty ⚙️ Refaktoring eventů je obtížný Staré eventy zůstanou – musíš je umět zpracovat 🧠 Náročnější modelování Vyžaduje změnu přemýšlení – pracuješ s „fakty“, ne s daty

Answer 55

Jedine misto v systemu kde jsou 100% aktualni data

Answer 56

Motivace ● Data čteme výrazně častěji než zapisujeme ● Čtení dat je pomalejší než např. odezvy, které potřebujeme na uživatelském rozhraní. ● Dotaz který čte data je náročný na výkon Řešení => Z místa pravdy dat si dopředu vytvoříme pohled na data, který obsahuje pouze data které potřebujeme. => Data jsou předzpracována do modelu, ve kterém potřebujeme data číst. => Tento pohled používáme pouze na čtení. => Do tohoto pohledu nikdy nezapisujeme přímo, měníme ho až po změně v hlavním místě pravdy - buď současně se zápisem do hlavního místa pravdy nebo se zpožděním (asynchronně nebo v dávce). Podobny princip jako view v databazich, tedy predprivamie slozite query jako virtualni tabulku, z krere rychle cteme Přímý příklad: Máš eventy: OrderCreated, ItemAdded, OrderShipped Materializovaný pohled udržuje aktuální stav objednávky a třeba i součet položek Při příchodu nové události se pohled aktualizuje inkrementálně 🧠 Shrnutí: Event Sourcing je způsob ukládání dat, materializovaný pohled je jejich rychlá předpočítaná verze pro efektivní dotazy.

Answer 57

Materializovaný pohled (view) uchovává aktuální, připravený stav, který je průběžně aktualizován podle příchozích eventů. Díky tomu nemusíš pokaždé přehrávat všechny eventy od začátku, aby ses dostal k aktuálnímu stavu.

Answer 58

CQRS odděluje model pro zápis od modelu na čtení = Command Query Responsibility Segregation Hlavní idea CQRS je: Operace by měla buď změnit stav objektu nebo vrátit výsledek, ale ne obojí najednou - odpovídání na otázku nemění otázku. Když provedeme takovou segregaci, tak budeme mít vždy dva typy operací: ● Commands - mění stav objektu nebo celého systému - tzv. mutátory ● Queries - vrací výsledek a nemění stav objektu Důvody pro CQRS: ● U složité aplikace vede spojení požadavků pro zápis a čtení do jednoho modelu k příliš komplikovanému modelu a komplikovaným dotazům ● Aplikace má zcela odlišné nefunkční požadavky na čtení a zápis - zápis a čtení se navzájem blokují a prodlužují odezvy Jaký je rozdíl mezi eventem a commandem event - co se stalo command - co se ma stat V tomto pripade mame klasicky MVC pattern s jednim modelem. Tento model ale rozdelime na dva modely - query model - pouze na cteni - command model - pouze na upravovani dat

Answer 59

1. Uzivatel v GUI neco klika 2. Poslou se commandy do systemu 3. Commandy se ulozi do queue 4. Command handler (model) je zpracuje a preposle do logiky 5. Command probubla pres aplikacni, servise, repository do DB 6. Tento event se ulozi do Event store - Event sourcing 7. Vyvolany event se nahraje do queue 8. Saga tuto queue kontroluje na konzistenci a pripadn spusti znovu 9. Event na zmenu stavu se propis do materialized view pro rychle cteni 10. Uzivatel z updated view dostane response

Answer 60

1. Obecný princip Dependency Injection (DI) Třída nedělá nové instance svých závislostí sama (nevytváří new přímo uvnitř) Závislosti jsou předávány zvenku (např. konstruktor, setter) Výhoda: volnější vazby mezi třídami, snadnější testování a údržba 2. Špatný přístup – ruční vytváření závislostí (pevné vazby) Třída si vytváří závislosti přímo pomocí new Silná závislost, obtížná náhrada komponent (třeba pro testování) Kód je méně flexibilní a těžko rozšiřitelný Obtížná automatizace a správa závislostí ve větších projektech 3. Lepší přístup – ruční předávání závislostí Závislosti se vytváří externě a předávají do tříd přes konstruktor nebo setter Umožňuje snadnější testování (lze použít mocky) Volnější vazby, lepší modularita Vyžaduje ale stále ruční správu vytváření a předávání objektů 4. Nejlepší přístup – použití DI frameworku (např. Spring) Framework automaticky vytváří a propojuje instance podle konfigurace nebo anotací (@Component, @Autowired) Programátor nemusí řešit manuální předávání ani tvorbu závislostí Zajišťuje správný životní cyklus objektů, singletony, prototypy apod. Velmi usnadňuje testování, rozšiřování a údržbu aplikace Umožňuje snadno měnit implementace a konfigurace bez změny kódu`

OMO Flashcards

(85 cards)