Wstęp: Od kodu do systemu

Umiemy już pisać klasy, dziedziczyć i obsługiwać błędy. Jednak samo znanie składni nie wystarczy, by zbudować duży, sprawny system. Potrzebujemy planu.

W tej części zajmiemy się procesem projektowania. Odpowiemy na pytania:

• Jakie klasy stworzyć?
• Jak te klasy powinny ze sobą współpracować?
• Jak uniknąć bałaganu w kodzie?

Na końcu omówimy wymagania dotyczące projektu zaliczeniowego.

Złożoność to Twój największy wróg

Małe programy można pisać "z głowy". Gdy system rośnie, brak struktury prowadzi do "kodu spaghetti" – sytuacji, w której zmiana jednej rzeczy psuje dziesięć innych.

Dobre projektowanie obiektowe (OOD) zapewnia:

• Łatwość utrzymania: Szybkie znajdowanie i naprawianie błędów.
• Rozszerzalność: Dodawanie nowych funkcji bez przepisywania całego programu.
• Czytelność: Inni programiści (lub Ty za miesiąc) zrozumieją, co kod robi.

Keep It Simple, Stupid

Najprostsze rozwiązania są zazwyczaj najlepsze. Nie komplikuj systemu na zapas.

• Nie twórz klas "na wszelki wypadek".
• Pisz metody, które robią tylko jedną rzecz.
• Pamiętaj: kod jest częściej czytany niż pisany.

Don't Repeat Yourself

Unikaj powtarzania tego samego kodu w różnych miejscach. Jeśli kopiujesz i wklejasz kod, robisz to źle.

• Wspólną logikę wynosimy do metod klasy bazowej.
• Używamy funkcji pomocniczych.
• Zmienne konfiguracyjne trzymamy w jednym miejscu.

Dzięki temu zmianę wprowadzasz tylko raz, a nie w dziesięciu plikach.

You Ain't Gonna Need It

Nie implementuj funkcjonalności, dopóki nie są one faktycznie potrzebne.

• Przewidywanie przyszłości często się nie sprawdza.
• Nadmiarowy kod to nadmiarowe błędy do naprawienia.
• Skup się na dostarczeniu tego, co jest wymagane "tu i teraz".

Pięć zasad czystego kodu

SOLID to akronim pięciu zasad, które pomagają tworzyć elastyczne systemy. Dla początkujących najważniejsza jest pierwsza z nich.

1. S: Single Responsibility (Jedna odpowiedzialność)
2. O: Open/Closed (Otwarte-Zamknięte)
3. L: Liskov Substitution (Zastępowalność Liskov)
4. I: Interface Segregation (Segregacja interfejsów)
5. D: Dependency Inversion (Inwersja zależności)

Przyjrzyjmy się im bliżej w uproszczony sposób.

Klasa powinna mieć tylko jeden powód do zmiany

Złe podejście: Klasa User, która przechowuje dane użytkownika, wysyła e-maile i zapisuje się do bazy danych.

Dobre podejście:

• User – tylko dane.
• EmailService – wysyłka poczty.
• UserRepository – obsługa bazy danych.

Otwarte na rozbudowę, zamknięte na modyfikacje

Powinieneś móc dodawać nową funkcjonalność bez zmieniania istniejącego, przetestowanego kodu.

Przykład: Zamiast instrukcji if typ == "kot": ... wewnątrz funkcji, stwórz wspólną klasę bazową Zwierze i pozwól nowym gatunkom nadpisywać ich zachowania.

Podklasa musi zachowywać się jak klasa bazowa

Jeśli funkcja oczekuje obiektu Ptak, musi działać poprawnie po przekazaniu jej obiektu Wrobel.

Uwaga na pułapkę: Strus jest ptakiem, ale nie lata. Jeśli klasa Ptak ma metodę lec(), to Strus nie powinien z niej dziedziczyć wprost, bo złamie logikę programu.

Lepiej mieć wiele małych interfejsów niż jeden duży

Nie zmuszaj klas do implementowania metod, których nie potrzebują.

Przykład: Zamiast jednego interfejsu Pracownik z metodami programuj() i sprzataj(), stwórz dwa oddzielne. Programista nie musi wiedzieć, jak profesjonalnie myć podłogi.

Zależ od abstrakcji, nie od konkretu

Wysokopoziomowe moduły nie powinny zależeć od niskopoziomowych.

Złe: Laptop bezpośrednio tworzy obiekt DyskSSD.

Dobre: Laptop wymaga dowolnego obiektu, który spełnia wymagania PrzechowywanieDanych. Dzięki temu łatwo podmienisz SSD na dysk w chmurze bez zmiany kodu laptopa.

Praktyczna rada

Jako początkujący, nie staraj się stosować wszystkich zasad SOLID na siłę od pierwszego dnia. To przychodzi z doświadczeniem.

Zacznij od SRP (Jedna klasa = Jedno zadanie). To najprostsza droga do czystszego kodu.

# SRP - Dobry przykład
class Logger:
    def log(self, message):
        print(f"LOG: {message}")

class Calculator:
    def add(self, a, b):
        return a + b

Jak obiekty ze sobą "rozmawiają"?

W systemie obiekty rzadko działają w izolacji. Musimy określić, w jaki sposób są ze sobą połączone.

Główne typy relacji:

• Dziedziczenie: Relacja typu "jest" (Pies jest zwierzęciem).
• Kompozycja/Agregacja: Relacja typu "ma" (Samochód ma silnik).
• Asocjacja: Zwykłe używanie (Lekarz leczy pacjenta).

Własność a współpraca

Oba terminy oznaczają, że jeden obiekt ma w sobie drugi, ale różnią się silą związku.

• Kompozycja (silna): Obiekt podrzędny nie może istnieć bez nadrzędnego. Jeśli zniszczysz Budynek, zniszczysz też jego Pokoje.
• Agregacja (słaba): Obiekty mogą istnieć niezależnie. Jeśli rozwiążesz Zespol, jego Czlonkowie nadal istnieją i mogą dołączyć do innego zespołu.

Silnik w samochodzie

class Silnik:
    def start(self): print("Wrrrum!")

class Samochod:
    def __init__(self):
        self.silnik = Silnik() # Kompozycja

    def jedz(self):
        self.silnik.start()
        print("Jedziemy!")

auto = Samochod()
auto.jedz()

Zauważ: Silnik jest tworzony wewnątrz Samochodu.

Piłkarz w klubie

class Pilkarz:
    def __init__(self, nazwisko):
        self.nazwisko = nazwisko

class Klub:
    def __init__(self, nazwa):
        self.nazwa = nazwa
        self.zawodnicy = []

    def dodaj_zawodnika(self, p):
        self.zawodnicy.append(p)

lewy = Pilkarz("Lewandowski")
fcb = Klub("FC Barcelona")
fcb.dodaj_zawodnika(lewy) # Agregacja

Złota zasada OOD

Dziedziczenie jest bardzo silnym związkiem i często prowadzi do problemów przy zmianach. Kompozycja jest bardziej elastyczna.

Zamiast tworzyć PracownikProgramista przez dziedziczenie z Pracownik i Programista, lepiej stworzyć obiekt Pracownik, który ma pole rola przechowujące obiekt typu Programista.

Luźna współpraca

Relacja typu: "Obiekt A używa obiektu B".

Przykład: Klient składa Zamowienie. Klient nie "ma w sobie" zamówienia jako stałego elementu swojej budowy, a zamówienie nie jest klientem. Po prostu w pewnym momencie dochodzi do interakcji.

Unified Modeling Language

Zanim zaczniesz pisać kod, warto narysować schemat klas. UML to standard rysowania takich "map drogowych" programu.

Klasa w UML: Prostokąt podzielony na trzy części:

1. Nazwa klasy.
2. Atrybuty (pola).
3. Metody.

Oznaczenia widoczności

W UML używamy symboli, by określić, kto ma dostęp do pól i metod:

• + (plus): Publiczne (dostępne dla wszystkich).
• - (minus): Prywatne (tylko wewnątrz klasy).
• # (hasz): Chronione (dla klasy i potomków).

Pamiętaj, że w Pythonie to tylko konwencja (np. _atrybut), ale na diagramie warto to zaznaczyć.

Jak rysować połączenia?

• Dziedziczenie: Linia ciągła z pustym trójkątem.
• Kompozycja: Linia z zamalowanym rombem po stronie "właściciela".
• Agregacja: Linia z pustym rombem.
• Asocjacja: Zwykła linia, ew. ze strzałką kierunku.

Gdzie rysować diagramy?

Nie musisz instalować drogiego oprogramowania:

• draw.io (diagrams.net): Darmowe, online, proste.
• PlantUML / Mermaid: Piszesz tekst, a generator robi z tego obrazek.
• Kartka i ołówek: Często najszybszy sposób na pierwszy szkic.

Zrozum problem, zanim zaproponujesz rozwiązanie

Projektowanie zaczyna się od rozmowy z "klientem" lub analizy tekstu zadania. Szukamy:

• Rzeczowników: To zazwyczaj kandydaci na klasy (Student, Książka, Kurs).
• Czasowników: To zazwyczaj kandydaci na metody (zapisz_na_kurs, oddaj_ksiazke).

Gotowe rozwiązania częstych problemów

Programiści przed Tobą rozwiązali już tysiące podobnych problemów. Wzorce projektowe to sprawdzone przepisy na architekturę.

Dzielimy je na:

• Kreacyjne: Jak mądrze tworzyć obiekty (np. Singleton, Fabryka).
• Strukturalne: Jak składać obiekty w większe całości (np. Dekorator, Adapter).
• Behawioralne: Jak obiekty mają się komunikować (np. Obserwator, Strategia).

Krok po kroku

1. Analiza: Co program ma robić?
2. Projekt: Jakie klasy i jak połączone? (UML)
3. Implementacja: Pisanie kodu (Python).
4. Testowanie: Czy działa zgodnie z założeniami?
5. Refaktoryzacja: Poprawianie struktury kodu bez zmiany jego działania.

Sprzątanie po sobie

Pierwsza wersja kodu rzadko jest idealna. Refaktoryzacja to proces ulepszania napisanego już kodu.

• Zmienianie nazw zmiennych na czytelniejsze.
• Wyciąganie powtarzających się fragmentów do metod.
• Upraszczanie skomplikowanych pętli i warunków.

Pomóż innym zrozumieć Twój kod

Używaj docstringów (potrójne cudzysłowy) pod definicją klasy i metody.

class Robot:
    """Klasa reprezentująca robota sprzątającego."""
    
    def sprzataj(self):
        """Uruchamia sekwencję sprzątania pokoju."""
        print("Sprzątam...")

Podział na pliki

Nie trzymaj wszystkiego w jednym pliku main.py. Podziel klasy tematycznie.

• models.py – definicje klas.
• utils.py – funkcje pomocnicze.
• gui.py / cli.py – interfejs użytkownika.

Trzy filary sukcesu

1. Zasady (SOLID): Wyznaczają kierunek.
2. Relacje (Kompozycja): Budują strukturę.
3. Wzorce: Dostarczają gotowe plany.

Praktyka czyni mistrza – najlepiej nauczysz się projektować, realizując projekt zaliczeniowy.

Czy wszystko jasne?

Zanim przejdziemy do szczegółów projektu zaliczeniowego, zastanów się, czy rozumiesz różnicę między kompozycją a dziedziczeniem oraz dlaczego SRP jest tak ważne.

Zastosowanie wiedzy w praktyce

Celem projektu jest stworzenie kompletnej aplikacji obiektowej w Pythonie, która rozwiązuje konkretny problem.

Czego będę szukał w Waszym kodzie?

• Poprawnego użycia klas i obiektów.
• Zastosowania dziedziczenia i polimorfizmu tam, gdzie ma to sens.
• Czystego kodu (zgodnego z PEP 8).
• Obsługi wyjątków i walidacji danych.
• Zapisywania stanu do pliku (serializacja).

Co musi się znaleźć w kodzie?

1. Minimum 3-4 współpracujące ze sobą klasy.
2. Użycie dziedziczenia (przynajmniej jeden poziom).
3. Wykorzystanie metod magicznych (np. __str__).
4. Obsługa błędów (bloki try...except).
5. Trwałość danych: JSON, Pickle lub plik CSV.
6. Prosty interfejs tekstowy (menu w konsoli).

Jak spakować zadanie?

Projekt powinien składać się z:

• Plików .py z kodem źródłowym.
• Krótkiej dokumentacji (plik README.md lub PDF) opisującej:
  • Co program robi?
  • Diagram klas (obrazek lub opis).
  • Instrukcja uruchomienia.

Inspiracja 1

Klasy: Ksiazka, Uzytkownik, Biblioteka.

Funkcje: Wypożyczanie, oddawanie, wyszukiwanie po tytule, zapisywanie bazy czytelników do JSON.

Dziedziczenie: KsiazkaPapierowa i Ebook jako potomkowie Pozycja.

Inspiracja 2

Klasy: Bohater, Bron, Przeciwnik, Walka.

Funkcje: Atakowanie, zdobywanie doświadczenia, ekwipowanie przedmiotów.

Dziedziczenie: Klasy postaci (Mag, Wojownik) dziedziczące po Bohater.

Inspiracja 3

Klasy: Transakcja, Kategoria, Budzet.

Funkcje: Dodawanie wydatków/przychodów, generowanie raportów miesięcznych, eksport do CSV.

Za co można dostać 5?

• Poprawność: Wszystko działa "od strzału".
• Architektura: Logiczny podział na klasy.
• Wyjątki: Program nie "wywala się" po wpisaniu litery zamiast cyfry.
• Kreatywność: Własny, ciekawy pomysł wykraczający poza standardowe przykłady.
• Estetyka kodu: Czytelne nazwy, docstringi, brak nieużywanego kodu.

Czego unikać?

• Klasa-Bóg: Jeden obiekt, który robi absolutnie wszystko.
• Globalne zmienne: Używaj atrybutów klasy.
• Brak walidacji: Przyjmowanie każdych danych od użytkownika bez sprawdzenia.
• Ignorowanie PEP 8: Niechlujne formatowanie (brak wcięć, dziwne nazwy).

Kiedy oddać projekt?

Szczegółowe terminy zostaną podane na platformie e-learningowej.

Rada: Nie zostawiajcie pisania na ostatnią noc. Projektowanie obiektowe wymaga czasu na przemyślenie struktury. Najpierw narysuj, potem koduj!

Koniec kursu

Gratulacje! Przeszliśmy razem przez podstawy i zaawansowane aspekty programowania obiektowego w Pythonie.

Pamiętajcie, że programowanie to rzemiosło. Kluczem do sukcesu jest pisanie jak największej ilości kodu i ciągłe szukanie sposobów na jego ulepszenie.

Do zobaczenia na prezentacji projektów!