Ich glaub nicht. Ich will nicht die Vererbung von Foo oder Bar verhindern. Ich möchte ein public-Interface, welches bereits in der Basisklasse implementiert ist (weil der Basiskram da drin für alle abgeleiteten Klassen sinnvoll ist) und nur ein kleiner Bruchteil soll dann aus diesem public-Interface über eine abstrakte/virtuelle private Methode realisiert werden, die die erbenden Klassen implementieren. Diese sollen von außen nicht direkt aufgerufen werden (da sie nur im Zusammenspiel mit dem public-Interface Sinn ergeben).
Was soll den deiner Meinung nach passieren, wenn du "nur" eine Base referenz hast? Du aber in der dahinter liegenden Kind klasse das interface von Base in private verwandelt hast? Das macht keinen Sinn und ist daher nicht möglich.
aber C# verbietet leider auch virtuelle protected Methoden. Das hätte ich vielleicht dazu sagen sollen.
Das wäre mir neu. Natürlich können protected methoden virtual sein. Aber logischweise muss dann die das override auch protected sein.
Zuletzt geändert von dowhilefor am 29.02.2012, 12:37, insgesamt 1-mal geändert.
Mein Gehirn besteht nur noch aus einem hash-index, ich weiss was ich kenn aber kenn nicht was ich weiss
Das Interface bleibt doch public, weil ich es gar nicht in den abgeleiteten Klasse anpacke (es ist ja nicht virtual). Ich überschreibe doch nur die protected-Methode, die von außen eh nicht erreicht werden kann.
@Artifical Mind: Hmm prinzipiell ja. Aber ob das in jedem Fall sinnvoll ist? Naja wäre erstmal eine Lösung.
aber C# verbietet leider auch virtuelle protected Methoden. Das hätte ich vielleicht dazu sagen sollen.
Das wäre mir neu. Natürlich können protected methoden virtual sein. Aber logischweise muss dann die das override auch protected sein.
Ja das war wohl falsch formuliert. Ich hab leider grad keinen Compiler da, mir schwirrte nur die Fehlermeldung im Kopf rum, wo auch irgendwas von protected stand. Hab mich aber mal informiert und scheinbar geht es mit protected (zum Glück).
Von aussen ist relativ. Es können ja auch protected methoden von anderen klassen aufgerufen werden, wenn sie die selbe Basisklasse haben. Fakt ist das interface schreibt protected vor, dann darf die eigentliche implementierung das nicht ändern.
Mein Gehirn besteht nur noch aus einem hash-index, ich weiss was ich kenn aber kenn nicht was ich weiss
BeRsErKeR hat geschrieben:@Artifical Mind: Hmm prinzipiell ja. Aber ob das in jedem Fall sinnvoll ist? Naja wäre erstmal eine Lösung.
Wieso sollte das denn nicht sinnvoll sein? Da es in der Base-Klasse protected ist, kann es von allen abgeleiteten Klassen gesehen und überschrieben werden, so wie du das ja auch machst. Wenn du irgendwann nicht mehr willst, dass es weiter überschrieben wird, machste halte sealed davor. Aber warum du die Sichtbarkeit von protected auf private einschränken willst, weiß ich nicht.
EDIT: ich habe das gerade nochmal ausprobiert, protected virtual geht prima ;) Benutze ich in CyberDive sogar an einigen Stellen.
BeRsErKeR hat geschrieben:@Artifical Mind: Hmm prinzipiell ja. Aber ob das in jedem Fall sinnvoll ist? Naja wäre erstmal eine Lösung.
Wieso sollte das denn nicht sinnvoll sein? Da es in der Base-Klasse protected ist, kann es von allen abgeleiteten Klassen gesehen und überschrieben werden, so wie du das ja auch machst. Wenn du irgendwann nicht mehr willst, dass es weiter überschrieben wird, machste halte sealed davor. Aber warum du die Sichtbarkeit von protected auf private einschränken willst, weiß ich nicht.
Ok verzeiht mir mein Unwissen. Ich mach noch nicht lange C#. Dachte dass sealed nur auf Klassen anwendbar ist. Das erübrigt natürlich den Wechsel von protected auf private, wie es in C++ z.B. dann sinnvoll gewesen wäre. Mir gings halt prinzipiell darum, dass ich das nicht endlos an alle abgeleiteten Klassen "überschreibbar weitergebe".
Artificial Mind hat geschrieben:EDIT: ich habe das gerade nochmal ausprobiert, protected virtual geht prima ;) Benutze ich in CyberDive sogar an einigen Stellen.
Ja hab mir grad mal ne VM mit Visual C# besorgt und getestet. Mit protected klappts, auch genau in der Form wie ich's brauche (also abstract).
BeRsErKeR hat geschrieben:Ok verzeiht mir mein Unwissen. Ich mach noch nicht lange C#. Dachte dass sealed nur auf Klassen anwendbar ist. Das erübrigt natürlich den Wechsel von protected auf private, wie es in C++ z.B. dann sinnvoll gewesen wäre. Mir gings halt prinzipiell darum, dass ich das nicht endlos an alle abgeleiteten Klassen "überschreibbar weitergebe".
Ja kein Problem, ich hatte extra den MSDN Link geschickt weil die dort sogar in ihrem Beispiel eine einzelne Funktion mit sealed markieren ;) Wahrscheinlich hätte ich den Link nicht "sealed" nennen sollen oder etwas mehr dazuschreiben oder so^^
