Pytania pomocnicze - INF.04

Należy porównać tempo wzrostu liczby operacji wraz ze wzrostem rozmiaru danych n. Im wolniej rośnie funkcja złożoności, tym algorytm jest zwykle szybszy dla dużych danych.

W O(n) liczba operacji rośnie liniowo, np. 1000 elementów to około 1000 operacji. W O(n²) wzrost jest kwadratowy, czyli dla 1000 elementów może to być około 1 000 000 operacji.

Najczęściej przyjmuje się kolejność: O(1), O(log n), O(n), O(n log n), O(n²), O(n³), O(2^n), O(n!). Im dalej na liście, tym gorzej algorytm skaluje się dla dużych danych.

O(n!) oznacza złożoność silniową, która rośnie bardzo szybko. Takie algorytmy są zwykle niepraktyczne dla większych danych, np. przy sprawdzaniu wszystkich permutacji.

Nie zawsze dla małych danych, ponieważ wpływ mają też stałe czasowe, implementacja i sprzęt. Jednak dla dużych danych algorytm o lepszej złożoności zazwyczaj wygrywa.

Algorytm 4 ma złożoność O(n), czyli liniową. Spośród podanych: O(n), O(n²), O(n³) i O(n!), złożoność O(n) rośnie najwolniej, więc jest najlepszym wyborem.

WPF, czyli Windows Presentation Foundation, służy do tworzenia aplikacji desktopowych dla systemu Windows. Pozwala budować graficzny interfejs użytkownika z użyciem XAML i języków .NET, np. C#.

Angular jest frameworkiem front-endowym do tworzenia aplikacji webowych działających w przeglądarce. Nie jest podstawowym narzędziem do tworzenia klasycznych aplikacji desktopowych.

Aplikacja desktopowa jest instalowana i uruchamiana bezpośrednio w systemie operacyjnym. Aplikacja webowa działa zwykle w przeglądarce i komunikuje się z serwerem.

XAML służy do deklaratywnego opisywania interfejsu użytkownika, np. okien, przycisków, pól tekstowych i układów kontrolek. Logikę działania zwykle zapisuje się w C#.

Xamarin służy głównie do tworzenia aplikacji mobilnych na różne platformy, szczególnie Android i iOS, z użyciem technologii .NET. Nie jest typową odpowiedzią na pytanie o aplikacje desktopowe.

Najczęściej używa się Microsoft Visual Studio. Środowisko to wspiera projektowanie okien, edycję XAML, pisanie kodu C# oraz debugowanie aplikacji.

Po zapisie z przecinkiem w nawiasach kwadratowych, np. `int[,]`. Przecinek oznacza, że tablica ma dwa wymiary.

Tworzy tablicę dwuwymiarową liczb całkowitych o rozmiarze 3 na 3. Taka tablica ma łącznie 9 elementów.

`int[]` oznacza tablicę jednowymiarową, czyli ciąg elementów z jednym indeksem. `int[,]` oznacza tablicę dwuwymiarową, czyli strukturę z dwoma indeksami.

Należy podać dwa indeksy, np. `array[1, 2]`. Pierwszy indeks zwykle oznacza wiersz, drugi kolumnę.

Stos działa według zasady LIFO, czyli ostatni dodany element jest zdejmowany jako pierwszy. W kodzie utworzono tablicę, a nie strukturę typu `Stack`.

Lista w C# jest zwykle tworzona jako `List<int> lista = new List<int>();`. Zapis `int[,]` oznacza tablicę dwuwymiarową, a nie listę.

Ponieważ p3 ma modyfikator public, a więc jest dostępne z dowolnego miejsca, gdzie obiekt jest widoczny. Taki element można odczytywać i modyfikować bezpośrednio przez obiekt.

Modyfikator `public` oznacza, że pole jest dostępne z zewnątrz klasy. Można się do niego odwołać przez `nazwaObiektu.nazwaPola`.

Pola p1 i p2 są oznaczone jako private, więc są dostępne tylko wewnątrz tej samej klasy. Kod głównego programu nie może odwoływać się do nich bezpośrednio.

Pole `private` jest dostępne tylko wewnątrz klasy, w której zostało zadeklarowane. Kod spoza tej klasy nie może odczytać ani zmienić go bezpośrednio.

Protected oznacza dostęp w obrębie danej klasy oraz klas pochodnych. Nie daje on bezpośredniego dostępu z poziomu zwykłego kodu głównego przez obiekt.

`private` jest dostępne tylko w tej samej klasie. `protected` jest dostępne także w klasach pochodnych, czyli dziedziczących po danej klasie.

Private ogranicza dostęp do wnętrza klasy, protected pozwala dodatkowo korzystać z pola w klasach dziedziczących, a public udostępnia pole na zewnątrz. To podstawowe modyfikatory kontroli dostępu.

Nie. Pole `protected` nie jest dostępne bezpośrednio przez `obiekt.pole` z kodu zewnętrznego, chyba że dostęp odbywa się wewnątrz klasy dziedziczącej.

Nie, o dostępności decyduje modyfikator dostępu, a nie typ danych. Typ określa tylko rodzaj przechowywanej wartości.

Tylko `p3`, ponieważ jako jedyne ma modyfikator `public`. Pola `p1` i `p2` są prywatne, a `p4` i `p5` chronione.

Publiczne pola osłabiają hermetyzację, bo pozwalają zmieniać stan obiektu bez kontroli. Częściej stosuje się pola prywatne i udostępnia dostęp przez właściwości lub metody.

Modyfikatory dostępu pozwalają ukrywać szczegóły klasy przed kodem zewnętrznym. Dzięki temu klasa kontroluje, które dane są dostępne publicznie, a które pozostają ukryte.

Można użyć metody lub właściwości, które zwracają albo ustawiają wartość pola. Dzięki temu klasa zachowuje kontrolę nad danymi.

Publiczne pola można dowolnie zmieniać z zewnątrz, co utrudnia kontrolę poprawności danych. Częściej stosuje się prywatne pola i publiczne właściwości lub metody dostępu.

Ponieważ powiadamia interfejs o zmianach w kolekcji, takich jak dodanie, usunięcie lub przestawienie elementów. Dzięki temu kontrolki powiązane z danymi mogą automatycznie się odświeżać.

Ponieważ informuje kontrolki UI o zmianach w kolekcji, np. dodaniu lub usunięciu elementu. Dzięki temu widok może odświeżyć się automatycznie.

List<T> przechowuje dane, ale nie informuje UI o zmianach. ObservableCollection<T> dodatkowo zgłasza zdarzenia zmian kolekcji, co jest kluczowe w aplikacjach z data bindingiem.

Obie kolekcje przechowują elementy, ale `List<T>` nie powiadamia interfejsu o zmianach. `ObservableCollection<T>` zgłasza zmiany kolekcji, dlatego lepiej nadaje się do data bindingu.

Data binding łączy źródło danych z kontrolką interfejsu. Gdy źródłem jest ObservableCollection<T>, zmiany w kolekcji mogą być automatycznie widoczne w UI bez ręcznego odświeżania.

Najczęściej w aplikacjach z wiązaniem danych, np. WPF, Xamarin, MAUI. Często występuje też we wzorcu MVVM.

Nie zawsze. Sama kolekcja informuje o zmianach w swojej strukturze, ale zmiany wewnątrz obiektu wymagają zwykle implementacji INotifyPropertyChanged w tym obiekcie.

Oznacza to, że po dodaniu, usunięciu lub wyczyszczeniu elementów kolekcja wysyła informację o zmianie. Kontrolka powiązana z kolekcją może wtedy zaktualizować wyświetlane dane.

Najczęściej w aplikacjach .NET z interfejsem graficznym, zwłaszcza WPF, Xamarin i MAUI, gdzie używa się wiązania danych i wzorca MVVM.

`ObservableCollection<T>` implementuje interfejs `INotifyCollectionChanged`. To on umożliwia zgłaszanie zmian w strukturze kolekcji.

Te kolekcje nie są przeznaczone do automatycznego powiadamiania interfejsu o zmianach zawartości. Mogą służyć do organizacji danych, ale nie rozwiązują problemu aktualizacji UI.

Nie zawsze. `ObservableCollection<T>` informuje głównie o zmianach w kolekcji, np. dodaniu lub usunięciu elementu. Aby widok reagował na zmianę właściwości obiektu, obiekt powinien implementować `INotifyPropertyChanged`.

`ReadOnlyCollection` służy do udostępniania kolekcji tylko do odczytu. Nie jest przeznaczona do automatycznego powiadamiania interfejsu użytkownika o zmianach.

W MVVM dane z ViewModelu są wiązane z widokiem. `ObservableCollection<T>` pozwala, aby zmiany w danych kolekcji były automatycznie widoczne w interfejsie użytkownika.

Usuwa pliki tymczasowe i wyniki kompilacji projektu, np. z katalogów bin i obj. Nie usuwa kodu źródłowego ani ustawień projektu.

Clean Solution usuwa pliki wygenerowane podczas kompilacji, takie jak pliki wynikowe i tymczasowe. Nie usuwa kodu źródłowego projektu.

Clean Solution czyści wyniki kompilacji, natomiast Build Solution kompiluje projekt i tworzy nowe pliki wynikowe.

Gdy występują problemy z nieaktualnymi plikami po kompilacji, błędy po zmianach konfiguracji albo przed pełną przebudową projektu. To pomaga usunąć stare artefakty.

Rebuild Solution najpierw czyści projekt, a potem buduje go ponownie. Clean Solution wykonuje tylko etap czyszczenia.

Nie. Usuwa tylko pliki wygenerowane podczas budowania projektu, a nie pliki źródłowe, formularze, klasy czy zasoby aplikacji.

Najczęściej są to pliki z katalogów `bin` i `obj`, np. pliki `.exe`, `.dll` oraz pliki pośrednie kompilacji.

Rebuild Solution najpierw czyści projekt, a potem kompiluje go od nowa. Clean Solution wykonuje tylko etap czyszczenia bez ponownej kompilacji.

Nie. Opcja usuwa tylko pliki wygenerowane przez środowisko podczas budowania, a kod źródłowy pozostaje bez zmian.

Bo stare lub uszkodzone pliki pośrednie mogą powodować konflikty z aktualnym kodem. Po ich usunięciu środowisko tworzy je ponownie na podstawie bieżącej wersji projektu.

Warto jej użyć, gdy projekt zachowuje się nieprawidłowo po kompilacji, zawiera stare pliki wynikowe albo trzeba wymusić budowanie od czystego stanu.

Bo najpierw trzeba ustalić, co aplikacja ma robić i jakie problemy rozwiązać. Dopiero na tej podstawie można projektować architekturę, interfejs, bazę danych i testy.

Najpierw trzeba wiedzieć, czego potrzebuje klient i użytkownicy. Bez tego architektura, interfejs i funkcje mogą zostać zaprojektowane niezgodnie z oczekiwaniami.

Obejmuje zebranie potrzeb użytkownika, określenie funkcji systemu, ograniczeń technicznych, oczekiwań biznesowych oraz warunków działania aplikacji.

Wymagania funkcjonalne opisują, co system ma robić. Wymagania niefunkcjonalne opisują jakość działania systemu, np. szybkość, bezpieczeństwo lub dostępność.

Źródłem wymagań mogą być rozmowy z klientem, obserwacja pracy użytkowników, dokumentacja firmy, przepisy prawne, ankiety oraz analiza istniejących systemów.

Architektura powinna wynikać z wymagań. Bez ich poznania łatwo zaprojektować rozwiązanie niedopasowane do potrzeb klienta.

Przypadki testowe tworzy się na podstawie znanych wymagań. Najpierw trzeba ustalić, co system ma robić, a dopiero potem można planować, jak to sprawdzać.

Na podstawie wymagań tworzy się scenariusze i przypadki testowe. Jeśli wymagania są niejasne, trudno sprawdzić, czy aplikacja działa poprawnie.

Architekturę systemu projektuje się po zebraniu i zrozumieniu wymagań. Dzięki temu można dobrać odpowiednie technologie, strukturę modułów i sposób komunikacji elementów systemu.

Może to prowadzić do błędnych funkcji, opóźnień, dodatkowych kosztów i niezadowolenia klienta. Często oznacza też konieczność przebudowy części systemu.

Może powstać aplikacja niezgodna z potrzebami klienta, wymagająca kosztownych poprawek. Często prowadzi to do opóźnień, konfliktów i wzrostu kosztów projektu.

Do grupowania linków w menu używa się elementu <ul> z klasą "navbar-nav". Wewnątrz znajdują się elementy <li class="nav-item"> oraz linki <a class="nav-link">.

Jest kontenerem listy linków nawigacyjnych w navbarze. Wewnątrz umieszcza się elementy <li class="nav-item"> oraz odnośniki <a class="nav-link">.

Navbar służy do tworzenia paska nawigacyjnego strony, czyli menu z linkami do najważniejszych sekcji lub podstron.

Dokumentacja Bootstrap 4 wskazuje użycie listy nieuporządkowanej <ul class="navbar-nav">. Element <ol> oznacza listę uporządkowaną i nie jest tu zgodny z podanym wzorcem.

Dokumentacja Bootstrap 4 wskazuje użycie elementu <ul class="navbar-nav">. Menu nawigacyjne jest tu definiowane jako lista nieuporządkowana, a nie numerowana.

W Bootstrap 4 lista linków powinna być zapisana jako element `<ul>` z klasą `navbar-nav`.

Klasa "navbar-nav" formatuje listę jako część menu nawigacyjnego w pasku navbar. Nadaje odpowiedni układ i styl elementom menu.

Do elementów listy dodaje się klasę .nav-item, a do linków wewnątrz tych elementów klasę .nav-link. Dzięki temu Bootstrap nadaje im odpowiedni wygląd i zachowanie.

Pojedynczy element listy `<li>` powinien mieć klasę `nav-item`.

Pojedynczy element tworzy się jako <li class="nav-item"><a class="nav-link" href="#">Link</a></li>. Klasa "nav-item" dotyczy elementu listy, a "nav-link" samego odnośnika.

Najpierw tworzy się kontener <nav class="navbar ...">, a w nim listę <ul class="navbar-nav">. Następnie dodaje się elementy <li class="nav-item"> z linkami <a class="nav-link">.

Odnośnik `<a>` w menu powinien mieć klasę `nav-link`, dzięki której otrzymuje styl zgodny z Bootstrapem.

Służą do tego klasy typu "navbar-expand-sm", "navbar-expand-md", "navbar-expand-lg" i "navbar-expand-xl". Określają one, od jakiej szerokości ekranowej navbar ma być rozwinięty poziomo.

Określają kolorystykę tekstu i linków w pasku nawigacyjnym. .navbar-dark stosuje się zwykle do ciemnego tła, a .navbar-light do jasnego.

`navbar-dark` stosuje się zwykle na ciemnym tle, aby linki były jasne. `navbar-light` stosuje się na jasnym tle, aby linki były ciemne.

Określają kolorystykę tekstu i linków w navbarze względem tła. "navbar-dark" stosuje jaśniejsze napisy na ciemnym tle, a "navbar-light" ciemniejsze napisy na jasnym tle.

Sterują responsywnością paska nawigacyjnego. Określają, od jakiej szerokości ekranu navbar ma być rozwinięty poziomo, a poniżej tej szerokości może się zwijać.

Określają, od jakiej szerokości ekranu pasek nawigacyjny ma być rozwinięty poziomo. Na mniejszych ekranach może zostać zwinięty.

Można użyć klas tła, takich jak `bg-primary`, `bg-success`, `bg-dark`, `bg-light`, `bg-warning` lub `bg-danger`.

Dziedziczenie polega na tworzeniu nowej klasy na podstawie już istniejącej. Nowa klasa przejmuje pola i metody klasy bazowej oraz może dodawać własne elementy lub zmieniać działanie odziedziczonych metod.

Wtedy, gdy nowa klasa jest szczególnym przypadkiem już istniejącej klasy i ma z nią relację „jest rodzajem”. Pozwala to ograniczyć powielanie kodu i uporządkować model obiektowy.

Dziedziczenie stosuje się, gdy nowa klasa jest bardziej szczegółową wersją istniejącej klasy, np. `Samochod` jako szczególny przypadek klasy `Pojazd`. Relację tę często opisuje się jako „jest rodzajem”.

Dziedziczenie służy tworzeniu klas bardziej szczegółowych na podstawie innych klas. Hermetyzacja dotyczy ukrywania danych i kontrolowania dostępu do pól oraz metod.

Klasa bazowa to klasa ogólna, z której dziedziczą inne klasy. Klasa pochodna to klasa bardziej szczegółowa, która przejmuje elementy klasy bazowej.

Dziedziczenie opisuje relację między klasami i umożliwia rozszerzanie klasy bazowej. Modyfikatory dostępu określają, skąd można korzystać z pól, metod i klas, np. public, private, protected.

Klasa `Zwierze` może zawierać metodę `Oddychaj()`, a klasy `Pies` i `Kot` mogą po niej dziedziczyć. `Pies` i `Kot` są bardziej szczegółowymi typami zwierząt.

Nadpisywanie metod jest często używane w klasie pochodnej, aby zmienić działanie metody odziedziczonej z klasy bazowej. To pozwala dopasować zachowanie bardziej szczegółowej klasy.

Dziedziczenie określa relację między klasami i pozwala tworzyć klasy bardziej szczegółowe. Modyfikatory dostępu, takie jak `public`, `private` czy `protected`, określają widoczność pól i metod.

Asynchroniczność dotyczy sposobu wykonywania operacji w czasie, np. bez blokowania programu. Dziedziczenie dotyczy struktury klas i relacji między nimi, a nie mechanizmu wykonywania zadań.

Asynchroniczność odnosi się do sposobu wykonywania operacji w czasie, np. bez blokowania programu. Nie służy do tworzenia klas bardziej szczegółowych, więc nie opisuje dziedziczenia.

Dziedziczenie dotyczy struktury klas w programowaniu obiektowym. Kod asynchroniczny służy do wykonywania długotrwałych operacji bez blokowania działania programu.

Stałe wartości definiuje się zwykle jako stałe lub pola statyczne, a nie przez tworzenie klas pochodnych. Dziedziczenie ma na celu specjalizację klas, a nie organizację niezmiennych danych.

Stałe służą do przechowywania niezmiennych danych, np. konfiguracji lub wartości liczbowych. Ich użycie nie tworzy relacji klasa bazowa–klasa pochodna.

Klasa pochodna może zmienić działanie metody odziedziczonej z klasy bazowej. Taką zmianę nazywa się nadpisywaniem metody.

Dzięki dziedziczeniu obiekty klas pochodnych mogą być traktowane jak obiekty klasy bazowej. Pozwala to pisać bardziej uniwersalny kod, który działa na wspólnym typie.

Testy wydajnościowe to po angielsku performance testing. Ten termin dotyczy badania szybkości, obciążenia i stabilności działania systemu.

Performance testing to testy wydajnościowe, czyli sprawdzanie, jak aplikacja działa pod względem szybkości, stabilności i zużycia zasobów. Bada się m.in. czas odpowiedzi, przepustowość i zachowanie systemu pod obciążeniem.

Testy funkcjonalne sprawdzają, czy aplikacja działa zgodnie z wymaganiami. Testy wydajnościowe badają, jak szybko i stabilnie działa pod obciążeniem.

Testy jednostkowe sprawdzają poprawność małych fragmentów kodu, np. pojedynczych metod lub funkcji. Testy wydajnościowe oceniają, jak szybko i stabilnie działa aplikacja przy określonym obciążeniu.

Najczęściej mierzą czas odpowiedzi, zużycie zasobów, przepustowość oraz zachowanie systemu przy wielu użytkownikach jednocześnie.

Testy integracyjne sprawdzają współpracę kilku modułów lub komponentów systemu. Ich celem jest wykrycie błędów pojawiających się na styku części aplikacji.

Dokumentacja, narzędzia i ogłoszenia o pracę często używają angielskich terminów. Znajomość takich nazw ułatwia naukę i pracę z materiałami technicznymi.

Testy bezpieczeństwa, czyli security testing, służą do wykrywania podatności aplikacji na ataki. Sprawdza się np. autoryzację, uwierzytelnianie, podatność na SQL injection lub XSS.

Często mylone są z unit testing, integration testing i security testing. Każdy z tych typów bada inny aspekt jakości oprogramowania.

Najczęściej mierzy się czas odpowiedzi, liczbę obsłużonych żądań na sekundę, obciążenie procesora, zużycie pamięci oraz stabilność działania systemu w czasie.

W dokumentacji technicznej i narzędziach programistycznych często używa się terminów angielskich. Trzeba umieć powiązać np. unit testing z testami jednostkowymi, integration testing z integracyjnymi, a performance testing z wydajnościowymi.