|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn ich in Java will, dass öffentliche Methoden der Superklasse in der Ableitung nicht mehr öffentlich sind, reicht es einen leeren private Methodenkörper von diesen Methoden in der Ableitung zu erstellen?
|
|
|
|
|
|
|
|
|
|
|
Probier es aus!
Spoiler - markieren, um zu lesen:
1. Ein ganz leerer Body würde keinen Sinn machen, du willst zumindest ein super.foo() darin.
2. Es funktioniert nicht, du kannst die Sichtbarkeit von Methoden in Unterklassen nicht verringern.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Redh3ad am 20.12.2010 10:46]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein, wie Redhead schon sagte -- Sichtbarkeit kann durch Ableitung niemals eingeschraenkt werden. Im Gegensatz zu C++ ermoeglicht Java keine private/protected Inheritance. Die Loesung in deinem Fall ist wahrscheinlich, nicht von der Klasse abzuleiten, sondern eine Wrapperklasse zu schreiben, die eine Instanz dieser Klasse als nicht-oeffentliches Feld enthaelt und nur Teile des Interfaces dieser Klasse sichtbar macht (und halt einfach weiterleitet).
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von igor]2 am 20.12.2010 10:59]
|
|
|
|
|
|
|
|
|
Ne, soll ja nur die Sichtbarkeit nach außen verringert werden, die Methoden sollen nur private werden quasi. Aber private Methoden, die die super.foo aufrufen müsste funktionieren thx. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von igor]2
Nein, wie Redhead schon sagte -- Sichtbarkeit kann durch Ableitung niemals eingeschraenkt werden. Im Gegensatz zu C++ ermoeglicht Java keine private/protected Inheritance. Die Loesung in deinem Fall ist wahrscheinlich, nicht von der Klasse abzuleiten, sondern eine Wrapperklasse zu schreiben, die eine Instanz dieser Klasse als nicht-oeffentliches Feld enthaelt und nur Teile des Interfaces dieser Klasse sichtbar macht (und halt einfach weiterleitet).
| |
Ich glaube Wegi will nur, dass bei der Benutzung der Child-Klasse eine public Methode der Super-Klasse des Childs nicht mehr sichtbar ist. Und nicht das die Sichtbarkeit der Super-Klasse direkt modifiziert wird.
|
|
|
|
|
|
|
|
|
|
|
|
Siehe auch hier, "simple composition" waere das Stichwort.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
| | Zitat von igor]2
Nein, wie Redhead schon sagte -- Sichtbarkeit kann durch Ableitung niemals eingeschraenkt werden. Im Gegensatz zu C++ ermoeglicht Java keine private/protected Inheritance. Die Loesung in deinem Fall ist wahrscheinlich, nicht von der Klasse abzuleiten, sondern eine Wrapperklasse zu schreiben, die eine Instanz dieser Klasse als nicht-oeffentliches Feld enthaelt und nur Teile des Interfaces dieser Klasse sichtbar macht (und halt einfach weiterleitet).
| |
Ich glaube Wegi will nur, dass bei der Benutzung der Child-Klasse eine public Methode der Super-Klasse des Childs nicht mehr sichtbar ist. Und nicht das die Sichtbarkeit der Super-Klasse direkt modifiziert wird.
| |
Richtig, aber genau das geht nicht, und dafuer gibt es auch einen Grund:
class Base {
public func { ... }
}
class Derived : Base {
private func { super.func(); }
}
das waere ja der Ansatz. Jetzt mache ich das:
Derived d = new Derived();
Base b = d; // zulaessig, weil "Derived" ja ein "Base" ist
b.func(); // Problem, Officer?
|
|
|
|
|
|
|
|
|
|
|
Oh.
| |
| Code: |
Base b = d; // zulaessig, weil "Derived" ja ein "Base" ist |
|
Diese Möglichkeit war mir gar nicht bewusst. Danke für den Hinweis, das sieht nützlich aus!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
Oh.
| |
| Code: |
Base b = d; // zulaessig, weil "Derived" ja ein "Base" ist |
|
Diese Möglichkeit war mir gar nicht bewusst. Danke für den Hinweis, das sieht nützlich aus!
| |
Und du bist hier Moderator.
|
|
|
|
|
|
|
|
|
|
|
|
Zu meiner Ehrverteidigung: Bewusst heißt: Ich weiß natürlich dass das geht, aber ich habe dieses Wissen in diesem Fall nicht angewendet!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
Zu meiner Ehrverteidigung: Bewusst heißt: Ich weiß natürlich dass das geht, aber ich habe dieses Wissen in diesem Fall nicht angewendet!
| |
OK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fuck, das war mir auch nicht bewusst.
Die Aufgabe ist es eine Klasse MyStack zu erstellen, die genau die Methoden: size, peek, pop und push zur Verfügung stellt.
Die Klasse soll aber eine Child-Class von RecursiveList sein, die verständlicherweise jede Menge public-Methoden bereit stellt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von WeGi
Fuck, das war mir auch nicht bewusst.
Die Aufgabe ist es eine Klasse MyStack zu erstellen, die genau die Methoden: size, peek, pop und push zur Verfügung stellt.
Die Klasse soll aber eine Child-Class von RecursiveList sein, die verständlicherweise jede Menge public-Methoden bereit stellt.
| |
Da das nicht gehen wird:
a) Du hast die Aufgabenstellung nicht verstanden.
b) Die Aufgabe ist mistig gestellt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von igor]2
| | Zitat von TriggerTG
| | Zitat von igor]2
Nein, wie Redhead schon sagte -- Sichtbarkeit kann durch Ableitung niemals eingeschraenkt werden. Im Gegensatz zu C++ ermoeglicht Java keine private/protected Inheritance. Die Loesung in deinem Fall ist wahrscheinlich, nicht von der Klasse abzuleiten, sondern eine Wrapperklasse zu schreiben, die eine Instanz dieser Klasse als nicht-oeffentliches Feld enthaelt und nur Teile des Interfaces dieser Klasse sichtbar macht (und halt einfach weiterleitet).
| |
Ich glaube Wegi will nur, dass bei der Benutzung der Child-Klasse eine public Methode der Super-Klasse des Childs nicht mehr sichtbar ist. Und nicht das die Sichtbarkeit der Super-Klasse direkt modifiziert wird.
| |
Richtig, aber genau das geht nicht, und dafuer gibt es auch einen Grund:
class Base {
public func { ... }
}
class Derived : Base {
private func { super.func(); }
}
das waere ja der Ansatz. Jetzt mache ich das:
Derived d = new Derived();
Base b = d; // zulaessig, weil "Derived" ja ein "Base" ist
b.func(); // Problem, Officer?
| |
Yes, problem.
"Cannot reduce the visibility of the inherited method from Base"
|
|
|
|
|
|
|
|
|
|
|
Ich nehme an explizite Interface Implementierungen gibt es in Java nicht?
Bsp:
| |
| Code: |
public abstract class Element
: IVisitable
{
void IVisitable.Assign(IVisitor visitor)
{
this.Assign(visitor);
}
protected virtual void Assign(IVisitor visitor)
{
if (null != visitor)
{
visitor.Visit(this);
}
}
}
|
|
Tatsächlich es sogar so, dass mir die Code Analyse nahelegt eine solche geschützte Implementierung anzubieten, wenn ich eine Interface Methode explizit implementiere. Die öffentliche Assign-Methode ist dabei nur sichtbar, wenn ich die Element-Instanz in eine IVisitable caste.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von WeGi
Fuck, das war mir auch nicht bewusst.
Die Aufgabe ist es eine Klasse MyStack zu erstellen, die genau die Methoden: size, peek, pop und push zur Verfügung stellt.
Die Klasse soll aber eine Child-Class von RecursiveList sein, die verständlicherweise jede Menge public-Methoden bereit stellt.
| |
Erstell eine Adapter-Klasse. Anders kannst du die Sichtbarkeit nicht verändern.
|
|
|
|
|
|
|
|
|
|
|
|
Was ist denn eigentlich diese RecursiveList?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Noch_ein_Kamel
Yes, problem.
"Cannot reduce the visibility of the inherited method from Base"
| |
Darum sach ich ja "geht nicht". 
|
|
|
|
|
|
|
|
|
|
|
Java hat ein paar merkwürdige Eigenschaften. Als ich gestern mit einem return vor dem Ende einer Methode testen wollte ob die bis dahin funktioniert, kam beim Ausführen vom Programm eine Fehlermeldung "Unreachable Code" und das Programm ist abgeschmiert. Klar darf der mich davor warnen, aber die ganze Ausführung verhindern? 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Danzelot
Java hat ein paar merkwürdige Eigenschaften. Als ich gestern mit einem return vor dem Ende einer Methode testen wollte ob die bis dahin funktioniert, kam beim Ausführen vom Programm eine Fehlermeldung "Unreachable Code" und das Programm ist abgeschmiert. Klar darf der mich davor warnen, aber die ganze Ausführung verhindern?
| |
Der Compiler sollte schon meckern.
Das es erst bei der Ausführung des Programms passiert bezweifel ich.
Mit if(1<2){ return ;} lässt dich der Compiler das übrigens kompilieren.
|
|
|
|
|
|
|
|
|
|
|
Gut zu wissen.
Jetzt erstmal dem Tutor aufs Dach steigen weil er das Übungsblatt fünf Stunden vor Abgabe des nächsten, darauf aufbauenden Übungsblattes korrigiert hat
|
|
|
|
|
|
|
|
|
|
|
|
UND er hat eine Zusatzaufgabe nicht angerechnet. Pah.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Danzelot
Gut zu wissen.
Jetzt erstmal dem Tutor aufs Dach steigen weil er das Übungsblatt fünf Stunden vor Abgabe des nächsten, darauf aufbauenden Übungsblattes korrigiert hat
| |
Du bist also einer von denen.
|
|
|
|
|
|
|
|
|
|
|
Musst ich auch grad denken 
|
|
|
|
|
|
|
|
|
|
|
Einer von wem?
/
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 20.12.2010 13:50]
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
![[dk]peacemaker](./avatare/[dk]peacemaker.gif)
