Operation VOR Superkonstruktor

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

Bluesmaster

Forum-Century


	Beiträge: 203

	Anmeldedatum: 13.11.11

	Wohnort: Gera

	Version: 2012a

Verfasst am: 29.06.2012, 10:33 Titel: Operation VOR Superkonstruktor

Ich habe ein verzwicktes Problem,

Ich habe ein Anzahl von Kindklassen mit speziellen Properties,
nennen wir sie XXX. Allen ist eine Methode f(XXX) gemeinsam, die
von den Properties XXX abhängt.

Es wäre also sinnvoll die Methode f(XXX) zentral im Superkonstruktor
aufzurufen. VORHER müssten die Properties aber INDIVIDUELL geprüft und verarbeitet werden. Das geht aber nicht VOR dem Superkonstruktor weil das Objekt zu diesem Zeitpunkt noch nicht existiert.

Wie komme ich aus diesem Dilema (siehe Bild) wieder heraus?

Vielen Dank

Blues

Scan0001.jpg

Beschreibung:

Dilema

Download

Dateiname:

Scan0001.jpg

Dateigröße:

29.05 KB

Heruntergeladen:

1198 mal

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 29.06.2012, 11:12 Titel:

Das müsste sich dadurch lösen lassen, wenn Du die Properties und die Methode als "protected" deklarierst in der Parentklasse deklarierst. Dann in der abgeleiteten Klasse die Überprüfung einfügt und die Properties zuweist und Ende des Konstruktors die Methode aufrufst

Bluesmaster

Themenstarter

Forum-Century


	Beiträge: 203

	Anmeldedatum: 13.11.11

	Wohnort: Gera

	Version: 2012a

Verfasst am: 29.06.2012, 12:12 Titel:

Ich könnte die Methode im Konstruktor JEDER KINDKLASSE am Ende aufrufen. Aber es sind viele, und für alle identisch.

Es ist mehr so eine Prinzipfrage:

Kann ich etwas individuelles tun BEVOR ich das tue was allen Objekte
gemeinsam ist (Der eigentliche Sinn der Vererbung)

Beispiel:

Klasse Quatrat und Kreis erben von Figur

Beide haben die Property "Fläche" die von "calcFläche" ausgerechnet
wird. Rechteck macht das mit seiner Property "Seitenlänge" und Kreis mit "Radius".
Günstig wäre es "calcFläche" in Figur aufzurufen, da es sowie so für beide
oder (tausende andere) gemacht werde muss. Aber das geht nicht weil
zuerst "Radius" oder "Seitenlänge" übernommen werden müssten.

Gut man könnte sagen das geht eben nicht. Aber ich hab mich hier im
Forum schon oft inspirieren lassen Wink

Gruß

BLues

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 29.06.2012, 12:21 Titel:

Es ist natürlich etwas schwer das sich jetzt genau zu überlegen, weil wir das Problem nicht im Detail kennen.

Aber bei Deinem Bespiel würde man das "calcFläche" abstrakt in der Superklasse definieren und jede Kindklasse muss es dann implementieren und ggf im Konstruktor aufrufen. Hier würde ich aber, sofern die Daten nach Erzeugung unveränderbar sind, die Berechnung direkt in den Konstruktor der Kindklasse einfügen.
Im Beispiel der Fläche ist es ja so, dass nur die Kindklasse weiß welche Daten es benötigt und wie die Fläche zu berechnen ist, d.h. die Basisklasse hat dieses Wissen nicht und somit wäre es auch falsch dieses in die Basisklasse einzufügen. Benötigst Du trotzdem eine Methode, die in allen Kindklassen individuell implementiert sein muss, dann gehört sie als abstrakte Methode in die Basisklasse und wird dann in jeder Kindklasse individuell überladen.

Das der Superkonstruktor vor dem Konstruktor der Kindklasse aufgerufen wird, ist schon korrekt, d.h. aber auch wenn Du Daten hast, die der Superkonstruktor verarbeiten muss, dann müssen die Überprüfungen in den Superkonstruktor.
Du versuchst gerade eine individuelle Struktur der Kindklasse generisch mit Hilfe der Basisklasse zu implementieren, das widerspricht aber der OOP, denn eine abgeleitete Klasse ist eine "Verfeinerung der Basisklasse".
Wenn Du eine Methode für alle Kindklassen brauchst, dann muss sie entweder abstrakt sein oder Du musst sie so implementieren, dass sie generisch mit allen Daten umgehen kann. In diesem Fall kannst Du dann in der Kindklasse entscheiden, ob Du die generische der Superklasse nimmst oder individuell überlädst.

Bluesmaster

Themenstarter

Forum-Century


	Beiträge: 203

	Anmeldedatum: 13.11.11

	Wohnort: Gera

	Version: 2012a

Verfasst am: 29.06.2012, 13:08 Titel:

Hallo flashpixx,

Danke für deine Überlegungen. Ganz kurz:

Ja, die Methode ist abstrakt, und die Kinder überschreiben sie.

Es geht allein um das AUFRUFEN im Superkonstruktor.
Ich will einfach "Peace of Mind", dass für jede Kindklasse die ich später
noch schreibe klar ist, dass diese Methode AUFGERUFEN wird und ich es
nicht etwa vergesse in deren Konstruktor zu schreiben.

(Es geht um viele Kindklassen und viele solcher Methoden, ich möchte
auf die Art die Komplexität senken)

Hat jemand eine Idee? Ich würde mich sehr freuen.

* Ich hatte die Idee einen Timer zu platzieren der das macht kurz nach dem der Superkonstruktor durch ist, aber das scheint mir zu unsicher und zu experimentell

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 29.06.2012, 13:38 Titel:

Naja Du hast ja im Konstruktor der Kindklasse eine Referenz auf das Kindobjekt, Du kannst ja dieses Objekt einfach dem Aufruf des Superkonstruktors mitgeben oder einer protected Methode der Superklasse, die dann entsprechend arbeitet.

Code:

classdef myChildClass < myParentClass

function this = myChildClass(varargin)
this@myParenClass(this)

Funktion ohne Link?

in dem Konstruktor der ParentClass kannst Du dann mit isa abprüfen um welche Kindklasse es sich handelt. Finde ich jetzt persönlich vom Designaspekt nicht schön, weil es irgendwie sehr schwierig zu verstehen ist.

Ich habe ein ähnliches Problem etwas anders gelöst: Es ging darum, dass ich mehrere Körper erzeugen muss wobei Volumen, Dichte und Maße des Körpers eben unterschiedlich waren. Was letztendlich dazu geführt hätte, dass ich eine Basisklasse und eben für jeden speziellen Körper eine Kindklasse haben muss. Ich habe auf die Kindklassen verzichtet. Es gibt eine Klasse Koerper, die als Parameter den Namen des Körpers bekommen und den dazugehörigen Berechnungscode aus einer Datenbank lädt und ausführt. isa Funktionen sind dann in der Klasse überladen, so dass sie eben abhängig von dem geladenen Körper auch die richtigen Ergebnisse liefert.
Damit kann ich dann letztendlich flexibel neue Körper erzeugen, ohne ständig neue Klasse generieren zu müssen. Einen neuen Körper erzeuge ich dann durch einen neuen Eintrag auf der Datenbanktabelle mit den entsprechenden Matlabcode. Natürlich kommt hier eval zum Einsatz, was generell nicht so schön ist, da aber eval hier nur eine einfache Funktion wie z.B. Hoehe*Breite*Tiefe ausführt und das auch nur einmal im Konstruktor ist das für mich zu verkraften und wird ggf mit try-catch abgefangen und ein sauberer Fehler produziert.

Bluesmaster

Themenstarter

Forum-Century


	Beiträge: 203

	Anmeldedatum: 13.11.11

	Wohnort: Gera

	Version: 2012a

Verfasst am: 29.06.2012, 14:24 Titel:

sind viele interessante Aspekte dabei, aber das entscheidende fehlt noch

Das Aufrufen der Kindmethode selbst vom Superkonstruktor ist nicht das
eigentliche Problem ( this@SuperConstructor(...) ) denn die Referenz
MUSS sogar (vor dem @) mitgegeben werden.

Mist ist blos, dass die entscheidenden Properties noch nicht da sind
(weil der this@super() Befehl an erster Stelle steht, also noch vor der
sachen wie this.property = varargin{1} )

Eine parametrierbare Klasse wie du sie vorgeschlagen hast ist zwar
denkbar aber passt für meine Bedürfnisse schlecht,
ich hab auch nichts gegen eval, im Maßen eingesetzt ist es ein
überaus mächtiges Werkzeug...

also falls noch jemand eine Idee hat wär das super

Gruß

Blues

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 29.06.2012, 14:56 Titel:

Was würde dagegen Sprechen, einfach die Parameter des Konstruktors der Kindklasse in den this@super(varargin) mit hineinzureichen?

Evtl wäre die Lösung des Problems darin zu finden, wenn Du die Ansätze passend kombinierst

Bluesmaster

Themenstarter

Forum-Century


	Beiträge: 203

	Anmeldedatum: 13.11.11

	Wohnort: Gera

	Version: 2012a

Verfasst am: 29.06.2012, 16:15 Titel:

die ParentClass müsste dann Fallunterscheidungen machen

Das führt die Sache ad absurdum, denn ich will ja Aufwand sparen und
Code in Kindklassen themengerecht kapseln

Ich werde wohl beim Klassiker bleiben und "calcFläche" in jeder
Kindklasse einzeln aufrufen

Vielen Dank trotzdem für deine Mithilfe,
wenn mir noch was einfällt poste ich es später

Gruß

Blues


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2024 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.