Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Wzorce programowe > Antywzorce > Flashcards

Antywzorce Flashcards

1
Q

Antywzorce – metodyczne

A
  • Copypasteryzm
  • Programowanie przez permutację
  • Złoty młotek
  • Silver bullet
  • Czynnik nieprawdopodobieństwa
  • Ponowne odkrywanie koła
  • Odkrywanie kwadratowego koła
  • U mnie działa
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Copypasteryzm

A

ang. Copy and paste programming – zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Programowanie przez permutację

A

ang. programming by permutation – próba rozwiązania problemu przez konsekwentne zmiany w kodzie (bez przemyślenia sprawy i zrozumienia problemu), do czasu aż program zadziała.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Złoty młotek

A

ang. golden hammer – faworyzowanie jednej technologii w celu rozwiązania wszystkich problemów, również tych, dla których istnieją znacznie lepsze metody.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Silver bullet

A

założenie, że sprawdzone rozwiązanie techniczne musi być zawsze skuteczne przy rozwiązaniu znacznie większego problemu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Czynnik nieprawdopodobieństwa

A

ang. improbability factor – założenie, że nie jest prawdopodobne, aby znany błąd się ujawnił w działaniu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Ponowne odkrywanie koła

A

ang. Reinventing the wheel – rozwiązywanie na nowo problemu dla którego jest już optymalne rozwiązanie.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Odkrywanie kwadratowego koła

A

ang. Reinventing the square wheel) – rozwiązywanie problemu w zły sposób, podczas gdy istnieją skuteczne i sprawdzone rozwiązania. Na przykład tworzenie własnego systemu bazodanowego, zamiast wykorzystania istniejących darmowych rozwiązań, z dużym prawdopodobieństwem lepszych niż sami jesteśmy w stanie stworzyć.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

U mnie działa

A

ignorowanie problemu powstałego na pewnej instalacji systemu ponieważ problem ten nie wystąpił na innej instalacji.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Antywzorce – w projektowaniu

A
  • Inwersja abstrakcji
  • Błotna bryła
  • Petrochemia
  • System, który gra i tańczy
  • System z wyścigami
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Inwersja abstrakcji

A

ang. Abstraction inversion: Nieudostępnianie użytkownikom zaimplementowanej funkcjonalności, której potrzebują, przez co muszą ją zaimplementować ponownie używając funkcji wyższego poziomu.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Błotna bryła

A

ang. Big ball of mud: Dotyczy systemu o trudnej do wyodrębnienia i zrozumienia strukturze. Modyfikowanie takiego systemu jest ryzykowne, gdyż nie sposób jest przewidzieć skutków zmian, kod przypomina spaghetti.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Petrochemia

A

ang. Gas factory: Zbyt skomplikowany, uciążliwie drobiazgowy projekt systemu lub funkcjonalność.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

System, który gra i tańczy

A

ang Stovepipe system: Ciężko serwisowalny system zbudowany z komponentów niepowiązanych ze sobą (funkcjonalnie).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

System z wyścigami

A

Race hazard: System, w którym źle zorganizowano obsługę zdarzeń i jego działanie jest zależne od ich kolejności.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Antywzorce – w programowaniu

A
  • Przypadkowa złożoność
  • Akcja na odległość
  • Blind faith
  • Boat anchor
  • Caching failure
  • Ukrywanie błędów
  • Sterowanie wyjątkami
  • Hard code
  • Magic number
  • Spaghetti code
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Przypadkowa złożoność

A

ang. Accidental complexity – wprowadzanie niepotrzebnej złożoności kodu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Akcja na odległość

A

Action at a distance – niespodziewana interakcja pomiędzy oddzielonymi częściami systemu (np. poprzez zmienne globalne)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Blind faith

A

niesprawdzanie rezultatów napisanego kodu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Boat anchor

A

zachowanie części systemu która już nie jest potrzebna

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Caching failure

A

pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Ukrywanie błędów

A

ang. Error hiding – przechwytywanie komunikatu o błędzie w celu ukrycia go przed użytkownikiem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Sterowanie wyjątkami

A

ang. Coding by exception – używanie konstrukcji językowych służących do zarządzania błędami (wyjątkami) w celu implementacji właściwej logiki programu (np. zwracanie wyniku z funkcji przez wyrzucenie wyjątku)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Hard code

A

wstawianie do kodu programu wartości, które mogłyby być potencjalnie modyfikowalne przez użytkownika

25
Q

Magic number

A

użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu. Przykładem wystąpienia tego antywzorca jest użycie stałej, której nazwa nic nie mówi o jej przeznaczeniu, a komentarze nie wyjaśniają sensu jej użycia. W efekcie tego działania posiadamy w kodzie magiczną liczbę, której przeznaczenia nikt nie zna.

26
Q

Spaghetti code

A

kod, który na skutek używania złożonych struktur językowych (duże zagnieżdżenie instrukcji warunkowych, instrukcje goto itd.) jest nieczytelny i trudny do modyfikacji.

27
Q

Antywzorce – w projektowaniu obiektowym

A
  • Boski obiekt
  • Object
  • Jo-jo
  • Anemiczny model dziedziny
  • Sequential Coupling
  • Singletonizm
28
Q

Boski obiekt

A

ang. God object: Umieszczenie zbyt wielu funkcji w jednym komponencie (klasie). Obarczenie jej nadmierną odpowiedzialnością, co powoduje problemy w utrzymaniu jej kodu i wyodrębnieniu funkcjonalności.

29
Q

Object

A

ang. cesspool: Ponowne wykorzystywanie obiektów, których zachowanie zmienia się przy kolejnym użyciu. Może to być wynikiem braku automatycznego przywracania stanu obiektu przy zwracaniu go do puli obiektów.

30
Q

Jo-jo

A

ang. Yo-yo problem: Sytuacja, kiedy funkcjonalność jest rozłożona pomiędzy głęboką hierarchię dziedziczących się klas. Aby zrozumieć działanie programu programista musi przechodzić w tę i z powrotem pomiędzy definicjami klas.

31
Q

Anemiczny model dziedziny

A

ang. Anemic Domain Model: W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy.

32
Q

Sequential Coupling

A

Klasa wymaga, aby jej metody były wywoływane w określonej kolejności.

33
Q

Singletonizm

A

ang. Singletonitis: Niepotrzebne używanie wzorca singleton

34
Q

SOLID

A

akronim zaproponowany prze Roberta Martina opisujący pięć podstawowych założeń programowania obiektowego

35
Q

S

A

SRP - Single Responsibility Principle - Zasada jednej odpowiedzialności

  • Nie powinno być więcej niż jednego powodu do modyfikacji klasy.
  • Zasada opisana przez Toma DeMarco i Meilira Page-Johnesa – określali ją jedność/spójność (ang. cohese) i definiowali jako funkcjonalność łączącą elementy pojedynczego modułu.
  • Odpowiedzialność – przyczyna zmiany.

Klasa powinna mieć tylko jedną odpowiedzialność (nigdy nie powinien istnieć więcej niż jeden powód do modyfikacji klasy).

36
Q

O

A

OCP - Open-Closed Principle - Zasada otwarte/zamknięte

  • Składniki oprogramowania (klasy, moduły, funkcje, …) powinny być otwarte na rozbudowę ale zamknięte na modyfikacje.
  • Zmiany w programie nie powinny pociągać za sobą wprowadzania całej sekwencji modyfikacji w modułach zależnych. Rozbudowa powinna wymagać dodania nowego kodu bez modyfikacji istniejącego.
  • Jak umożliwić rozbudowę bez modyfikacji kodu? Abstrakcja.
  • Alternatywnie można użyć wzorca metody szablonowej (Template method).
37
Q

L

A

LSP - Liskov Substitution Principle - Zasada podstawienia Liskov

  • Musi istnieć możliwość zastępowania typów bazowych ich podtypami.
  • Barbara Liskov opisała tę zasadę w 1988 roku: „Oczekujemy czegoś na kształt następującej właściwości podstawiania: jeżeli dla każdego obiektu o1 typu S istnieje taki obiekt o2 typu T, że zachowanie wszystkich programów P zdefiniowanych na bazie typu T nie zmienia się, jeśli obiekt o1 zastąpimy obiektem o2, typ S jest podtypem typu T.”
  • Prostymi słowami: Korzystanie z funkcji klasy bazowej musi być możliwe również w przypadku podstawienia instancji klas pochodnych.
  • Dziedziczenie jest relacją IS-A (taksonomii, dziedziczenia hierarchicznego).
  • Obiekt klasy kwadrat nie musi być prostokątem, ponieważ na poziomie zachowania się różnią
38
Q

I

A

ISP - Interface segregation Principle - Zasada segregacji interfejsów

  • Zasada ma na celu wyeliminowanie nieporęcznych i zbyt rozbudowanych interfejsów.
  • Do tej grupy zaliczamy nadmiernie rozbudowane i niespójne interfejsy. Należy je podzielić na mniejsze grupy metod. Każda z tych grup będzie odpowiadać za obsługę innego zbioru klientów. Oznacza to, że część klientów będzie korzystała z jednej grupy metod, a pozostałe aplikacje klienckie z pozostałych grup. Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny.

Klient nie powinien być zmuszony do zależności od metod, których nie używa

39
Q

D

A

DIP - Depedency Inversion Principle - Zasada odwrócenia zależności

  • Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.
  • Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.
  • Moduły wysokopoziomowe powinny zawierać ważne decyzje strategiczne i modele biznesowe aplikacji. Te moduły w największym stopniu decydują o funkcjonowaniu aplikacji. Jeśli będą zależeć od modułów niskiego poziomu, to zmiany będą wpływać na moduły wysokopoziomowe i wymuszać zmianę działania całej aplikacji.
40
Q

Nazewnictwo

A
  • Używaj nazw przedstawiających intencje
  • Unikaj dezinformacji
  • Twórz nazwy, które da się wymówić
  • NIE UŻYWAJ notacji węgierskiej (sz, psz, m_)
  • Im krótszy zakres działania zmiennej tym krótsza zmienna
  • Im większy zakres działania zmiennej tym dłuższa zmienna
  • Nazwy publiczne - krótkie
  • Nazwy prywatne - długie i opisowe
41
Q

Części mowy

A
  • Rzeczowniki - klasy, interfejsy, zmienne
  • Czasowniki - metody, funkcje
  • Przymiotniki – enum
  • Predykat - zmienne typu boolean, metody zwracające boolean
42
Q

Metody (funkcje)

A

• Pierwsza zasada konstruowania funkcji:
Funkcje powinny być małe
• Druga zasada konstruowania funkcji:
Funkcje powinny być mniejsze niż są

  • Ile linii kodu? 4? 10? 20?
  • Jeśli metoda jest długa to ukrywa wewnątrz klasę
  • Max 3 argumenty
  • Metoda ma robić jedną rzecz i robić ją dobrze
  • Nie przesyłamy zmiennych typu boolean jako argument
  • Publiczne metody - krótkie nazwy
  • Prywatne metody - długie opisowe nazwy
43
Q

Refaktoryzacja kodu (wykorzystanie wzorców projektowych)

A

• Proces wprowadzania zmian w programie, w wyniku których zasadniczo nie zmienia się funkcjonalność.

Celem refaktoryzacji jest więc nie wytwarzanie nowej funkcjonalności, ale utrzymywanie odpowiedniej,
wysokiej jakości organizacji systemu.

• Wykorzystanie wzorców projektowych:
- nowy kod tworzony od zera
- modyfikacja istniejącego kodu (refaktoryzacja)
• Czym jest refaktoryzacja?
- Przekształceniem zmieniającym strukturę kodu nie zmieniającym jego działania.
Testy jednostkowe!

44
Q

Piramida refaktoryzacji

A 
I: Czytalny kod, czyli formatowanie, nazwy, uproszczenie warunków, jasne etapy procesu
II: Ekstrahowanie metod
III: SOLID
IV: Wzorce projektowe
V: Architektura
45
Q

Refaktoryzacja - co można zrobić

A
  • zwiększenie abstrakcji:
  • – enkapsulacja atrybutów (gettery, settery),
  • – uogólnianie typów (dzielenie i współużytkowanie kodu),
  • dzielenie na logiczne części,
  • wyodrębnianie metod,
  • mniejsze fragmenty łatwiejsze do zrozumienia,
  • lepsze nazwy (klas, metod, zmiennych),
46
Q

Zaciemnianie kodu/obfuskacja

A
  • ang. Obfuscation
    • Sytuacja odwrotna do refaktoringu.
    • Służy utrudnieniu analizy kodu źródłowego.
    • NIE ZABEZPIECZA!!! jedynie wymusza użycie większych zasobów
47
Q

Model warstwowy aplikacji

A

• W związku ze wzrostem złożoności systemów informatycznych nastąpiła potrzeba separacji komponentów. Umożliwia to uproszczenie procedur konfiguracji i zarzadzania (administracji). Zoptymalizowało to również etap syntezy czyli kompozycji całości systemu z oddzielnie projektowanych i dedykowanych elementów.
• Warstwy komunikują się ze sobą za pomocą określonego protokołu.
- w architekturze warstwowej aplikacji mogą to być interfejsy, klasy abstrakcyjne lub bezpośrednie odwołania do pól i metod
- w architekturze warstwowej systemów informatycznych są to najczęściej gniazda sieciowe i pamięć współdzielona

48
Q

Najczęściej wyodrębniane warstwy:

A
  • warstwa logiki biznesowej,
  • warstwa prezentacji,
  • warstwa dostępu do danych.
  • warstwa autentyfikacji i autoryzacji,
  • warstwa danych (warstwa zarządzania danymi),
49
Q

Zalety modelu warstwowego

A
  • dekompozycja systemu na niezależne komponenty, możliwe do oddzielnej analizy,
  • łatwość podmiany komponentu z dowolnej warstwy na inny, wykorzystujący ten sam protokół,
  • możliwość scalenia kolejnych warstw w jedną, z zachowaniem protokołu do następnej i poprzedniej warstwy,
  • możliwość rozdzielenia jednej warstwy w wiele, z zachowaniem protokołu do następnej i poprzedniej warstwy,
  • rozdzielenie systemów do zadań dedykowanych,
  • rozdzielenie mocy obliczeniowej między warstwy,
  • zapewnienie rozwiązań redundantnych (nadmiarowych, zapasowych).
50
Q

Wady modelu warstwowego

A
  • trudny do implementacji w istniejących już systemach nie projektowanych z uwzględnieniem modelu warstwowego,
  • potrzeba obudowania funkcjonalności w dodatkowy interfejs,
  • utrudnienia związane z zapewnieniem zgodności wstecznej podczas rozbudowy interfejsu.
51
Q

Model warstwowy aplikacji – architektura aplikacji

A

• MVC (Model View Controller),
• HMVC (Hierarhical…),
• PAC (Presentation, Abstraction, Control)
+ wzorce projektowe

52
Q

Model warstwowy aplikacji – architektura systemów informatycznych

A
  • architektura jednowarstwowa (1-tier)
  • architektura dwuwarstwowa (2-tier)
  • architektura wielowarstwowa (multi-tier, n-tier)
53
Q

Architektura jednowarstwowa (1-tier)

A

• samodzielny system lub pojedyncza aplikacja

54
Q

Architektura dwuwarstwowa (2-tier)

A
  • program napisany w języku ogólnego przeznaczenia (C#, Python, PHP) komunikujący się z bazą danych (SQL, Oracle)
  • przeglądarka internetowa współpracująca z serwerem HTTP, oferującym statyczne strony
55
Q

Architektura wielowarstwowa (multi-tier, n-tier)

A
  • przeglądarka internetowa współpracująca z serwerem aplikacji (HTTP ze wsparciem PHP, ASP, JSP, XSQL lub innych narzędzi), korzystającym z bazy SQL - klasyczny model trójwarstwowy,
  • hierarchiczny system synchronizacji czasu - NTP
56
Q

Wzorce dla aplikacji webowych - MVC

A
  • Model – reprezentacja problemu bądź logiki aplikacji
  • View – odpowiada za wyświetlanie części modelu przez interfejs użytkownika
  • Controller – odbiera dane wejściowe od użytkownika i na ich podstawie aktualizuje model i odświeża widoki
57
Q

MVC - wykorzystane wzorce proste

A
  • kompozyt – tworzenie i praca z zagnieżdżonymi widokami
  • obserwator – powiadamianie widoku o zmianie modelu
  • strategia – obsługa reakcji na zdarzenia wejściowe w gestii konkretnych kontrolerów
  • metoda wytwórcza – domyślny kontroler
  • dekorator – dynamicznie rozszerza widoki
58
Q

MVC - pokrewne wzorce

A

MTP (model-template-view),
MVP (model-view-presenter),
HMVC (hierarchical modelview-controller)

59
Q

Wzorce dla aplikacji webowych - PAC

A

• Wzorzec podobny do MVC
• PAC
- Presentation – formatuje dane graficzne/dźwiękowe
- Abstraction – odbiera i przetwarza dane
- Control – kontroluje przepływ danych i informacji pomiędzy pozostałymi 2 komponentami
• Używany w postaci hierarchicznej struktury agentów. Agenty komunikują się między sobą za pomocą kontrolerów.
• W odróżnieniu od MVC prezentacja (widok) i abstrakcja (model) są kompletnie izolowane.

Wzorce programowe (9 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions