r2ls

Hallo,

ich habe eine Klasse A mit den Funktionen F1, F2, F3.

Jetzt erstelle ich die Klasse B und erbe von der Klasse A. In der Klasse B soll aber nur der Zugriff auf Methode F1 möglich sein, nicht auf F2 und F3.

Kann ich das mit PHP umsetzen?

Mister Ad

ragtek

HM, was sllte dsa bringen?

Möglichkeiten:

Methode F1 als private oder public deklarieren
F2 und F3 als protected (dann werden sie nicht weitervererbt)

nikosch

Stimmt nicht. protected wird vererbt.Das bringt nichts. Nachträglich auf private setzen verletzt die Schnittstelle und ist syntaktisch verboten.

Ein Möglichkeit wäre, Die Methoden mit Dummys zu überschreiben (leere Funktionalität) oder mit Methoden, die bspw. eine Exception werfen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

jw-lighting

Du verwechselst protected mit private und vice versa.

Geschützte (protected) Funktionen werden mit vererbt, sind aber auch dort nur innerhalb der Klasse verfügbar.
Private Methoden werden nicht vererbt und sind ebenfalls nur innerhalb der Klasse verfügbar.

Vom Design her wäre es schlauer, eine abstrakte Klasse zu definieren die die Schnittmengen zwischen beiden anderen Klassen darstellt, und diese dann zu erweitern.

EDIT: nikosch war schneller..

LG:
jw-lighting

__________________

ragtek

Ups sorry.

Aber wieso verletze ich die Schnittstelle?
Vlt ist es ja nicht beabsichtigt, dass die 2 von aussen aufgerufen werden sollen.

Persönlich finde ich das nachträgliche überschreiben viel grausamer.
Wenn sie nicht verfügbar sein soll, dann soll die Elternklasse dafür sorgen.
Wozu soll eine Methode in einer Kindsklasse verfügbar sein, wenn diese nicht aufrufbar sein darf.

Das einzige Szenario wo ich mir sowas vorstellen könnte, wäre eine API wo etwas gravierendes geändert wurde und man nun bitte Methode / Klasse xyz verwenden soll.
Das ist halt meine Sichtiweise.

ChrisB

Wenn du ein Haustier haben willst, das zwei Beine und zwei Flügel hat - dann solltest du es nicht von zwei Säugetieren zeugen lassen.

Wenn deine Kindklasse etwas bestimmtes nicht können/dürfen soll - wieso soll sie dann bitte überhaupt von einer Elternklasse erben, die diese Fähigkeiten hat?

„Säugetier“ und „Vogel“ leiten sich beide von „Lebewesen“ ab.
Du willst aber offenbar „Vogel“ von „Säugetier“ ableiten.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

cycap

Was Chris damit meint wäre

Klasse A mit F1
Klasse B erbt von A und definiert F2, F3
Klasse C erbt von A und definiert F4

jw-lighting

Ich nehme an, du (TE) hast das bisher nicht gemacht/machen wollen da du für 'Lebewesen' keine eigene Verwendung hast.

Um das Problem zu lösen gibt es, wie ich angesprochen hatte, die Möglichkeit eine Klasse (oder auch Methoden) als abstrakt zu definieren, d.h. das sie eine Grundlage darstellt die von Kindklassen erweitert werden MUSS, und so noch nicht instanziert werden darf.

LG

__________________

r2ls

ich dachte an sowas wie sealed in c#, aber das verhindert auch nur weiteres überschreiben.

über Klasse A sitzt noch eine abstrakte Klasse und ein Interface mit jeder Menge Logik. Es sind bereits alle Methoden F1, F2, F3 im Interface defniert. Dann müsste man die Struktur doppelt anlegen und die ganze Logik davon auslagern (automatisches Suchen von Klassenpfaden, viel statisches).

Ich werde dann wohl doch auf die unschönere Methoder gehen und leer überschreiben.

nikosch

Weil eine einmal publizierte Methode nicht nachträglich eingeschränkt werden darf. Wenn A::foo() public ist und B:foo() private (B extends A), dann beendet B effektiv den weiteren Vererbungsbaum. Allgemeiner gefasst stellte dann jede Vererbung einer Vererbung eine potentielle Entwertung des Objekts dar. Stell Dir nur mal vor, Du gibst als Type-Hint A an, dann kannst Du B zwar übergeben, aber effektiv kann der Kontext trotzdem nicht sicher sein, dass die Schnittstelle noch konsistent ist, weil es eben B:foo() gar nicht mehr aufrufen könnte. Noch klarer wird das bei der Verwendung von Interfaces. Wenn A ein Interface mit foo() bedient, würde B (das ja die Implementierung erbt) nicht mehr das Interface repräsentieren (bzw. anders herum).

Dann sollte man eben auch nur F1 als Schnittstelle definieren und den Rest entweder protected anlegen oder nur eine Ableitung zwischenschieben.

Nein das ist falsch. Die Elternklasse weiß ja nicht, dass sie Elternklasse ist. Ergo auch nichts über die Kinder, erst recht nicht über implementierte Funktionalitäten. Im Übrigen kann es durchaus sinnvolle Anwendungen für Methoden geben. Nimm das Beispiel „Automat wechselt nicht“. Briefmarkenautomat extends Selbstbedienungsautomat. gebeWechselgeld() ist dann eben eine Dummymethode, die aber trotzdem das Interface bedient, auf das vielleicht ein Objekt Automatentastatur oder Automatenprozessor aufsetzt.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--