POWP
Design Patterns Quiz
Test your knowledge of design patterns in software engineering with this comprehensive quiz. Whether you're a student, a teacher, or a professional looking to sharpen your skills, this quiz will provide insightful questions on various design patterns.
- 38 thought-provoking questions
- Multiple choice and checkbox formats
- Covers popular patterns like Singleton, Proxy, and Observer
Wzorzec Decorator
Pozwala na dodanie nowej funkcjonalności do instancji klas podczas działania programu
Jest wzorcem behawioralnym
Jest wzorcem strukturalnym
Z uwagi na elastyczność osłon zwiększa ryzyko błędów
Wzorzec Proxy umożliwia
Dynamiczne dodawanie funkcjonalności
Kontrolę dostępu do obiektów
Powiadamianie innych obiektów o zmianie stanu
Definiowanie rodziny wymiennych algorytmów w postaci klas
Konsekwencje zastosowania wzorca Bridge
Daje on niezależność pomiędzy klasami, które reprezentują abstrakcje, a klasami, które je implementują
Utrudnia ukrycie implementacji przed klientem
Abstrakcja I jej implementacja mają tę samą hierarchie klas
Obiekty abstrakcji mogą zmieniać implementacje bez wpływu na klienta
Zastosować Template Method można w celu
Zaimplementowania algorytmu jako jednej metody w klasie
Umożliwienia zdefiniowania wybranych kroków algorytmu
Zaimplementowania algorytmu jako jednej klasy
Zaimplementowania każdego kroku danego algorytmu w osobnych podklasach
Observer umożliwia
Skupienie całej odpowiedzialności wewnątrz jednej instancji klasy
Pozwala skupić odpowiedzialność w jednej klasie, nadzorującej interakcje innych obiektów
Ukrycie za jednolitym interfejsem wielu różnych implementacji
Oddzielić obiekt od znajomości obiektów od niego zależnych
Command stosuje się po to, aby
Uprościć obiekt klienta
Dokonać hermetyzacji wywołań metod w obiekcie
Dodać nowe metody do kodu klienta
Zredukować liczbę użytych instrukcji typu if, switch, w kodzie
W jaki sposób wzorzec Command może być zastosowany w programowaniu obiektowym?
Delegację utworzenia obiektu użytkowego do metody tworzącej
Hermetyzowanie wywołania metody w obiekcie
Traktowanie "wywołania metody obiektu" jako pełnoprawnego obiektu
Rozdystrybuowanie operacji tak, aby każda implementacja odnosiła się do innego typu kompozycji
Visitor
Pełni tę samą rolę co wzorzec Proxy
Umożliwia zdefiniowanie operacji dla złożonej hierarchii obiektów, bez konieczności "zanieczyszczania" klas tych obiektów dodatkową odpowiedzialnością
Ma na celu umożliwienie współpracy klas o niekompatybilnych interfejsach
Jest wzorcem behawioralnym
Mediator umożliwia
Ukryć za jednolitym interfejsem wielu różnych implementacji
Wymusić określoną liczbę instancji klasy
Uprościć implementacje I wielokrotne użycie wybranych klas
Zarządzanie interakcją innych obiektów
Singleton umożliwia
Ukrycie za jednolitym interfejsem wielu różnych implementacji
Skupienie odpowiedzialności w jednej klasie, nadzorującej interakcje innych obiektów
Oddzielenie obiektu od znajomości obiektów od niego zależnych
Skupienie całej odpowiedzialności wewnątrz jednej instancji klasy
Wzorce kreacyjne
Ułatwiają proces tworzenia obiektów gdy wymaga on podejmowania decyzji
Utrudniają proces tworzenia obiektów gdy nie wymaga on podejmowania decyzji
Ułatwiają proces tworzenia obiektów gdy nie wymaga on podejmowania decyzji
Utrudniają proces tworzenia obiektów gdy wymaga on podejmowania decyzji
Dla jakich strategii tworzenia Abstract Factory zapewnia wsparcie
Rozproszone tworzenie
Wybór klasy pochodnej
Tworzenie według zasady Open Create Principle
Ponowne użycie obiektów w cache
Dependency Injection polega na
Implementacji mechanizmu umożliwiającego dodawanie operacji do istniejącej hierarchii
Zastosowaniu metody undo I rollback
Dynamicznym tworzeniu zachowania obiektów
Usuwaniu bezpośrednich zależności pomiędzy komponentami na rzecz architektury typu plug-in
Które wzorce dotyczą organizacji interakcji między obiektami (tzw. Wzorce rewalizujące)
Bridge I Facade
Strategy I Template Method
Mediator I Observer
Adapter I Singleton
Zdanie - 'Komponenty wyższych warstw nie powinny zależeć od niższych. Obydwa powinny zależeć od abstrakcji' - określa następującą zasadę projektowania
Injection of Control
Dependency Inversion Principle
Interface Segregation Principle
Dependency Injection
Do łączenia ze sobą istniejących obiektów lub klas służą wzorce
Strukturalne
Współbieżności
Rozszerzeń
Behawioralne
Zasady strategii projektowania SOLID stosowanej w metodykach zwinnych to
Zasada pojedynczej odpowiedzialności (Single Responsibility Principle)
Zasada otwarcia-zamknięcia (Open Closed Principle)
Zasada zamienialności Barbary Liskov (Liskov Substitution Principle)
Zasada przedkładanie kompozycji nad dziedziczenie (Composition over Inheritance Principle)
Podstawowe techniki realizacji Dependency Injection, to
Constructor injection
Intrusive injection
Setter injection
Class injection
Wybierz konsekwencje zastosowania Facade
Klient nie musi znać klas fasady
Zmiany w klasach, znajdujących się za fasadą, muszą być uwzględnione w klasach klienta
Wykorzystanie fasady upraszcza klasy klienta, gdyż przesuwa zależności z klas klienta do fasady
Klient nie musi znać klas za fasadą
Wzorzec projektowy Facade
Rozszerza interfejs zbyt prostego systemu
Upraszcza lub porządkuje interfejs złożonego systemu
Nie ma związku ze złożonością interfejsu
Pozostawia interfejs systemu bez zmian
Które wzorce pomagają, gdy projekt zawiera wiele rozbudowanych instrukcji switch
Adapter, facade
Factory method, singleton
Visitor, decorator
State, strategy
Wzorzec Strategy rozwiązuje następujący problem
Potrzebę wydania żądania do obiektór bez żadnej wiedzy na temat odbiorcy I operacji
Potrzebę hermetyzacji zachowania klasy bez korzystania z kompozycji
Potrzebę budowy oprogramowania zorientowanego-obiektowo ze zminimalizowaną liczbą zależności
Potrzebę możliwości przywracania poprzednieop stanu obiektu
Konsekwencje zastosowania wzorca Command
Pozwala na odseparowanie obiektu wywołującego polecenie od obiektu go wykonującego
Upraszcza dodawanie nowych poleceń, gdyż nowe polecenia nie zrywają ani nie modyfikują żadnych, istniejących już zależności
Redukcja liczby użytych instrukcji typu if, switch w kodzie
Pozwala na hermetyzowanie wywołania metody w obiekcie
Wzorzec Command umożliwia
Traktowanie „wywołnia metody obiektu” jako pełnoprawnego obiektu
Delegację utworzenia obiektu użytkowego do metody tworzącej
Hermetyzowanie wywołania metody w obiekcie
Rozdystrybuowanie operacji tak, aby każda implementacja odnosiła się do innego typu kompozycji
Wybierz, z niżej wymienionych, konsekwencje zastosowania Strategy:
Zachowanie obiektów klienta może być zdefiniowane za pomocą obiektów
W niektórych przypadkach może przyspieszyć działanie obiektów klienta, gdyż nie muszą one dokonywać wyboru zachowania
Pozwala ograniczyć ilość instrukcji typu if, switch w kodzie
Zwiększa złożoność obiektów klienta, gdyż wymusza odpowiedzialność za wybór zachowania
Zadaniem wzorców rozszerzeń jest
Uczynić proces rozwijania kody bardziej czytelnym, prostym I dostępnym
Tworzenie nowych obiektów inaczej niż tylko przez wywoływanie konstruktorów klas
Organizacja, zarządzanie I łączenie zachowań
Centralizacja, delegowanie I ograniczanie odpowiedzialności zwykłych obiektów
W jakich wzorcach unika się konstrukcji „new” uznając ją za szkodliwą
Bridge
Template Method
Abstract Factory
Prototype
Najbardziej dynamicznym z wzorców kreacyjnych jest
Prototype
Template Method
Abstract Factory
Singleton
Zaletą zastosowania wzorca Prototype jest to, że
Zachowanie obiektów klienta może być określone za pomocą obiektów PrototypeBuilder
Ułatwia implementacje I utrzymanie innych obiektów
Klient ma określony, spójny zestaw metod, który prototyp określa
Logika nowej operacji jest umieszczona w jednej spójnej klasie prototypu
Zasadę podstawienia (LSP) można sformułować następująco
Instancja klasy nie powinna funkcjonować jako instancja jej klasy nadrzędnej
Klient może używać obiektów dziedziczących po klasie bazowej bez dokładnej znajomości tych obiektów
Wiele małych interfejsów jest lepsze od jednego wielkiego
Każda jednostka powinna mieć wiedzę jedynie o innych jednostkach blisko skojarzonych
Zasadę „segregacji interfejsów” (Interface Segregation Principle) można sformułować następująco
Szczegóły powinny być uzależnione od abstrakcji
Klienci nie powinni być zależni od interfejsów, z których nie korzystają
Gdzie dwóch się bije tam trzeci korzysta
Powinien być tylko jeden powód zmiany dla klasy
Wybierz, z niżej wymienionych, konsekwencje zastosowania Composite
Dowolna klasa hierarchii wzorca Composite może być dzieckiem obiektu kompozytowego
Komponenty nie implementują żadnych, unikalnych operacji, wszystkie operacje są zaimplementowane w klasie najogólniejszej
Klient nie musi znać hierarchii komponentów
Nie trzeba udostępniać wspólnego interfejsu do wszystkich obiektów w danej hierarchii
Konsekwencje zastosowania adapterów to
Klient I adoptowany komponent pozostają niezależne
Ułatwiają zrozumienie aplikacji
Wywierają negatywny wpływ na wydajność aplikacji
Klient I adoptowany komponent poprzez zastosowanie adaptera stają się od siebie zależne
Sygnatura definiuje
Fragment reprezentacji obiektu
Nazwę interfejsu
Parametry I nazwę operacji
Wartość identyfikującą obiekt
Wzorzec projektowy Facade
Rozszerza interfejs zbyt prostego systemu
Upraszcza lub porządkuje interfejs złożonego systemu
Nie ma związku ze złożonością interfejsu
Pozostawia interfejs systemu bez zmian
{"name":"POWP", "url":"https://www.quiz-maker.com/QPREVIEW","txt":"Test your knowledge of design patterns in software engineering with this comprehensive quiz. Whether you're a student, a teacher, or a professional looking to sharpen your skills, this quiz will provide insightful questions on various design patterns.38 thought-provoking questionsMultiple choice and checkbox formatsCovers popular patterns like Singleton, Proxy, and Observer","img":"https:/images/course1.png"}