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. Da das bei größeren Projekten schnell für Unordnung sorgen kann, gibt es sogenannte Pakete.

Diese 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.

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.

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;.

Wichtig:

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:

1. 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.
2. 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.
3. 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;