Classpath Zwei gleiche Dateinamen in verschiedenen Projekten möglich?

[tumprogrammer]

Hallo zusammen,

ich habe in Eclipse zwei Projekte, die jeweils eine Datei mit gleichem Namen enthalten. Nun zeigt mir Eclipse die Fehlermeldung "The type Kreis is already defined" an. Ist es nicht möglich, zwei gleiche Dateinamen in verschiedenen Projektes zu haben?

Danke!!

 

[Javinner]

Datei mit gleichem Namen

Was für Dateien? Zwei Klassen, welche den Namen Kreis tragen?

 

[krgewb]

Ich habe etliche Projekte mit einer "Hauptprogramm.java"

 

[tumprogrammer]

Was für Dateien? Zwei Klassen, welche den Namen Kreis tragen?

Ja genau zwei Klassen Kreis.java

 

[Javinner]

Ja genau zwei Klassen Kreis.java

Darin liegt der Sinn: kein doppelten Code zu erzeugen.
Überlege dir gut, was die Klasse Kreis können muss, ob diese als privat, publik oder final zu kennzeichnen ist und alle Instanzvariablen und Methoden, die diese Klasse enthält. Als Vorlage würde ich dir die Java-Bibliothek empfehlen, als Beispiel die Klasse Math https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html
Angenommen, du willst kein Objekt von Kreis oder Quadrat erzeugen, jedoch brauchst du hier und da die Fläche des Kreises oder des Quadrates zum Berechnen, so eignet sich eine Klasse Flaeche, welche als final deklariert ist (keine Instanz-Erzeugung der Klasse möglich), um dir die Flächeninhalte der jeweiligen Form zu liefern.

public final class Flaeche
{

    static double getKreisFlaeche(double radius)
    {
        return (radius * radius) * Math.PI;
    }

    static double getQuadratFlaeche(double laenge)
    {
        return (laenge * laenge);
    }

}

So kannst du die Klasse Flaeche und die Methoden dieser überall, wo du es brauchst, aufrufen, Werte übergeben und erhalten, ohne die Klasse deklarieren und initialisieren zu müssen (an dieser Stelle nehme ich gerne Korrekturen entgegen, falls ich mich irre).

public class FlaechenBerechnung
{

    public static void main(String[] args)
    {
        double radius = 20;
        System.out.println(Flaeche.getKreisFlaeche(radius));

        double laenge = 20;
        System.out.println(Flaeche.getQuadratFlaeche(laenge));
    }

}

Wie gesagt: es hängt sehr davon ab, was die Klasse können muss oder wie diese wo eingesetzt wird. Seeeehr umfangreiches Thema

 

[krgewb]

Sein Ärgernis ist aber, dass die Fehlermeldung erscheint obwohl die Dateien in verschiedenen Projekten sind. Das sollte doch eigentlich keine Probleme machen!?

 

[Javinner]

Das sollte doch eigentlich keine Probleme machen!?

Habe es gerade in NetBeans ausprobiert und siehe an, das ist kein Problem, wenn die Klassen nicht in dem selben Paket liegen. Etwas gegoogelt: es scheint ein generelles Problem von Eclipse zu sein, fand Einträge zum selben Thema aus dem Jahr 2006.

Kurz um: überfragt, kann leider keine genaue Antwort liefern.

 

[mrBrown]

[...]

Deine Codestücke sind aber auch eher Beispiele, wie man es nicht machen sollte

 

[Javinner]

Deine Codestücke sind aber auch eher Beispiele, wie man es nicht machen sollte

Mach mit, machs nach, machs besser

 

[mrBrown]

Mach mit, machs nach, machs besser

Objektorientiert:

public interface Flaeche{
    double getFlaeche();
}

class Kreis implements Flaeche {
   final double radius;
   Kreis(double radius) {
      this.radius = radius
   }
   double getFlaeche() {
      return (radius * radius) *Math.PI
   }
}

(Wobei das jetzt ganz schön offtopic ist )

 

[Javinner]

@mrBrown
Das ist klar. Da Java keine Mehrfachvererbung erlaubt, sind Interfaces sehr nützlich und ermöglichen allen Klassen, die diese implementieren ein Satz an Methoden, welche für alle implementierenden Klassen gleich heißen und jeweils in der Klasse implementiert werden müssen. Auch pflegeleicht, weil man an nur einer Stelle weitere Mögliche Methoden einfügen kann.

Jedoch muss die jeweilige Klasse deklariert und implementiert werden. So frage ich mich nach der Zeit, ob es hier und da sinnvoller wäre, eine Klasse wie die oben erwähnte Math ins Leben zu rufen, welche public ist und eine Reihe an Methoden bietet, welche die Fläche berechnen, als Beispiel. Ich für mich kann hier kein Nachteil erkennen, warum man dies nicht tun sollte, wenn diese besagte Klasse nur zur Umrechnung eingesetzt wird, weil eben der Speicher nicht mit Erzeugung von jeweiligen Klassen beschäftigt wird und alles nur durch eine Klasse erledigt werden kann.
Von der Programmierung ganz abgesehen, den für jede Form muss(Vorbehalt) eine Klasse erstellt werden so dass am Ende des Tages man 10 Klassen und ein Interface hat.

Ein Grund, weshalb man es auf vielen Klassen unterteilen sollte ist die Übersichtlichkeit, sonst fällt mir da nichts ein.

 

[mrBrown]

Jedoch muss die jeweilige Klasse deklariert und implementiert werden.

Die Methoden musst du so oder so implementieren - nur hast du es bei der einen Variante sinnvoll gruppiert, und bei der anderen nicht

Von der Programmierung ganz abgesehen, den für jede Form muss(Vorbehalt) eine Klasse erstellt werden so dass am Ende des Tages man 10 Klassen und ein Interface hat.

Die implementierten Methoden hast du sowieso, das einzig zusätzliche sind die 11 Typ-Deklarationen (und deren Schreibaufwand ist vermutlich weniger, als an jede Methode den Typ zu schreiben ) .

Ich für mich kann hier kein Nachteil erkennen, warum man dies nicht tun sollte, wenn diese besagte Klasse nur zur Umrechnung eingesetzt wird

Was du damit gewinnst, sind eben Objekte mit denen du sinnvolle arbeiten kannst
Du kannst sonst zB keine Liste von Objekten erstellen, da du nicht weißt, ob die Zahl grad ein Kreis oder Quadrat sein soll. Hättest du Klassen, wäre das kein Problem - die Klasse weiß schließlich, was sie ist.

Für das Hinzufügen von neuen Formeln müsstest du alles ändern - aber eben in beiden Fällen, wobei man bei OO natürlich mehr ändern muss, könnte man als leichten Nachteil dafür sehen.
Für das Hinzufügen von neuen Formen müsstest du mit OO aber nichts bestehendes anpassen, und kannst die neuen Formen einfach so nutzen - deine eine große Klasse müsstest du im Gegensatz dazu ändern.
Und was passiert öfter - neue Formeln für bestehende Formen oder neue Formen?

, weil eben der Speicher nicht mit Erzeugung von jeweiligen Klassen beschäftigt wird

Das sollte niemals ein Grund sein (und Speicher in Java ist ein zu komplexes Thema, als das es so leicht abzuhaken wäre ;P)

Ein Grund, weshalb man es auf vielen Klassen unterteilen sollte ist die Übersichtlichkeit, sonst fällt mir da nichts ein.

Gibt es irgendwas wichtigeres?

 

[Javinner]

Gibt es irgendwas wichtigeres?

Die Ordnung ist das halbe Leben
Vielleicht ist das Beispiel mit der Klasse Kreis zu banal und trifft nicht ins Schwarze, weil eben hier du schon Recht hast. Mit den paar Klassen und einem Interface ist man hier wesentlich besser dran. Jedoch bin ich auf die Überlegung schon paar Mal gekommen, ob es hier und da für bestimmte Berechnungen nicht eine finale Klasse ins Leben gerufen werden sollte, um dies oder das schnell zu berechnen. Da befinde ich mich noch in einer experimenteller Phase und teste, ob der vermeintliche Vorteil auch ein Vorteil ist.

 

[mrBrown]

Die Ordnung ist das halbe Leben
Vielleicht ist das Beispiel mit der Klasse Kreis zu banal und trifft nicht ins Schwarze, weil eben hier du schon Recht hast. Mit den paar Klassen und einem Interface ist man hier wesentlich besser dran. Jedoch bin ich auf die Überlegung schon paar Mal gekommen, ob es hier und da für bestimmte Berechnungen nicht eine finale Klasse ins Leben gerufen werden sollte, um dies oder das schnell zu berechnen. Da befinde ich mich noch in einer experimenteller Phase und teste, ob der vermeintliche Vorteil auch ein Vorteil ist.

In den meisten Fällen (Ausnahmen bestätigen die Regel) fährt man mit Klassen besser.
(Aber das wäre, Falls du welche hast, mit konkreten Beispielen einen eigenen Thread wert )