Mehrfachvererbung auf Spezifikations- und Implementierungsebene in Java. Interfaces

[OliI.]

Hallo,

haben das Thema abstrakte Klassen behandelt, dann haben wir uns Interfaces angeschaut:

Meine Fragen:
=> Ist es richtig, das man in einem Interface in der Regel keine Attribute setzt, sondern i.d.R. nur Methoden die automatisch abstrakt und public sind?

Mehrfachvererbung auf Spezifikationsebene ist in Java möglich auf Implementierungsebene allerdings nicht.
=> Was ist hier unter Spezifikationsebene und Implementierungsebene zu verstehen?

Gruß

 

[Oneixee5]

Die Frage bedeutet wohl, dass du deinem Tutor und/oder den Unterlagen zum Kurs nicht vertraust!? Da kannst über das Thema hier: https://openbook.rheinwerk-verlag.de/oop/oop_kapitel_05_004.htm nachlesen.

 

[OliI.]

Ich vertrau dem Tutor/Dozenten schon, nur sind die angegebenen Erklärungen für Programmieranfänger nicht immer verständlich.
Deshalb die Nachfrage.

 

[M.L.]

nicht immer verständlich

Generell gilt es -für den Menschen- "auf Vorrat" (häufige(re)) Änderungen oder Erweiterungen der Software (z.B. einer Basisklasse) einzuplanen und diese an einer (zentralen) Stelle durchzuführen. Eine abstrakte Klasse erzwingt eine Vererbung, wobei die Zielklasse zuviel oder zuwenig Funktionalität bekommen könnte. Mit Interfaces bleibt man hierbei flexibler: SOLID-Prinzipien ("Composition over inheritance")

 

[mihe7]

=> Ist es richtig, das man in einem Interface in der Regel keine Attribute setzt, sondern i.d.R. nur Methoden die automatisch abstrakt und public sind?

Fast. Erstmal ist "setzen" ein äußerst ungünstiger Begriff. Ein Attribut setzen würde bedeuten, den Wert eines Attributs festzulegen. Dir geht es um die Deklaration bzw. Definition eines Attributs. Diesbezüglich könntest Du sagen, dass ein Interface keine Attribute besitzt und zwar nicht nur "in der Regel", sondern ganz grundsätzlich.

Eine Methode "setzt" man gar nicht. Man kann sie deklarieren oder definieren. Mit einem Interface werden Methoden deklariert, in der Regel jedoch nicht definiert. Hier stimmt "in der Regel", weil es mittlerweile durchaus die Möglichkeit gibt, Standarddefinitionen für eine Methode in einem Interface anzugeben (default implementation).

 

[KonradN]

Bezüglich Attribute kann man einfach in die Java Language Specification schauen. JLS 9.3:

Every field declaration in the body of an interface declaration is implicitly public, static, and final. It is permitted to redundantly specify any or all of these modifiers for such fields.

Das bedeutet also: Alle Variablen sind automatisch Konstanten auf Klassenebene und es gibt keine Instanzvariablen.

Eine Methode "setzt" man gar nicht. Man kann sie deklarieren oder definieren. Mit einem Interface werden Methoden deklariert, in der Regel jedoch nicht definiert. Hier stimmt "in der Regel", weil es mittlerweile durchaus die Möglichkeit gibt, Standarddefinitionen für eine Methode in einem Interface anzugeben (default implementation).

Dazu möchte ich auch noch anregen: Es gibt auch de ganz normalen private Methoden in einem Interface. Ebenso die bekannten statischen Methoden. JLS 9.4 sagt dazu:

A method in the body of an interface declaration may be declared public or private (§6.6). If no access modifier is given, the method is implicitly public. It is permitted, but discouraged as a matter of style, to redundantly specify the public modifier for a method declaration in an interface declaration.

A default method is an instance method declared in an interface with the default modifier. Its body is always represented by a block, which provides a default implementation for any class that implements the interface without overriding the method. Default methods are distinct from concrete methods (§8.4.3.1), which are declared in classes, and from private interface methods, which are neither inherited nor overridden.

An interface can declare static methods, which are invoked without reference to a particular object. static interface methods are distinct from default methods, abstract interface methods, and non-static private interface methods, all of which are instance methods.

The declaration of a static interface method introduces a static context (§8.1.3), which limits the use of constructs that refer to the current object. Notably, the keywords this and super are prohibited in a static context (§15.8.3, §15.11.2), as are unqualified references to instance variables, instance methods, and type parameters of lexically enclosing declarations (§6.5.5.1, §6.5.6.1, §15.12.3).

Daher ist folgendes Interface gültig:

package de.kneitzel;

public interface TestInterface {

    private void doSomethingPrivate() {
        System.out.println("do something private");
    }

    static void doSomethingStatic() {
        System.out.println("do something static");
    }

    default void doSomethingDefault() {
        System.out.println("default");
        doSomethingPrivate();
        doSomethingStatic();
    }

    void doSomething();

    static void main(String[] args) {
        TestInterface instance = new TestInterface() {
            @Override
            public void doSomething() {
                System.out.println("Test");
            }
        };

        instance.doSomethingDefault();
    }
}

Die main für einen Test habe ich einfach einmal mit hinein gepackt.

Chapter 9. Interfaces (oracle.com)

 

[philanthrop]

Ist es richtig, das man in einem Interface in der Regel keine Attribute setzt, sondern i.d.R. nur Methoden die automatisch abstrakt und public sind?

Ja

Was ist hier unter Spezifikationsebene und Implementierungsebene zu verstehen?

Trennung zwischen Konzept und Umsetzung (Abstraktion). Man könnte auch Theorie und Praxis sagen. Oder anders, es gibt auch Programmiersprachen, die es erlauben, Java jedoch nicht.

Beispiel: Grüne Elefanten sind zwar theoretisch möglich, in der Praxis jedoch wahrscheinlich selten.

 

[mihe7]

Dazu möchte ich auch noch anregen: Es gibt auch de ganz normalen private Methoden in einem Interface. Ebenso die bekannten statischen Methoden. JLS 9.4 sagt dazu:

Wusste ich es doch: wenn ich es aus dem Kopf schreibe, vergesse ich garantiert was

 

[KonradN]

Wusste ich es doch: wenn ich es aus dem Kopf schreibe, vergesse ich garantiert was

Das Problem ist hier vermutlich wie immer: Wann hast du sowas bisher gebraucht? Mal eine default Methode: ok. Aber noch private Methoden?

Das ist typische Theorie, die nur Leute kennen, die vor dem Essen uns ins Bett gehen ein Abschnitt der JLS als Gebet sprechen oder so

 

[Barista]

Mehrfachvererbung auf Spezifikationsebene ist in Java möglich auf Implementierungsebene allerdings nicht.
=> Was ist hier unter Spezifikationsebene und Implementierungsebene zu verstehen?

Ich würde sagen, in diesem Fall ist mit Spezifikationsebene die abstrakte Angabe von Methoden in einem Interface oder einer abstrakten Klasse gemeint.

Mit Implementierungsebene ist dann die Implementierung der Methoden, also das Hinschreiben des Codes in den Body (in die beiden äußeren geschwungenen Klammern) gemeint.

Die Vorstellung als Ebene kommt wahrscheinlich von der Darstellung als Vererbungsbaum. Wie üblich in der IT steht der Baum Kopf, also Wurzel oben und Blätter unten.

 

[philanthrop]

Denke, Spezifikation ist einfach das Konzept einer Sprache, also das theoretisch mögliche. Denn Java erlaubt Mehrfachvererbung nicht. Man kann zwar versuchen, extends zwei oder mehr Klassen zu schreiben, aber dann wird der Compiler einen Fehler generieren.

 

[philanthrop]

@Barista Oder ist das im Bytecode möglich? Weißt du da was? Also ist das theoretisch vorgesehen?

 

[KonradN]

Denke, Spezifikation ist einfach das Konzept einer Sprache, also das theoretisch mögliche. Denn Java erlaubt Mehrfachvererbung nicht. Man kann zwar versuchen, extends zwei oder mehr Klassen zu schreiben, aber dann wird der Compiler einen Fehler generieren.

Da nur einmal kurz zur Spezifizierung:
Die Aussage ist nur für Klassen gültig. Java erlaubt Mehrfachvererbung von Interfaces:

Classes and interfaces support multiple inheritance from interfaces. A class that implements one or more interfaces may inherit instance methods from both its superclass and its superinterfaces.

JLS - bereits im Kapitel 1 - in denKapiteln 8.1.5 und 9.4.1.2 ist dazu mehr zu finden.

@Barista Oder ist das im Bytecode möglich? Weißt du da was? Also ist das theoretisch vorgesehen?

Nein, im Bytecode ist genau eine Superclass vorgesehen:
Chapter 4. The class File Format (oracle.com)

 

[M.L.]

Spezifikationsebene und Implementierungsebene

neben der JLS könnte ein Zitat aus dem obigen Link (runterscrollen bis etwa zur Hälfte) weiterhelfen: "...

• Klassen, die eine Implementierung ihrer Spezifikation enthalten können, die sowohl in Java als auch in C# mit dem Schlüsselwort class deklariert und daher einfach nur »Klasse« genannt werden.

• Klassen, die nur die Spezifikation ihrer Schnittstelle enthalten dürfen. Sie werden einfach nur »Schnittstellen« genannt und mit dem Schlüsselwort interface deklariert. ..."

 

[philanthrop]

Aber Realisierung eines Interfaces ist doch etwas anderes als Vererbung einer Klasse ... auch wenn es technisch gesehen Ähnlichkeiten geben mag. Ich würde die Realisierung oder Konkretisierung mehrerer Interfaces deshalb nicht als Mehrfachvererbung sehen. Aber vielleicht ist genau das damit gemeint. Mehrere Interfaces kann es geben, klar. MWn darf es dann die Implementierung einer Methode mit gleicher Signatur aber höchstens einmal geben.

 

[KonradN]

Aber Realisierung eines Interfaces ist doch etwas anderes als Vererbung einer Klasse ... auch wenn es technisch gesehen Ähnlichkeiten geben mag. Ich würde die Realisierung oder Konkretisierung mehrerer Interfaces deshalb nicht als Mehrfachvererbung sehen. Aber vielleicht ist genau das damit gemeint. Mehrere Interfaces kann es geben, klar. MWn darf es dann eine Methode mit gleicher Signatur aber höchstens einmal geben.

Ja, das ist die Problematik mit ungenauen Begriffen. Daher greife ich bei Java immer sehr gerne zur JLS und nutze die Begriffe dort, denn da ist durch den Kontext klar, was gemeint ist. Sobald man von den Begriffen abweicht - und sei es nur eine Übersetzung - wird es schnell problematisch.

Das ist auch bei der ursprünglichen Fragestellung mit Spezifikationsebene und Implementationsebene ebenso. Eine Klasse hat ja auch eine Spezifikation (Z.B. ist das ein Begriff, der bei der Javainsel zu finden ist). Daher muss es da auch eine Art Spezifikationsebene geben bei der Klasse. Das macht eine Aussage wie:

Mehrfachvererbung auf Spezifikationsebene ist in Java möglich auf Implementierungsebene allerdings nicht.

relativ problematisch und erklärt in meinen Augen auch die dadurch gestiftete Verwirrung.

Aber ja - ein Interface fügt nur eine Spezifikation hinzu. Daher ist es eine Aussage, die ich nicht abstreiten oder als falsch bezeichnen wollte. Nur eben die Begriffe sollten klar definiert werden.

 

[philanthrop]

Btw: Hier wird sehr ausführlich einmal durchgespielt, welche Probleme auftreten könnten, wenn Java Mehrfachvererbung erlauben würde:

Code 360 by Coding Ninjas

www.codingninjas.com

Ich würde sagen, die Aufgabenstellung wurde einfach ungünstig formuliert.

 

[philanthrop]

Aber ja - ein Interface fügt nur eine Spezifikation hinzu. Daher ist es eine Aussage, die ich nicht abstreiten oder als falsch bezeichnen wollte. Nur eben die Begriffe sollten klar definiert werden.

+1. Aber man kann von Studierenden ja schlecht erwarten, die komplette JLS auswendig zu lernen ... Denn sonst würden die ja nie produktiv werden können.

 

[KonradN]

+1. Aber man kann von Studierenden ja schlecht erwarten, die komplette JLS auswendig zu lernen ... Denn sonst würden die ja nie produktiv werden können.

Es geht auch weniger darum, dass die Leute die JLS kennen sondern mehr darum, dass die klaren Begriffe verwendet werden. Und da ist meine Erwartungshaltung an Professoren und Dozenten, sich da an die Begriffe zu halten, die in der Java Welt üblich sind.

Aber zur "Ehr-Rettung" der Hochschule: Java ist da nur eine kleine Belanglosigkeit. Es wird halt aktuell Java verwendet. Die Sprache spielt aber keine Rolle sondern es sollen ja Konzepte und so verstanden werden. Da kann sowas durchaus wichtig und interessant sein. Es ist also immer eine Frage der Sichtweise. Hier konzentrieren wir uns natürlich auf Java und Java bildet einen Mittelpunkt und ist nicht nur ein Mittel zum Zweck und wir könnten jede andere Sprache nehmen, die ähnliche Konzepte umsetzt.

So kann man ja z.B. dart anschauen. Dort wird klar zwischen Spezifikation und Implementation unterschieden. Da kann man - so ich das richtig im Kopf habe (hab die Spezifikation vor 2 oder 3 Jahren gelesen aber nie gross etwas damit gemacht) - frei entscheiden, was man will: Spezifikation, Implementation oder beides. Ich kann also eine Klasse nehemen und wie gewohnt von dieser erben. Ich kann aber auch sagen: Ich will nur die Spezifikation - dann ist es wie ein Interface und ich muss alles neu implementieren. Aber man kann wohl auch nur die Implementation nehmen. Dann wird es nicht Teil der Spezifikation der eigenen Klasse aber ich habe dann die Methoden dieser Klasse in meiner zur Verfügung.

 

[philanthrop]

Aber zur "Ehr-Rettung" der Hochschule: Java ist da nur eine kleine Belanglosigkeit.

Ja, das wäre auch meine Argumentation gewesen. Es wird eine Vielzahl an Programmiersprachen an Hochschulen gelehrt, und Java bildet nur einen Teil davon. Das sollte eigentlich verständlich sein. Dennoch erfolgt die Vertiefung und Spezialisierung auf eine Programmiersprache idR erst später.

Es würde ja kaum sinnvoll sein, jemanden, der vielleicht Schwierigkeiten hat, eine einfache for-Schleife zu schreiben oder nicht weiß, was ein switch-case ist, zu sagen, er solle bitte den Syntaxbaum (vereinfacht) von Java wiedergeben ... (Nur ein Beispiel herausgegriffen, vielleicht auch etwas unpassend ...)

Und wenn man zwischen Unis und anderen Hochschulen unterscheiden möchte, hat man an Unis eher akademische Debatten, wohingegen an Hochschule der Praxisbezug mehr im Vordergrund steht. Beides ist natürlich wichtig, egal welchen Weg man gehen möchte.

Wies auch sei:

Mehrfachvererbung auf Spezifikationsebene ist in Java möglich auf Implementierungsebene allerdings nicht.

Ich würde beim Dozenten vielleicht einmal nachfragen, wie diese Aufgabenformulierung gemeint sei.