# Attribute in Interfaces möglich?



## ernst (13. Jul 2007)

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 (13. Jul 2007)

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 (13. Jul 2007)

JPKI hat gesagt.:
			
		

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



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 (13. Jul 2007)

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 (13. Jul 2007)

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 (13. Jul 2007)

ernst hat gesagt.:
			
		

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


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 (13. Jul 2007)

: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 (13. Jul 2007)

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


----------



## Murray (13. Jul 2007)

Anonymous hat gesagt.:
			
		

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


Wie meinst du das?


----------



## Guest (14. Jul 2007)

Murray hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...


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 (14. Jul 2007)

> 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 (14. Jul 2007)

HoaX hat gesagt.:
			
		

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


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 (14. Jul 2007)

JPKI hat gesagt.:
			
		

> 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 (14. Jul 2007)

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 (14. Jul 2007)

HoaX hat gesagt.:
			
		

> 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 (14. Jul 2007)

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


----------



## Guest (14. Jul 2007)

Wildcard hat gesagt.:
			
		

> @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 (16. Jul 2007)

Anonymous hat gesagt.:
			
		

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


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


----------

