Pakete

🚧

Diese Seite befindet sich in Bearbeitung

🚧

🤓

Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 2 annotiert und ab Blatt 3 abgezogen wird.

🤓

Beschreibung

Wir kennen bereits den "src" Ordner, in dem erst mal alle für unser Programm notwendigen Klassen(dateien) liegen. Dieser Ordner wird auch das Standard-Paket (default-package) genannt. Da das bei größeren Projekten schnell für Unordnung sorgen kann, gibt es sogenannte Pakete.

Im Folgenden werden wir das Paket edu.kit.kastel als Standardpaket bezeichnen. Dieses (oder ein ähnlich sinnvoll gewähltes Paket wie com.github.name) sollte in den Abgaben immer alle anderen Pakete und Klassen beinhalten.

Pakete sind einfache Ordnerstrukturen innerhalb des "src"-Ordners, die helfen sollen, Struktur in das Programm zu bringen.

Um ein Paket zu erstellen muss nicht viel mehr gemacht werden, als einen Ordner innerhalb des "src"-Ordners zu erstellen und diesem einen Namen zu geben, den das Paket bekommen soll. Innerhalb von IDEs ist es sogar noch simpler, diese haben in der Regel Funktionalität zum Einfügen von Paketen.

Geschachtelte Pakete wie das obige edu.kit.kastel bestehen dabei nicht nur aus einem Ordner, sondern stellen einen Dateipfad dar. Das heißt, dass es einen Ordner src gibt, der einen Ordner edu enthält. Dieser enthält dann wieder einen Ordner, der kit bennant wurde und dieser beinhaltet letztlich den Ordner kastel. Jeder dieser Ordner ist nun ein Paket.

Um von der Paketbezeichnung zur Ordnerstruktur zu gelangen müssen also alle Punkte in der Paketbezeichnung durch "\" ersetzt werden um den Dateipfad zu erhalten.

Anschließend muss innerhalb jeder Klasse, die diesem Ordner hinzugefügt wurde, angegeben werden, in welchem Paket die Klasse denn jetzt eigentlich ist. Das geschieht über das package-Keyword.

package edu.kit.kastel.graphics; ist also das Grafik-Paket innerhalb unseres Standardpakets.

Wichtig:

Pakete beinhalten nur Klassen, jedoch keine anderen Pakete. In dem Beispiel von eben ist also das Paket package edu.kit.kastel.graphics nicht Teil unseres Standardpakets edu.kit.kastel.

Um jetzt Klassen aus einem anderen Paket zu verwenden, müssen wir diese zunächst importieren. Auch dafür gibt es ein entsprechendes Keyword: import. Wir importieren etwa die Square-Klasse aus dem Grafik-Paket wie folgt:

import edu.kit.kastel.graphics.Square;.

Wildcard Imports

Es kann schnell dazu kommen, viele externe Klassen importieren zu müssen. Da kommt dann schnell die Frage: "Wieso kann ich nicht einfach ein ganzes Paket importieren? Das geht schneller und ich habe weniger import-Statements".

Das geht und wird Wildcard-Import genannt. Hierbei spezifizieren wir bei einem import-Statement das gewünschte Paket und erweitern das mit einem ".*". Damit importieren wir direkt das gesamte Paket und alle enthaltenen Klassen.

Und wo ist jetzt das Problem? Ich kann ja schließlich alle Klassen jetzt verwenden. Ja. Allerdings entsteht das Problem nicht direkt durch den Import. Sondern durch die dadurch entstehenden Namenskonflikte innerhalb des Quellcodes. Hier gibt es 3 Möglichkeiten, die eintreten können:

Es kann direkt einen Konflikt geben. Ein Klassenpaar aus dem importierten Paket und dem eigenen Projekt hat denselben Namen. Das führt zu einem Kompilierfehler.
Es gibt erst einmal keine Probleme beim Importieren. Allerdings gibt es später Typisierungsfehler beim Verwenden einer Klasse, da wird glauben, die richtige Klasse zu verwenden, obwohl wir tatsächlich eine andere Klasse verwenden.
Wenn der Code kompiliert wird, wird erst mal nur eine Klasse aus dem importierten Paket verwendet. Eine Klasse mit gleichem Namen im Paket gibt es erst mal nicht. Das Kompilieren führt dann nicht zu Problemen. Fügen wir jetzt allerdings später eine Klasse dem Paket mit gleichem Namen hinzu und kompiliert erneut, ist der vorher valide Quellcode auf einmal invalide.

Durch das einzelne Importieren der verwendeten Klassen ist also direkt auf einen Blick klar, welche Klasse überhaupt verwendet werden soll. Dadurch führt es nicht mehr zu "Leichtsinnsfehlern" und vielen frustgeplagten Stunden, Fehler zu debuggen.

Für die Verwendung von Paketen gibt es zusätzlich folgende Konventionen:

Das Standardpaket ist in der Regel immer die Domain, gespiegelt
Das Standardpaket des Übungsbetriebes ist edu.kit.kastel (Die Domain ist "kastel.kit.edu")
Bezeichner sind sinnvoll zu wählen und kleinzuschreiben
Die Klassen sollten in sinnvolle Pakete gegliedert werden

Negativbeispiel

package edu.kit.kastel.mEmEs.PaTrIkStAr;

import java.util.*;

Positivbeispiel

package edu.kit.kastel.game.model;

import edu.kit.kastel.game.ai.ArtificialPlayer;
import java.util.HashMap;