dämliche frage zu objektorientierung

copter

ich programmiere einen quadrocopter, in c++, objektorientiert.
oo verstehe ich hier als technik der modularisierung, andere werkzeuge (vererbung etc. benutze (brauche) ich nicht).
nun taucht im programm (main, aufgerufen von 200hz-timerinterrupt) folgendes problem auf :
die objekte müssen untereinander kommunizieren.

symbolisch gesagt :

klassen : a und b, methoden : a.methode und b.methode, attribute (public) : a.attribut und b.attribut
im programm dann die objekte : a_objekt und b_objekt (davon gibts rund 20)

frage : wie kann a_objekt.methode auf b_objekt.attribut zugreifen ??

- attribute als objekte, also "ineinander referenzieren" wird bei der vielzahl sehr unübersichtlich
- lauter variablen im main ... das kanns nicht sein
- ?????

Bradon

Wenn deine Objekte Module repraesentieren, die alle miteinander kommunizieren muessen, muss es natuerlich Referenzen geben.
Ich hab keine wirkliche Vorstellung davon, was du da alles fuer Objekte hast, aber mein erster Gedanke waer das Singleton-Pattern

copter

beispiel : eine klasse macht lageregler , eine andere klasse steuert motoren.

im programm : das motoren-objekt kriegt vom lageregler-objekt (davon gibts dann mehrere, für jede raumachse einen) stellwerte für die drehzahl.

"muß es natürlich referenzen geben" .. was heißt das in c++ ??

"singleton-pattern" ist wenn ich nicht irre die referenzierung in genau einem objekt. hab ich nicht, das sind immer mehrere objekte einer klasse.

Privacy

Bin auch Bradons Meinung das hier das Singleton-Pattern die richtige Problemlösung bietet. Alternativ kannst du auch die Objekte in der Main anlegen und .init(...) Methoden schreiben in denen alle (für diese Klasse) benötigten Referenzen übergeben werden und in der Klasse zwischengespeichert werden. Das gibt ein bisschen mehr Freiheiten, ist aber nicht unbedingt ganz so elegant lösbar.

Edit - Ausführlicher (Symbolischer Code):

Code

class Motorcontroller controller;


class Motor motor1;
class Motor motor2;
class Motor motor3;
class Motor motor4;


class Lageregler sensors;


controller.init(&sensors, &motor1, &motor2, &motor3, &motor4);

Alles anzeigen

Der Motorcontroller hat dann alles was er benötigt, er steuert die Motor-ESCs und erhält die Sensor-Daten von Beschleunigungs und Kreiselsensor.
Wenn du noch Steuerdaten vom Reciever einfließen lassen musst, übergibst du diese Klasse auch dem Controller.

copter

wie gesagt, sind immer mehrere objekte einer klasse. was bringt dann das singleton ?

die objekte werden alle in der main (übrigens auf einem atmega128) angelegt. nochmal (verzeiht die anfängerfrage !) ... was ist eine "referenz", die ich in der init-methode anlegen kann. kann ich ein (symbloisches) code-beispiel haben ?

Privacy

Code

class Motorcontroller {[INDENT]Lagesensor *sensorp;[/INDENT]
[INDENT]Motor *motor1p;[/INDENT]


public:[INDENT]Motorcontroller();[/INDENT]
[INDENT]void init(Lagesensor *sensorp, Motor *motor1p, ...);[/INDENT]
[INDENT]void tick(void);[/INDENT]


};


void Motorcontroller::init( Lagesensor *sensorp, Motor *motor1p, ... ) {[INDENT]this->sensorp = sensorp;
this->motor1p= motor1p;
//...[/INDENT]
}


void Motorcontroller::tick( void ) {[INDENT]//...[/INDENT]
[INDENT]motor1p->setSpeed(2000);[/INDENT]
[INDENT]//...[/INDENT]
}


void main(){[INDENT]Motorcontroller controller = new Motorcontroller();


Lagesensor sensor = new Lagesensor();
Motor motor1 =  new Motor();
//...


controller.init(&sensor, &motor1, ...);


while(1){ //100Hz or whateva
[/INDENT]
[INDENT=2]controller->tick();[/INDENT]
[INDENT]}[/INDENT]
}

Alles anzeigen

Solltest du aber nicht wissen was diese & oder * Operatoren machen, dann solltest du dir die C/C++ Grundlagen nochmal anschauen. Pointer sind in C++ und OOP unabdinglich.
http://www.proggen.org/doku.php?id=c:tutorial:pointer

Jegliche Syntaxfehler in meinem C++ Code sei mir verziehen.

Privacy

copter

erstmal : vielen dank für deine hilfe (deine zeit).
die syntax krieg ich auf die reihe, muß halt lesen ...

wenn ichs richtig verstehe (das ist mir das wesentlichste) :

ein pointer zeigert auf einen speicherplatz. da wird ein wert abgelegt, und kann dann in jedem beliebigen objekt wieder als pointer zugegriffen werden. der driekte zugriff auf die speicherzelle ohne variablen(-attribut)definition "umgeht" sozusagen das problem, daß die attribute nicht untereinander von den objekten zugegriffen werden können.

ich melde mich, wenn ichs syntaxtechnisch am schnürchen und getestet habe.

Privacy

Ja so in etwa. Eins der Probleme ist, dass eine Funktion in C nur Werte über die Argumente bekommen kann. Dein Objekt der Klasse "Motorcontroller" liegt auf einer Speicherstelle im uC-Speicher an der Adresse die du mit dem &-Opterator bekommen kannst. Diese Adresse ist ein einfacher Wert, der als Funktionsparameter übergeben werden kann. In der Funktion, wird dieser Pointer dann referenziert. Das geschieht über:

Code

pointer->var

Etwas vereinfacht ausgedrückt:
Eine Klasse ist nichts anderes als ein Bauplan eines Objektes. Welche Funktionen hat das Objekt, welche Variablen.
Das Objekt musst du anschließend erzeugen. Man kann aus dem Bauplan nicht einfach auf ein Objekt von einer anderen Klasse zugreifen. (So wie du das wohlt verstanden hast)

Zuerst erzeugst du die Objekte aus deinen Bauplänen und dann übergibst du den Objekten die Referenzen auf die anderen, gerade erzeugten, Objekte.

Du bekommst das schon hin, probier ein bisschen rum.

Privacy

copter

na ja, die grundlagen der objektorientierung hab ich glaub ich verstanden. pointer machen mir n paar probleme, in den "alten sprachen" (ich hab mal mit fortran angefangen vor 100jahren war sowas unüblich ..das krieg ich aber gebacken ... ich hadere eher mit den grundlagen.

als programmierkonzept ist das in meinen augen ein modularisierungswerkzeug. besser strukturiert als klassisch functions, procedures und all das. kapselung ist z.b. auch nur ein aspekt der modularisierung ...
folge von modularisierung ist in jeder technischen struktur dann kommunkationsbedarf. in module gegliederte funktionalitäten ziehen das unweigerlich nach sich.
aber : anders als in anderen modularisierungskonzepten fehlt hier ein sauberes konzept, die module (=objekte) dann auch kommunizieren zu lassen...

in meinen augen fehlt eine, übersichtliche, klar strukturierte funktionalität, um ein objekt mit einem anderen kommunizieren zu lassen.
(ich frage mich, wie das in objektorientierten konzepten der industrieanlagenprogrammierung läuft, da ist die modularisierung ja das kerngeschäft.)

... aber das werdet ihr hier als informatik-freaks sicher anders sehen. (...eben gar nicht als problem, stimmts ?)

Bradon

Jedes Modul braucht eine sauber definierte Schnittstelle, ueber die es benutzt werden kann. Bei einem Objekt in OOP waeren das die Methoden (und etwaige public Variablen)
Wenn du jetzt ein "uebergeordnetes" (z.B. ein Kontroll-) Modul hast, braucht das natuerlich Zugriff auf untergeordnete Module, das heisst, es muss diese irgendwie "ansprechen" koennen. Auf Hardwareebene geschieht dieser Zugriff z.b. ueber Stecker und Kabel, auf Softwareebene, wo alle Objekte im luftleeren virtuellen Raum schweben, eben ueber Referenzen.

Der Vorteil von dem ganzen: Abstraktion. Am Ende muss man nur dem "schlauesten" Modul einen Befehl geben wie "Flieg eine Rechtskurve". Dieses Modul kuemmert sich um die genaue Abarbeitung des Befehls, d.h. es sagt zum Beispiel dem einen Motormodul "Rotier etwas schneller" und dem anderen "Brems dich ein"

Vermutlich hilft dir die Erklaerung nichts, aber wenigstens hab ich mich wieder ein paar Minuten vor sinnvollen Taetigkeiten gedrueckt :o

Privacy

Zitat von copter

in meinen augen fehlt eine, übersichtliche, klar strukturierte funktionalität, um ein objekt mit einem anderen kommunizieren zu lassen.

Deswegen der Controller. Dieser bekommt Daten und kann Steuerbefehle umsetzen. Er hält auch die Referenzen auf die Module wie die Motoren oder den Sensoren.
Die Motoren und Sensoren haben Schnittstellen über die diese ausgelesen oder beschrieben werden können und der Controller kennt alle Beteiligten und nutzt deren Schnittstellen.

In der Praxis wird es auch genau so gemacht. Zum Teil aber mit Frameworks die mehr Übersichtlichkeit reinbringen. (Wenn auch net unbedingt auf uC)

copter

ich will ja nicht lästig sein, aber vielleicht habt ihr ja auch spaß am gedankenaustausch ..

übergeordnete module .. der controller ... eben nicht !

in modern strukturierten modularen system gibt es eben keinen zentralen "master" oder so, sondern eine einfache kommunikation zwischen hierarchisch gleichwertigen modulen ("peer-to-peer" sozusagen).
natürlich sind dazu an jedem modul saubere schnittstellen zu definieren, aber eben ... modulkommunikation untereinander (!) -> was hier bedeuten würde, objekte müßten gegenseitig ihre attribute (oder, mal phantasiert : "spezielle kommunikationsattribute") zugreifen können. gerne über get/set oder so.

ich les' mal, wie das die objektorientierte sps-technik macht ...

Bradon

Ich kann mir ehrlich gesagt nicht vorstellen, dass (uebertrieben gesprochen) das Gehirn eines Roboters auf gleicher Ebene "peer-to-peer" mit dem Fortbewegungsapparat oder den Sensoren oder was auch immer kommuniziert..

copter

das gehirn ist verteilt :

sensorik misst werte, prüft diese auf plausibilität, fusioniert manche, rechnet mit wahrscheinlichkeiten, filtert.
regler machen aus soll- und ist-werten neue steuerwerte, passen sich an situationen an, reagieren auf ereignisse.
antrieb gewichtet die einflüsse, vergibt prioritäten, verteilt steueraktionen angepasst an verschiedene motoren

..usw.

natürlich gibt es auch unterlagerte klassen (z.b. die reine motoransteuerung oder das lesen eines a/d-wanlders oder so...),
die kann man ohne strukturschwäche auch in anderen objekten referenzieren.

dazu kommen ein paar aufgaben, die sich nur als interruptroutinen lösen lassen, da versagt das oo-konzept völlig.

-------------------

ich denke es wird auf eine lösung rauslaufen, die sich an das sps-konzept des "prozessabbilds" anlehnt.
alle prozessrelevanten werte werden als variablen in main angelegt.

(trotzdem arbeite ich das pointer/referenzen-konzept mal aus)

copter

also, hab mich schlau gemacht (sps-messe in nürnberg) :

objektorientierte programmierkonzepte in der sps (=anlagen) - technik arbeiten mit globalen variablen, entsprechend dem "prozessabbild".
-> alle prozesswichtigen werte werden im hauptprogramm (hier main) als variable definiert. alle objekte können damit (und so auch "darüber") kommunizieren.
(wird als übersichtlicher und weniger syntaxintensiv beschrieben, ist auch kompatibler zu "alten" konzepten)

ich denke, diese argumente treffen auch für so kleine controller-applikationen wie meinen quadrocopter zu. alle prozessvariablen werden in main deklariert, und entweder als parameter für methoden benutzt oder (auch bei mehr als einem rückgabewert) direkt um den methodenaufruf rum übergeben. wird sehr übersichtlich !

so etwa :

nickregler.acc = sensor_4; //variable in attribut (eingänge, könnten auch parameter sein..)
nickregler.gyro = sensor_7;
nickregler.stabilisieren(); //methode
nickkorrektur = nickregler.stellwert //attribut in variable (ausgänge, bei nur einem ging's auch als rückgabewert)

die attribute sind, soweit sie kommunizieren müssen, public. ist ne m2m-kommunikation, die bei einem fehler (sensorausfall) sowieso das ende bedeutet. also, so what, private bringt nix.

(weiter : konstruktor wird im normalfall nicht benutzt (=default), außer wenn anfangswerte (höhe=0 oder ähnliches...) zu setzen sind)

Privacy

copter, es gibt unterschiedliche Wege ans Ziel. Das Controller-Konzept passt zum Mediator Pattern welches ein Behavioral pattern der Objektorientierten Programmierung ist.
http://en.wikipedia.org/wiki/Mediator_pattern

Was du hier vorschlägst klingt für mich typisch nach SPS-Programmierungen. Nämlich komplett wirr, nur solang Objektorientiert wie man Lust hat und wenns funktioniert simma alle glücklich.
Du brauchst die Klassen Motor, Sensor etc. dem Controller nicht übergeben, du kannst sie auch public in der Main speichern. (Angelehnt an das Singelton pattern welches von dir quasi auch vorgeschlagen wurde)

Das "so etwa" ist genau das was der Controller machen sollte. Ich glaube wir haben eine sehr getrennte Meinung was übersichtlich ist. xD
Dieses "Objekte an Methoden übergeben" beim Methodenaufruf ist die Technik wenn man keine wirklichen Objekte hat die selber speichern können was sie benötigen.
In C zB. macht man das.
Ich habe ein struct welches meine Variablen hält und übergebe es einer Methode die auf diesem struct arbeitet.

Code

struct ADC_TypDef;
uint16_t value;


void readADC(&ADC_TypeDef, &value);

dämliche frage zu objektorientierung

Maximilian Rupp 27. Dezember 2024 um 00:26

Jetzt mitmachen!