„Sznikák vizsga kikérdező” változatai közötti eltérés
a Új kérdések hozzáadása. |
a Új kérdések hozzáadása. |
||
| 322. sor: | 322. sor: | ||
== Egy nem statikus változót célszerű statikus lockkal (osztályszintű zárral) védeni, mert ez hatékonyabb megoldást jelent. == | == Egy nem statikus változót célszerű statikus lockkal (osztályszintű zárral) védeni, mert ez hatékonyabb megoldást jelent. == | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | |||
# Hamis | |||
== C# nyelven a statikus tagváltozókat statikus lock objektummal kell védeni (a lock paraméterében statikus tagváltozót használni), mert nem statikus lock objektum alkalmazása esetén nem teljesülne a kölcsönös kizárás. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
| 421. sor: | 426. sor: | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== Jelölje meg, mely állítások igazak a Pipes and Filters architektúrára. == | |||
{{kvízkérdés|típus=több|válasz=1,2|pontozás=-}} | |||
# Egyik előnye, hogy a filterek tetszőlegesen kombinálhatók. | |||
# Egyik előnye a párhuzamos feldolgozás lehetősége (aktív szűrők esetén). | |||
# Adatnyelő által vezérelt architektúra esetén a szűrő egy ciklusban dolgozza fel a bemenetére érkező adatokat. | |||
== Adottak az alábbi állítások a Document-View (Dokumentum-Nézet) architektúra vonatkozásában. Jelölje meg, mely állítások igazak! | == Adottak az alábbi állítások a Document-View (Dokumentum-Nézet) architektúra vonatkozásában. Jelölje meg, mely állítások igazak! | ||
FIGYELEM, akárhány helyes válasz létezhet! == | FIGYELEM, akárhány helyes válasz létezhet! == | ||
{{kvízkérdés|típus=több|válasz=3,4|pontozás=-}} | {{kvízkérdés|típus=több|válasz=3,4,5|pontozás=-}} | ||
# A Document-View architektúrában a Controller osztály feladata a felhasználói interakciók kezelése. | # A Document-View architektúrában a Controller osztály feladata a felhasználói interakciók kezelése. | ||
# A Document-View architektúrában a dokumentumban külön tagváltozót vezetünk be minden egyes nézetre. | # A Document-View architektúrában a dokumentumban külön tagváltozót vezetünk be minden egyes nézetre. | ||
# A Document-View architektúrában a dokumentumnak van egy vagy több olyan művelete, mellyel az állapotát a nézetek bármikor le tudják kérdezni. | # A Document-View architektúrában a dokumentumnak van egy vagy több olyan művelete, mellyel az állapotát a nézetek bármikor le tudják kérdezni. | ||
# A Document-View architektúrában a nézetnek van egy hivatkozása a dokumentumára. | # A Document-View architektúrában a nézetnek van egy hivatkozása a dokumentumára. | ||
# A dokumentumnak van egy listája a beregisztrált nézeteire. | |||
== Adott az alábbi Pipes and filters architektúra, filter megvalósítás pszeudokód. Melyik forgatókönyv felel meg a fenti kódnak? <br> == | == Adott az alábbi Pipes and filters architektúra, filter megvalósítás pszeudokód. Melyik forgatókönyv felel meg a fenti kódnak? <br> == | ||
| 476. sor: | 488. sor: | ||
== Adottak az alábbi állítások különböző tervezési mintákkal kapcsolatban! Jelölje meg, mely állítások igazak. FIGYELEM, akárhány helyes válasz létezhet! == | == Adottak az alábbi állítások különböző tervezési mintákkal kapcsolatban! Jelölje meg, mely állítások igazak. FIGYELEM, akárhány helyes válasz létezhet! == | ||
{{kvízkérdés|típus=több|válasz=1,2,4|pontozás=-}} | {{kvízkérdés|típus=több|válasz=1,2,4,5,6,7|pontozás=-}} | ||
# Az Adapter tervezési mintában a Client osztálynak van egy Target típusú mutatója vagy hivatkozása az Adapter osztály egy példányára. | # Az Adapter tervezési mintában a Client osztálynak van egy Target típusú mutatója vagy hivatkozása az Adapter osztály egy példányára. | ||
# Az Adapter tervezési mintában az Adapter osztály a Target osztályból származik (vagy a Target interfészt implementálja). | # Az Adapter tervezési mintában az Adapter osztály a Target osztályból származik (vagy a Target interfészt implementálja). | ||
# Az Adapter minta Object Adapter változatában a Adaptee implementálja a Target interfészt (vagy a Target osztályból származik). | # Az Adapter minta Object Adapter változatában a Adaptee implementálja a Target interfészt (vagy a Target osztályból származik). | ||
# Az Adapter tervezési mintában (legalábbis annak object adapter változatában) az Adapter (adaptáló) osztály – amennyibe lehetősége van rá – továbbítja (delegálja) a kéréseket az Adaptee (adaptálandó) osztálynak. | # Az Adapter tervezési mintában (legalábbis annak object adapter változatában) az Adapter (adaptáló) osztály – amennyibe lehetősége van rá – továbbítja (delegálja) a kéréseket az Adaptee (adaptálandó) osztálynak. | ||
# Bár az Adaptert tervezési mintának tekintik, valójában ez egy idióma, mert csak egy adott programozási nyelv kontextusában (Java) használatos. | |||
# A minta lehetővé teszi olyan osztályok együttműködését, melyek egyébként az inkompatbilis interfészeik miatt nem tudnának együttműködni. | |||
# Az Adapter mintában - pontosabban annak Object Adapter változatában - az Adapter osztály tartalmaz egy mutatót vagy referenciát az adaptálandó (Adaptee) osztályra. Az Adapter osztály a műveleteinek megvalósításában felhasználja az adaptálandó (Adaptee) osztály szolgáltasait. | |||
== Egy online bolt alkalmazásban a feladata egy a bevásárlókosár lezárását (szállítási cím kezelése, megerősítés, fizetés) kezelő osztály megvalósítása. Az osztálynak több fizetési módot (pl. bankkártya, átutalás) kell támogatnia, és könnyen kiterjeszthetőnek kell lennie újabb fizetési módokkal. Mely tervezési mintát alkalmazná a megvalósítás során? == | == Egy online bolt alkalmazásban a feladata egy a bevásárlókosár lezárását (szállítási cím kezelése, megerősítés, fizetés) kezelő osztály megvalósítása. Az osztálynak több fizetési módot (pl. bankkártya, átutalás) kell támogatnia, és könnyen kiterjeszthetőnek kell lennie újabb fizetési módokkal. Mely tervezési mintát alkalmazná a megvalósítás során? == | ||
| 492. sor: | 507. sor: | ||
# Factory method | # Factory method | ||
# Adapter | # Adapter | ||
# Abstract factory | |||
== Az egyik tervezési minta azt javasolja, hogy a származtatás/komplex hierarchia helyett az osztály viselkedésének különböző aspektusait kompozícióval tegyük paraméterezhetővé. Melyzik ez a tervezési minta? == | |||
{{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | |||
# Composite | |||
# Memento | |||
# Observer | |||
# Strategy | |||
# Singleton | |||
# Proxy | |||
# Factory method | |||
# Adapter | |||
# Abstract factory | |||
== A feladatunk egy ablakozós keretrendszer kifejlesztése. A keretrendszerben bevezetünk egy absztrakt Window osztályt, melyből a keretrendszerre épülő alkalmazások fejlesztésekor le kell származtatni és meg kell valósítani az alkalmazásspecifikus ablak viselkedését. A keretrendszerben egy WindowManager osztályt is megvalósítunk, melynek felelőssége bizonyos feltételek esetén a Window leszármazott objektumok létrehozása, tárolása és menedzselése. A felületelemek vonatkozásában (pl. Button, Dropdown, stb.) az alkalmazásfejlesztőknek nem kell a keretrendszer osztályaiból leszármaztatni. Mely tervezési mintát a legcélszerűbb választani a Window leszármaztatott osztály keretrendszeren belüli létrehozására? Olyan megoldást válasszo, mely a legkevesebb új osztály bevezetésével jár. == | |||
{{kvízkérdés|típus=egy|válasz=7|pontozás=-}} | |||
# Composite | |||
# Memento | |||
# Observer | |||
# Strategy | |||
# Singleton | |||
# Proxy | |||
# Factory method | |||
# Adapter | |||
# Abstract factory | |||
== Feladatunk egy olyan alkalmazás megtervezése, mely szervezetek osztályainak hierarchiáját képes egy diagramon megjeleníteni. Egy szervezeten belül lehetnek osztályok és személyek, az osztályokon belül további osztályok és személyek, tetszőleges mélységben. Mely tervezési mintát a legcélszerűbb választani a probléma modellezésére? == | |||
{{kvízkérdés|típus=egy|válasz=8|pontozás=-}} | |||
# Prototype | |||
# Memento | |||
# Observer | |||
# Strategy | |||
# Singleton | |||
# Proxy | |||
# Factory method | |||
# Composite | |||
# Abstract factory | # Abstract factory | ||
| 512. sor: | 564. sor: | ||
== Adottak az alábbi állítások a C# nyelvi eszközökről (property, delegate, event és attribute). Jelölje meg, hogy mely állítások igazak. == | == Adottak az alábbi állítások a C# nyelvi eszközökről (property, delegate, event és attribute). Jelölje meg, hogy mely állítások igazak. == | ||
{{kvízkérdés|típus= | {{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | ||
# A C# property-k segítségével deklaratív módon tudunk információt csatolni többek között tagváltozókhoz, metódusokhoz és osztályokhoz. | # A C# property-k segítségével deklaratív módon tudunk információt csatolni többek között tagváltozókhoz, metódusokhoz és osztályokhoz. | ||
# C# eventre feliratkozni az "=" operátorral lehet. | # C# eventre feliratkozni az "=" operátorral lehet. | ||
# C# event | # C# event tagváltozóra helyes példa a következő: <code>event int CompareDelegate(object a, object b);</code> | ||
# C# event tag értéke null abban az esetben, ha nincs az eseményre feliratkozó. | # C# event tag értéke null abban az esetben, ha nincs az eseményre feliratkozó. | ||
== Adottak az alábbi állítások a C# nyelvi eszközökről (property, delegate, event és attribute). Jelölje meg, hogy mely állítások igazak. == | |||
{{kvízkérdés|típus=több|válasz=2,5|pontozás=-}} | |||
# A C# attribútumok definiálásakor egy get és egy set blokkot adunk meg, melyek az attribútum lekérdezésekor, illetve beállításakor hívódnak meg (nem kötelező mindkettőt megadni). | |||
# C# delegate objektumot át lehet adni függvényparaméterként is. | |||
# C# delegate típus definícióra szintaktikailag helyes példa a következő: <code>event int CompareDelegate(object a, object b);</code> | |||
# C# event események vonatkozásában a -= operátor valamennyi előfizetőt leiratkoztat. | |||
# Egy delegate objektum/változó több metódusra is hivatkozhat. | |||
== Adottak az alábbi állítások a C# nyelvi eszközökről (property, delegate, event és attribute). Jelölje meg, hogy mely állítások igazak. == | |||
{{kvízkérdés|típus=több|válasz=1,2,3,5|pontozás=-}} | |||
# A C# attribútumok segítségével deklaratív módon tudunk információt csatolni többek között tagváltozókhoz, metódusokhoz és osztályokhoz. | |||
# C# eventre feliratkozni a "+=" operátorral lehet. | |||
# C# delegate típus definícióra szintaktikailag helyes példa a következő: <code>delegate int CompareDelegate(object a, object b);</code> | |||
# C# események elsütésekor a beregisztrált eseménykezelő függvények a hatékonyság érdekében külön szálakon hívódnak meg. | |||
# Egy osztály több eseményt is publikálhat. | |||
== Jelöje meg, hogy a .NET Framework esetében mely állítások igazak! == | == Jelöje meg, hogy a .NET Framework esetében mely állítások igazak! == | ||
{{kvízkérdés|típus=több|válasz= | {{kvízkérdés|típus=több|válasz=2,4,5|pontozás=-}} | ||
# Az alábbi forgatókönyv a klasszikus DLL hell probléma legjellemzőbb esetének jó definíciója: egy alkalmazás telepítésekor hiányzik egy vagy több DLL a célkörnyezetben, mely szükséges lenne az alkalmazás futásához, így az alkalmazás nem működik megfelelően (mert a szükséges DLL-ek telepítéséről a felhasználó nem gondoskodott). | # Az alábbi forgatókönyv a klasszikus DLL hell probléma legjellemzőbb esetének jó definíciója: egy alkalmazás telepítésekor hiányzik egy vagy több DLL a célkörnyezetben, mely szükséges lenne az alkalmazás futásához, így az alkalmazás nem működik megfelelően (mert a szükséges DLL-ek telepítéséről a felhasználó nem gondoskodott). | ||
# A .NET IL kód processzor-és architektúrafüggetlen. | |||
# A .NET IL kód nagyon hatékony, mert a processzorok közvetlenül tudják futtatni. | # A .NET IL kód nagyon hatékony, mert a processzorok közvetlenül tudják futtatni. | ||
# Az azonosított (erős névvel aláírt) szerelvények lehetővé teszik, hogy a több kiadó/fejlesztőcég azonos fájlnévvel és azonos verzióval telepítsen .NET szerelvényeket. | # Az azonosított (erős névvel aláírt) szerelvények lehetővé teszik, hogy a több kiadó/fejlesztőcég azonos fájlnévvel és azonos verzióval telepítsen .NET szerelvényeket. | ||
# A privát szerelvényeket egyszerűbb telepíteni, mint az azonosított szerelvényeket. | # A privát szerelvényeket egyszerűbb telepíteni, mint az azonosított szerelvényeket. | ||
== | == Az alábbiak közül melyik definiálja a legjobban a klasszikus DLL hell problémát? == | ||
{{kvízkérdés|típus=egy több|válasz=|pontozás=-}} | {{kvízkérdés|típus=több|válasz=3|pontozás=-}} | ||
# | # Egy alkalmazás telepítésekor hiányzik egy vagy több DLL a célkörnyezetben, mely szükséges lenne az alkalmazás futásához, így az alkalmazás nem működik megfelelően (mert a szükséges DLL-ek telepítéséről a felhasználó nem gondoskodott). | ||
# | # Egy alkalmazás telepítésekor felteszi a célkörnyezetbe az általa használt DLL-eket egy közös mappába. Ezeket a DLL-eket további alkalmazások is használják, melyek közül az egyik eltávolításakor (uninstall) a DLL-ek egy része eltávolításra kerül, így az alkalmazásunk működésképtelenné válik. | ||
# | # Egy alkalmazás telepítésekor felteszi a célkörnyezetbe az általa használt DLL-eket egy közös mappába. Később, egy másik alkalmazás a telepítésekor felülírja a korábban telepített alkalmazás egyik DLL-jét egy másik verzióval. A korábban telepített alkalmazás ezzel az újonnan telepített DLL-lel nem működik megfelelően. | ||
# | # Egy alkalmazás telepítésekor felülírja az operációs rendszer bizonyos DLL-jeit, mely következtében az operációs rendszer instabillá válik. | ||
== Jelölje meg, mely állítások igazak a szálkezelésre .NET környezetben! == | |||
{{kvízkérdés|típus=több|válasz=2,3,5,6|pontozás=-}} | |||
# A ManualResetEvent osztályt jellemzően arra használjuk, hogy adott erőforrás elérésére vonatkozó kölcsönös kizárást valósítunk meg a segítségével. | |||
# A ManualResetEvent osztályt jellemzően arra használjuk, hogy hatékonyan tudjunk várakozni más szál jelzésére. | |||
# A Mutex előnye a lock utasítással szemben, hogy különböző folyamatok szálai között is használható. | |||
# Az x++ művelet .NET környezetben atomi (és így szálbiztos), ha az x típusa int (32 bites). | |||
# A ReaderWriterLock használata akkor célszerű használni kölcsönös kizárásra, ha a védett erőforrást gyakran olvassuk és ritkán írjuk. | |||
# Az x=10 művelet .NET környezetben atomi (és így szálbiztos), ha az x típusa int (32 bites). | |||
== Adott az alábbi Pipes and filters (csővezeték) architektúra filter megvalósítás pszeudokód:<br> | |||
<code> | |||
void Write(Data data)<br> | |||
{<br> | |||
Data processedData = ProcessData(data);<br> | |||
nextFilter.Write(processedData);<br> | |||
}</code> == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Adatforrás által vezérelt. | |||
# Adatnyelő által vezérelt. | |||
# Csővezeték által vezérelt. | |||
# Aktív szűrő által vezérelt. | |||
# Passzív szűrő által vezérelt. | |||
== Adott az alábbi Pipes and filters (csővezeték) architektúra filter megvalósítás pszeudokód:<br> | |||
<code> | |||
Data Read()<br> | |||
{<br> | |||
Data data = prevFilter.Read();<br> | |||
Data processedData = ProcessedData(data); | |||
return processedData;<br> | |||
}</code> == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Adatforrás által vezérelt. | |||
# Adatnyelő által vezérelt. | |||
# Csővezeték által vezérelt. | |||
# Aktív szűrő által vezérelt. | |||
# Passzív szűrő által vezérelt. | |||
== Adottak az alábbi állítások a kétrétegű, valamint a háromrétegű architektúrával kapcsolatban! jelölje meg, mely állítások igazak! == | |||
{{kvízkérdés|típus=több|válasz=2,3,4|pontozás=-}} | |||
# A kétrétegű architektúrát ma már soha nem használjuk a háromrétegű architektúra előnyei miatt. | |||
# A kétrétegű architektúra lehetővé teszi, hogy adott üzleti logikához egyszerűen készítsünk különböző frontend alkalmazásokat, úgy mint desktop, web, mobil. | |||
# A háromrétegű architektúra lehetővé teszi, hogy adott üzleti logikához egyszerűen készítsünk különböző frontend alkalmazásokat, úgy mint desktop, web, mobil. | |||
# A háromrétegű architektúra előnye a kétrétegűvel szemben, hogy az adatbázis sémája a kliensalkalmazástól függetlenül egyszerűbben átszervezhető. | |||
== Melyek a Singleton tervezési minta megvalósításának kellékei? Jelölje meg a helyes válaszokat! == | |||
{{kvízkérdés|típus=több|válasz=2,3,6|pontozás=-}} | |||
# Globális változó | |||
# Statikus tagváltozó | |||
# Statikus metódus vagy statikus property | |||
# Virtuális metódus | |||
# Absztrakt metódus | |||
# Védett konstruktor | |||
# Védett destruktor | |||
# Globális pointer vagy referencia | |||
== Egy alkalmazásban a CommHandler osztály felelős egy külső rendszer adott szolgáltatásainak eléréséért. A CommHandler osztályt a felhasználói/kliensei egy interfész típusként (ICommHandler) kapják meg és használják. Egy új, jogosultság hozzáférést ellenőrző objektumot szeretnénk beékelni az osztály és a felhasználói közé olyan módon, hogy az osztályt és a felhasználóit a lehető legkevésbé érintse a változtatás. Mely tervezési mintát a legcélszerűbb választani a probléma megoldására? == | |||
{{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | |||
# Factory method | |||
# Abstract method | |||
# Composite | |||
# Proxy | |||
# Observer | |||
# Adapter | |||
# Singleton | |||
# Strategy | |||
== Egy kilens objektum egy nagy erőforrásigényű objektumot használ (pl. egy szövegszerkesztő nagyméretű képeket), a nagy erőforrásigényű objektumra, azonban nincs mindig szükség, igény esetén tölthető be. A betöltés előtt is szükség van azonban a nagy erőforrásigényű objektum bizonyos paramétereire. Mely tervezési mintát használná a probléma megoldására? == | |||
{{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | |||
# Factory method | |||
# Abstract method | |||
# Composite | |||
# Proxy | |||
# Observer | |||
# Adapter | |||
# Singleton | |||
# Strategy | |||
== A feladatunk egy keretrendszer megtervezése. A keretrendszerben létre kell hozni egy adott típusú objektumot, de annak típusát nem ismerjük, mert az csak a keretrendszerre épülő alkalmazás esetén dől el. Mely tervezési mintát használná a probléma megoldására? == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Factory method | |||
# Abstract method | |||
# Composite | |||
# Proxy | |||
# Observer | |||
# Adapter | |||
# Singleton | |||
# Strategy | |||
== Adottak az alábbi állítások a Memento tervezési mintával kapcsolatban. Jelölje meg a helyes válaszokat! == | |||
{{kvízkérdés|típus=több|válasz=2,3,6,7|pontozás=-}} | |||
# A mintában a Memento osztálynak van olyan művelete, melynek egy Originator objektumot lehet átadni. Ez a művelet az Originatorban levő adatok alapján a Memento állapotát állítja. | |||
# A mintában az Originator osztálynak van olyan művelete, mellyel egy Memento objektumot lehet kérni. Ez a Memento objektum az Originator állapotának másolatát tárolja. | |||
# A mintában az Originator osztálynak van olyan művelete, melynek egy Memento objektumot lehet átadni. Ez a művelet a Mementoban levő adatok alapján az Originator állapotát állítja. | |||
# A mintában a CareTaker Originator objektumokat tárol. | |||
# A mintában az Originator osztályt becsomagoljuk egy Memento objektummal, a Memento tárolja az Originator állapotát. | |||
# A minta elérhetővé teszi a külvilág számára az objektum belső állapotát az egységbezárás megsértése nélkül (vagyis anélkül, hogy publikussá tennénk az állapotát.) | |||
# A mintát használhatjuk az Undo funkció megvalósítására. | |||
== Composite tervezési minta fontosabb osztályai a következők: Client, Component, Composite (összetett) és Leaf (levél). Jelölje meg a helyes választ! == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# A Composite osztálynak van egy Component gyűjteménye. | |||
# A Component osztálynak van egy gyűjteménye Composite, valamint egy másik gyűjteménye Leaf objektumokból. | |||
# A Component osztálynak van egy közös gyűjteménye (heterogén kollekció) Composite és Leaf objektumokból. | |||
# A Composite osztálynak van egy gyűjteménye Component, valamint egy másik gyűjteménye Leaf objektumokból. | |||
# A Client osztálynak van egy gyűjteménye Composite, valamint egy másik gyűjteménye Leaf objektumokból. | |||
== Adott az alábbi C# nyelvű .NET alkalmazás kódrészlet, melyben a .NET beépített List<T> osztályát használjuk (és nem lehet helyette más osztályt használni).<br><code> | |||
class DataProcessor<br> | |||
{<br> | |||
List<int> items = new List<int>();<br> | |||
static object syncObject = new object();<br> | |||
public int GetItem(int index) {<br> | |||
lock (syncObject) { return items[index]; }<br> | |||
}<br> | |||
public void AddItem(int n) {<br> | |||
lock (syncObject) { items.Add(n); }<br> | |||
}<br> | |||
} </code>== | |||
{{kvízkérdés|típus=egy|válasz=3|pontozás=-}} | |||
# A megoldás jelen formájában nem szálbiztos (thread safe), de azzá tehető, ha a syncObject tagváltozó elől a static kulcsszót eltávolítjuk. | |||
# A megoldás szálbiztos (thread safe) és nem tehető triviális módon hatékonyabbá. | |||
# A megoldás szálbiztos (thread safe), de a syncObject tagváltozó előtti a static kulcsszó eltávolításával hatékonyabbá tehető. | |||
# A megoldás szálbiztos (thread safe), de a lock utasítások eltávolításával hatékonyabbá tehető. | |||
== Adott az alábbi C# nyelvű .NET alkalmazás kódrészlet, mely egymásba ágyazott zárakat tartalmaz. | |||
<code><br> | |||
class Program<br> | |||
{<br> | |||
static object syncObject = new object();<br> | |||
static void Main(string[] args)<br> | |||
{<br> | |||
lock (syncObject) {<br> | |||
f();<br> | |||
}<br> | |||
}<br> | |||
static void f()<br> | |||
{<br> | |||
lock (syncObject) {<br> | |||
Console.WriteLine("Hello!");<br> | |||
}<br> | |||
}<br> | |||
}<br> | |||
</code> == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Az alkalmazás kiírja a "Hello!" szöveget a konzolra. | |||
# Az alkalmazás soha nem fejezi be a futását, mert az f() függvényben a lock utasításnál már egy a Main függvényben zárolt objektumra próbál zárolni (holtpont alakul ki). | |||
# Az f() függvényben a lock utasítás kivételt dob annak érdekében, hogy ne alakuljon ki holtpont. | |||
== Az alábbiak közül mely adatok teszik egyedivé az erős névvel ellátott (azonosított) .NET szerelvényeket? Jelölje meg a helyes választ! == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Név, fejlesztő cég privát kulcsa, verzió, opcionális kultúra információ | |||
# Név, fejlesztő cég nyilvános kulcsa, verzió, opcionális kultúra információ | |||
# Név, verzió, pcionális kultúra információ | |||
# Név, fejlesztő cég nyilvános kulcsa, verzió, digitális aláírás, opcionális kultúra információ | |||
== | == Adottak az alábbi állítások különböző tervezési mintákkal kapcsolatban! Jelölje meg a helyes állításokat! == | ||
{{kvízkérdés|típus= | {{kvízkérdés|típus=több|válasz=1,2|pontozás=-}} | ||
# | # A Proxy tervezési mintában a Proxy objektum egy transzparens csomagoló az eredeti objektum körül, mely szabályozhatja az eredeti objektumhoz való hozzáférést. | ||
# | # Az Adapter minta - pontosabban annak Object Adapter változata - az objektum becsomagolásával teszi lehetővé, hogy az objektum interfésze kompatibilis legyen azzal, amit a kliens/környezete elvár. | ||
# | # A Singleton minta globális hozzáférést biztosít egy osztály egyetlen objektumához, és ezt az objektumot egy globális változóban tárolja. | ||
== | == .NET környezetben egy szálban hatékonyan kell várakozni arra, hogy egy másik szál valamilyen adatot előkészítse a számára. Milyen szinkronizációs konstrukciót a legcélszerűbb erre használni? == | ||
{{kvízkérdés|típus=egy | {{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | ||
# | # lock | ||
# | # synchronized | ||
# | # Mutex | ||
# | # ManualResetEvet | ||
# ReaderWriterLock | |||
# Semaphore | |||
== | == Adottak az alábbi állítások a Strategy tervezési mintával kapcsolatban. Jelölje meg, mely állítások igazak! == | ||
{{kvízkérdés|típus= | {{kvízkérdés|típus=több|válasz=3,5|pontozás=-}} | ||
# | # A minta globális függvénypointereket vezet be annak érdekében, hogy a kliens szemszögéből az általa használt algoritmusok szabadon kicserélhetőek legyenek. | ||
# | # A minta lehetővé teszi, hogy egy adott osztály viselkedésének különböző aspektusai paraméterezhetőek legyenek. Mindezt elsődlegesen úgy éri el, hogy magából az osztályból számos leszármazottat vezet be (minden viselkedés kombinációhoz egyet). | ||
# | # A minta lehetővé teszi, hogy egy adott osztály viselkedésének különböző aspektusai paraméterezhetőek legyenek. Mindezt úgy, hogy minden aspektushoz egy osztályhierarchiát vezet be. | ||
# | # A mintában a Context (vagy Client) osztályban van egy vagy több mutató/referencia, mely típusa egy vagy több konkrét algoritmus implementáció. | ||
# A mintában a Context (vagy Client) osztályban van egy vagy több mutató/referencia, mely típusa egy vagy több algoritmus interfész/absztrakció. | |||
== | == Adottak az alábbi állítások különböző tervezési mintákkal kapcsolatban% Jelölje meg, mely állítások igazak. == | ||
{{kvízkérdés|típus= | {{kvízkérdés|típus=több|válasz=1,3,4|pontozás=-}} | ||
# | # A Document-View architektúra az Observer tervezési minta egy speciális alkalmazása. | ||
# | # A Document-View architektúra a Composite tervezési minta egy speciális alkalmazása. | ||
# | # Az Adapter minta lehetővé teszi olyan osztályok együttműködését, melyek egyébként az inkompatbilis interfészeik miatt nem tudnának együttműködni. | ||
# | # Az Adapter mintában - pontosabban annak Object Adapter változatában - az Adapter osztály tartalmaz egy mutatót vagy referenciát az adaptálandó (Adaptee) osztályra. Az Adapter osztály a műveleteinek megvalósításában felhasználja az adaptálandó (Adaptee) osztály szolgáltasait. | ||
== == | == == | ||
| 565. sor: | 793. sor: | ||
# | # | ||
# | # | ||
# | # | ||
== == | == == | ||
| 572. sor: | 800. sor: | ||
# | # | ||
# | # | ||
# | # | ||
== == | == == | ||
| 579. sor: | 807. sor: | ||
# | # | ||
# | # | ||
# | # | ||
== == | == == | ||
| 586. sor: | 814. sor: | ||
# | # | ||
# | # | ||
# | # | ||
== == | == == | ||
| 593. sor: | 821. sor: | ||
# | # | ||
# | # | ||
# | # | ||
== == | == == | ||