POWP

A visually engaging illustration depicting software design patterns, including shapes and arrows representing various design methodologies, with a modern and tech-themed background.

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

38 Questions10 MinutesCreated by CodingCheetah742

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