static inner Klassen

[Gast]

Moin,

hab gerade ein static inner Klasse ausprobiert und bin begeistert.
Verwendet ihr solche Konstrukte oft bzw. bin ich auf der Suche nach Anwendungsfällen,
Habt ihr da einige Vorschläge?

package javaapplication35;

public class Calculation {

	public double calculate(double x, Operation operation, double y) {
	    return operation.eval(x, y);
	    }

	public abstract static class Operation {

        private String name;

        public Operation(String name) {
            this.name = name;
            }

	    public abstract double eval(double x, double y);

	    public static Operation PLUS = new Operation("+") {
            public double eval(double x, double y) { return x + y;}
            };

	    public static Operation MAL = new Operation("*") {
            public double eval(double x, double y) { return x * y;}
            };
	}
}

 

[tfa]

Inner Classes sind nie statisch. Das was du meinst ist nur eine "nested class", also eine eingebettete Klasse. Wenn möglich, sollte man eingebettete Klassen immer statisch machen, also inner classes vermeiden.
Solche eingebetteten Klassen sind eine gute Möglichkeit zur Kapselung seiner Daten. Wenn die Objekte der nested class nur von einer äußeren Klasse verwendet bzw. verwaltet werden, kann man die gut lokal definieren. Auch wenn man sie über eine Schnittstelle nach außen zur Verfügung stellen will.

 

[Spacerat]

Inner Classes sind nie statisch. Das was du meinst ist nur eine "nested class", also eine eingebettete Klasse. Wenn möglich, sollte man eingebettete Klassen immer statisch machen, also inner classes vermeiden.

Klar... wenn man eingebettete Klassen nicht statisch macht, werden es "inner-classes". Das fatale an deinem Satz fällt wohl nur Querlesern auf. Glücklicherweise weis man sofort was du sagen willst. "inner-classes" vermeiden ist auch eine gute Idee. Ist das auch bei "generischen" Klassen möglich (innere Klasse verwendet Parameter der äusseren)? Wenn ja, wüsste ich gerne wie.

mfg Spacerat

 

[didjitalist]

nested classes gibt es nur in zwei geschmacksrichtungen: statisch und nicht statisch. mehr gibs da nicht zu unterscheiden. nicht statische nested classes (manche nennen sie wohl inner classes), benötigen ein exemplar ihrer umgebenen klasse, um erzeugt werden zu können.

man sollte nested classes daher nur dann nicht-statisch machen, wenn so ein objekt niemals ohne seine umgebene klasse existieren darf. meist sind aber parametrisierte statische nested classes der schmerzlosere weg.

 

[tfa]

meist sind aber parametrisierte statische nested classes der schmerzlosere weg.

Ja, aber die können die Parameter der äußeren Klasse nicht verwenden, da die Objekte ja isoliert existieren. Ich glaube, darum ging die Frage.

 

[Spacerat]

@tfa: Genau darum gehts (mir zumindest).

Ich habe da folgendes:

public class ObjectStore<K extends CharSequence, V>
implements Iterable<ObjectStore.Entry<K, V>>
{
    public interface Entry<KK extends K, VV extends V>
    {
        KK getKey();
        VV getValue();
    }
}

"Entry" ("inner-class") ist hier zwar nach aussen Sichtbar aber nicht von dort zu verwenden (z.B. für anonyme Instanzierung ohne eine Instanz von "ObjectStore").

public class ObjectStore<K extends CharSequence, V>
implements Iterable<ObjectStore.Entry<K, V>>
{
    public static interface Entry<KK, VV>
    {
        KK getKey();
        VV getValue();
    }
}

Lässt man die "extends"-Klauseln weg, bekommt man "Entry" auch statisch. Nun ist "Entry" nicht nur Sichtbar, ich kann es auch ausserhalb von "ObjectStore" verwenden (z.B. anonym instanzieren).

Dabei fällt mir auf, das das eine das andere ausschliesst. Meine Frage wie ich "Entry", mit Beibehaltung der Eigenschaft es nach Aussen hin unverwendbar zu lassen, statisch bekomme, dürfte sich damit wohl erledigt haben. Es geht nicht.

mfg Spacerat

 

[tfa]

Richtig, weil du Eigenschaften von ObjectStore in Entry benötigst.
Das mit der Nichtverwendbarkeit nach Außen löst man aber am besten damit, die Klasse bzw. das Interface private zu machen.

 

[Spacerat]

Das hatte ich mir auch schon gedacht. Geht aber nicht, wegen "Iterable". Man soll doch wenigstens von aussen durch die Elemente iterieren können.

mfg Spacerat