Attribute in Interfaces möglich?

[ernst]

Hallo allerseits,
In Interfaces werden Methodenköpfe definiert.
Dürfen in Interfaces auch Attribute (private) vorkommen?
Kann mir jemand dazu ein Beispiel geben?

mfg
Ernst

 

[JPKI]

Nein, in Interfaces können nur statische Variablen (ich glaub "final" ist nicht unbedingt nötig) definiert werden.
Sicher können die auch prviat sein... Nur Atrribute halt nicht (also Objektvariablen).

Beispiel:

public interface IndaFaeis {

  public static final int KONSTANTE_1=12340;
  public static final int KONSTANTE_2=12341;

  //Methodenköpfe
  public void doSomething(Object o[]);
}

 

[ernst]

Nein, in Interfaces können nur statische Variablen (ich glaub "final" ist nicht unbedingt nötig) definiert werden.
Sicher können die auch prviat sein... Nur Atrribute halt nicht (also Objektvariablen).

Beispiel:

public interface IndaFaeis {

  public static final int KONSTANTE_1=12340;
  public static final int KONSTANTE_2=12341;

  //Methodenköpfe
  public void doSomething(Object o[]);
}

Was mir dazu gerade noch einfällt:
Muss das Interface in einer eigenen Datei erstellt werden?
(d.h. die Klasse die das Interface implementiert muss sich einer anderen Datei befinden)?

mfg
Ernst

 

[JPKI]

Diesbezüglich gilt das selbe wie für Klassen:

- Ist das Interface public, so muss es in eine eigene Datei gepackt werden
- Du kannst aber auch Interfaces definieren, die eben nicht public sind und diese somit auch in eine deiner anderen Dateien mit hineinpacken
- Du kannst auch innere Interfaces definieren, genauso wie innere Klassen.

 

[ernst]

Ok.
Kannst du mir den _Sinn_ sagen, warum eine public Klasse in einer eigenen Datei stehen muss?
(Irgendwas müssen die Java-Entwickler dabei gedacht bzw. beabsichtigt haben).

mfg
Ernst

 

[Guest]

Ok.
Kannst du mir den _Sinn_ sagen, warum eine public Klasse in einer eigenen Datei stehen muss?
(Irgendwas müssen die Java-Entwickler dabei gedacht bzw. beabsichtigt haben).

mfg
Ernst

Dies schafft bzw. erzwingt etwas mehr Ordnung im Code. Dateien kriegen die gleichen Namen wie die darin
enthaltenen public-Klassen. So kann man auch im Verzeichnis nach einer bestimmten Klasse suchen.
Gleiches gilt übrigens auch für Packages und die dazugehörige Verzeichnisstruktur.
(die ganze Reflection-API basiert darauf bzw. setzt dies voraus)
In C# kann man z.B. Namespaces (sowas wie Packages) unabhängig von der Verzeichnisstruktur vergeben
und Klassennamen sind auch nicht zwingend mit Klassennamen gekoppelt.
Folge: Wenn die Entwickler schlampig in der Namensgebung sind, findet man nur mit Mühe etwas. Es gibt
aber Zusatztools, mit denen man das Problem entschärfen kann (FxCop für .NET, Checkstyle für Java etc.)

Jetzt stell dir mal vor, du steigst bei irgendeiner Firma in ein laufendes Projekt ein und sollst dich schnell
zurecht finden. Es ist viel einfacher, wenn es gewisse Konventionen gibt, die überall gleich eingehalten
werden.

 

[Guest]

:autsch: Ich meinte

In C# kann man z.B. Namespaces (sowas wie Packages) unabhängig von der Verzeichnisstruktur vergeben
und Dateinamen sind auch nicht zwingend mit Klassennamen gekoppelt.

 

[Wildcard]

1. und was ist daran gut?
2. packages haben primär nichts mit der Verzeichnisstruktur zu tun.

 

[Murray]

(die ganze Reflection-API basiert darauf bzw. setzt dies voraus)

Wie meinst du das?

 

[Guest]

(die ganze Reflection-API basiert darauf bzw. setzt dies voraus)

Wie meinst du das?

Hier ein typisches Beispiel

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")

Man kann davon ausgehen, dass irgendeine Jar-Datei oder URI im Classpath diese Klasse enthält.
Ferner ist auch bekannt, dass die Klasse in einem Unterverzeichnis "sun/jdbc/odbc" zu finden
ist und auch tatsächlich den Namen "JdbcOdbcDriver" hat.
All dies ist nur deswegen möglich, da Packages und Klassennamen den oben genannten Konventionen
entsprechen. Wäre dies nicht der Fall, müsste jede Jar-Datei etc. eine Zusammenfassung der darin
enthaltenen Klassen enthalten (ein Mapping von Dateien und Klassen) oder es müsste jede einzelne
Datei untersucht werden, ob sie eine solche Klasse enthält.

 

[HoaX]

Man kann davon ausgehen, dass irgendeine Jar-Datei oder URI im Classpath diese Klasse enthält.
Ferner ist auch bekannt, dass die Klasse in einem Unterverzeichnis "sun/jdbc/odbc" zu finden
ist und auch tatsächlich den Namen "JdbcOdbcDriver" hat.

du kannst davon ausgehen dass einer der classloader diese klasse laden kann. ob das jetzt ein jarclassloader ist, der seine classen in verzeichnissen ordnet oder ein selbstgeschriebener, der die klassen anhand vom packagenamen von der entsprechenden domain im internet läd ist nicht gesagt. der packagename ist nur eine innere ordnung, wie die klassen geladen werden und wie sie in der quelle stukturiert sind hat damit nichts zu tun.

All dies ist nur deswegen möglich, da Packages und Klassennamen den oben genannten Konventionen
entsprechen. Wäre dies nicht der Fall, müsste jede Jar-Datei etc. eine Zusammenfassung der darin
enthaltenen Klassen enthalten (ein Mapping von Dateien und Klassen) oder es müsste jede einzelne
Datei untersucht werden, ob sie eine solche Klasse enthält.

letzteres ist der fall, der JarClassLoader ist nur dazu da, klassen auf jardateien zu laden. für andere quellen gibts wiederum andere classloader.

 

[Guest]

Man kann davon ausgehen, dass irgendeine Jar-Datei oder URI im Classpath diese Klasse enthält.
Ferner ist auch bekannt, dass die Klasse in einem Unterverzeichnis "sun/jdbc/odbc" zu finden
ist und auch tatsächlich den Namen "JdbcOdbcDriver" hat.

du kannst davon ausgehen dass einer der classloader diese klasse laden kann. ob das jetzt ein jarclassloader ist, der seine classen in verzeichnissen ordnet oder ein selbstgeschriebener, der die klassen anhand vom packagenamen von der entsprechenden domain im internet läd ist nicht gesagt. der packagename ist nur eine innere ordnung, wie die klassen geladen werden und wie sie in der quelle stukturiert sind hat damit nichts zu tun.

All dies ist nur deswegen möglich, da Packages und Klassennamen den oben genannten Konventionen
entsprechen. Wäre dies nicht der Fall, müsste jede Jar-Datei etc. eine Zusammenfassung der darin
enthaltenen Klassen enthalten (ein Mapping von Dateien und Klassen) oder es müsste jede einzelne
Datei untersucht werden, ob sie eine solche Klasse enthält.

letzteres ist der fall, der JarClassLoader ist nur dazu da, klassen auf jardateien zu laden. für andere quellen gibts wiederum andere classloader.

Es geht mir nur um den Sinn der ganzen Geschichte. Die Classloaderhierarchie und das eigentliche Laden von Klassen
liess ich hier weg. Der Standard ist aber nun mal, dass Packages in entsprechende Verzeichnisstrukturen aufgelöst werden.
z.B. (Der Pfad innerhalb der Jardatei entspricht dem Packagenamen und der Dateiname dem Klassennamen)

jar:file:/c:/programme/java/jdk1.6.0_01/jre/lib/rt.jar!/sun/jdbc/odbc/JdbcOdbcDriver.class

 

[tfa]

Nein, in Interfaces können nur statische Variablen (ich glaub "final" ist nicht unbedingt nötig) definiert werden.
Sicher können die auch prviat sein... Nur Atrribute halt nicht (also Objektvariablen).

"Variablen" in Interfaces sind immer public, static und final, niemals private.
Ob man die Modifier jetzt dazu schreibt oder nicht, bleibt einem selbst überlassen.

tfa

 

[HoaX]

gast, nur weil es der am häufigsten verwendete classloader, jarclassloader, so macht ist das noch lange kein standard. und die reflectionapi hat damit auch überhauptnix zu tun.

 

[Guest]

gast, nur weil es der am häufigsten verwendete classloader, jarclassloader, so macht ist das noch lange kein standard. und die reflectionapi hat damit auch überhauptnix zu tun.

Ich gebe auf, hat keinen Sinn. Ich habe hier manchmal den Eindruck, dass ich Deutsch schreibe und
der Forumsserver konvertiert es in Chinesisch. Keine Ahnung, was für ausgefallene, selbst geschriebene
Klassloader du verwendest, aber bei 99% aller Java-Anwendungen entspricht die Verzeichnisstruktur
der Packagestruktur (ob Jar-Datei, Verzeichnis, Jar-Datei über HTTP oder anderes Protokoll (URLClassloader
allgemein)) und das ist nun mal Standard bei Java. Was ist so schwer daran zu verstehen, was ich meine?

package a.b.c;

public class Hallo
{
   public static void main(String args[])
   {
      System.out.println("Hallo");
   }
}

Compiliere es ohne die Option -d und versuche es zu starten. Benenne die .class Datei um und versuche
es ebenfalls zu starten. OK, hier kommt jetzt dein ausgefallener Classloader zum Einsatz. :wink:

 

[Wildcard]

@Gast
Java Klassen aus Datenbanken zu laden ist so ungewöhnlich nicht.

 

[Guest]

@Gast
Java Klassen aus Datenbanken zu laden ist so ungewöhnlich nicht.

Du kannst auch einen Classloader schreiben, der zunächst eine Email nach Japan schickt, die dort von
irgendeinem Server verarbeitet wird und dem Classloader via ICQ die Adresse eines Servers in Papua
Neu Guinea zuschickt, der ein Katalog von Klassen und der dazugehörigen Server führt, auf denen die
gesuchten Klassen gehostet sind. Jeder dieser Server speichert die Klassen in einem speziellen, Kontinent-
abhängigen Format, für den du einen Decoder von einem Server auf Grönland brauchst...
All diese Klassen wurden auch mit einem speziellen Compiler compiliert, der nicht darauf besteht, dass die
Sourcecodedateien den Klassennamen entsprechen...

:wink: Man kann das beliebig fortführen.

 

[Yzebär]

Du kannst auch einen Classloader schreiben, der zunächst eine Email nach Japan schickt, die dort von
irgendeinem Server verarbeitet wird und dem Classloader via ICQ die Adresse eines Servers in Papua
Neu Guinea zuschickt, der ein Katalog von Klassen und der dazugehörigen Server führt, auf denen die
gesuchten Klassen gehostet sind. Jeder dieser Server speichert die Klassen in einem speziellen, Kontinent-
abhängigen Format, für den du einen Decoder von einem Server auf Grönland brauchst...
All diese Klassen wurden auch mit einem speziellen Compiler compiliert, der nicht darauf besteht, dass die
Sourcecodedateien den Klassennamen entsprechen...

Deswegen ist Java sooooooooooo langsam... wegen des speziellen Classloaders... :wink: