Forum: PC-Programmierung C++ globale Objekte erzeugen?


von Georg Fr. (Gast)


Lesenswert?

Hi,


ich möchte in einer Klasse ein Objekt der Klasse "BufferedASyncSerial
erzeugen und auf dieses auch aus einer anderen Klasse heraus zugreifen!

Ich hab da nun vieles von Singleton etc. gehört aber was muss ich nun 
wirklich machen? (Ich bin bzgl. C++ ziemlich grün! hab aber längere 
Erfahrung mit plain  ;) ).

1
try {
2
    
3
    BufferedAsyncSerial serial(m_stComPort, m_stBaudrate);
4
    serial.writeString("TESTAUSGABE\r\n");
5
    
6
    } catch(boost::system::system_error& e)
7
    {
8
    cout<<"Error: "<<e.what()<<endl;
9
    }

von Arne Maximilian R. (arnemaximilian_r)


Lesenswert?

Dann legst du einen oeffentlichen Zeiger in deiner Klasse an, auf den 
die anderen Klassen zugreifen koennen.

Was soll der Code? Geht es dir um eine Klasse fuer den asynchronen 
Buffer?

von Georg Fr. (Gast)


Lesenswert?

Arne Maximilian R. schrieb:
> Was soll der Code? Geht es dir um eine Klasse fuer den asynchronen
> Buffer?

Nein darum ging es mir nicht! Wie gesagt mir ist C++ noch ziemlich neu!

Aber nun schau ich mal nach öffentlichen Zeigern!

Vielen Dank!

von Karl H. (kbuchegg)


Lesenswert?

Georg Fr. schrieb:

> Ich hab da nun vieles von Singleton

Singleton löst ein anderes Problem.
Es geht um die Problemstellung, dass es von einer Klasse nur ein Objekt 
und nur ein einziges Objekt in einem Programm geben soll.

von Karl H. (kbuchegg)


Lesenswert?

Georg Fr. schrieb:

> ich möchte in einer Klasse ein Objekt der Klasse "BufferedASyncSerial
> erzeugen und auf dieses auch aus einer anderen Klasse heraus zugreifen!

Die allererste Frage lautet hier: Warum?

Eines der wesenetlichsten Grundprinzipien der objektorientierten 
Programmierung ist das Information Hiding in seiner scharfen Form in 
Form von Klassen und dem verstecken von Informationen in diesen Klassen. 
Eine Klasse ist für ihre Internals verantwortlich und lässt keine andere 
Klasse an diese Internals ran. Wenn die andere Klasse etwas von diesem 
BuffereASyncSerial Objekt will, dann soll es sich gefälligst an das 
Objekt wenden, welches dieses Objekt hält. Dieses haltende Vaterobjekt 
vermittelt dann die entsprechenden Aufrufe an die Methoden des Serial 
Objektes.

Einen Zeiger auf ein Member rausrücken - da kannst du dir 
Objektorientierung auch gleich sparen. Denn genau das will man nicht 
tun.

von Amöbenrolf (Gast)


Lesenswert?

Arne Maximilian R. schrieb:
> Dann legst du einen oeffentlichen Zeiger in deiner Klasse an, auf den
> die anderen Klassen zugreifen koennen.

Ganz schlechte Idee. Dann besser gleich C verwenden.

Karl Heinz schrieb:
> Singleton löst ein anderes Problem.

Hmm... Wenn man das Ganze so auslegt, dass die Repräsentation einer 
(physischen) Schnittstelle genau einmal vorhanden und global verfügbar 
ist, wäre die Implementation als Singleton nicht so unüblich. Das 
"gobal" ist zwar kein Muss, aber meist der Fall.

von Arne Maximilian R. (arnemaximilian_r)


Lesenswert?

Amöbenrolf schrieb:
> Hmm... Wenn man das Ganze so auslegt, dass die Repräsentation einer
> (physischen) Schnittstelle genau einmal vorhanden und global verfügbar
> ist, wäre die Implementation als Singleton nicht so unüblich. Das
> "gobal" ist zwar kein Muss, aber meist der Fall.

Nur so als kleiner Tipp aber Singletons gelten mittlerweile als 
überholt, da sie auch einige Schwachstellen haben.

Darf ich präsentieren: Dependency Injection ( 
http://de.wikipedia.org/wiki/Dependency_Injection )

Ist sicherer in der Instanziierung und vereinfacht das Testen im 
V-Modell.

von Amöbenrolf (Gast)


Lesenswert?

Arne Maximilian R. schrieb:
> Nur so als kleiner Tipp aber Singletons gelten mittlerweile als
> überholt

Zumindest werden sie für viele Situationen nicht mehr empfohlen, 
richtig. Aber was hat das mit meiner Aussage zu tun? Ich schrieb 
lediglich als Antwort auf den Beitrag von Karl Heinz, dass die 
Vorgehensweise nicht ganz unüblich ist. Es war keine Empfehlung an den 
TO, es so zu machen; darum verstehe ich auch nicht ganz, was die 
belehrende Art und Weise deines Hinweises nun bedeuten soll.

von Arne Maximilian R. (arnemaximilian_r)


Lesenswert?

Öffentlicher Zeiger kann für Dependency Injection genutzt werden ;)

von Udo S. (urschmitt)


Lesenswert?

Arne Maximilian R. schrieb:
> Nur so als kleiner Tipp aber Singletons gelten mittlerweile als
> überholt,

Die die am lautesten "veraltet" schreien und bestimmte Methoden generell 
verteufeln sind meistens Theoretiker, die noch nie einen 
funktionierenden Code über 100 (1000) Dateien weiterentwickeln pflegen 
oder warten mussten, sondern nur kleine neue Projekte gemacht haben.

Ich habe mir Dependecy Injection in Form von Google Juice anschauen 
(müssen) und bin bis jetzt noch nicht davon überzeugt.
Man kauft sich einige Vorteile durch andere Nachteile und erst mal sehr 
viel mehr Komplexität und Unübersichtlichkeit ein.

Mein Spruch ist immer noch "keep it simple".

von Quack (Gast)


Lesenswert?

Amöbenrolf schrieb:
> darum verstehe ich auch nicht ganz, was die
> belehrende Art und Weise deines Hinweises nun bedeuten soll.

Er hat ein hippes Wort fuer eine uralte Technik gefunden und moechte es 
jetzt gerne benutzen.

von Arne Maximilian R. (arnemaximilian_r)


Lesenswert?

Udo Schmitt schrieb:
> Die die am lautesten "veraltet" schreien und bestimmte Methoden generell
> verteufeln sind meistens Theoretiker, die noch nie einen
> funktionierenden Code über 100 (1000) Dateien weiterentwickeln pflegen
> oder warten mussten, sondern nur kleine neue Projekte gemacht haben.

Da hast du leider Recht. Meine Erfahrungen mit Dependency Injection ist 
nicht wirklich doll und mehr theoretischer Natur (hatte nach dem Vortrag 
kein Projekt mehr mit Objektorientierung :/ ).
Aber gerade Kernpunkte hören sich für die Wartung und das Testen des 
Systems besser an, als ein Singleton mit festen Abhängigkeiten, die man 
irgendwie für einen Unit Test aushebeln muss. Also ich versuche 
mittlerweile zumindest die Grundlagen des Konzeptes in meine Arbeit 
einfließen zu lassen. Teilweise nicht sehr einfach aber selbst bei VHDL 
macht es die Komponenten besser testbar.

von Amöbenrolf (Gast)


Lesenswert?

Arne Maximilian R. schrieb:
> Öffentlicher Zeiger kann für Dependency Injection genutzt werden ;)

Witzbold ...

von Karl H. (kbuchegg)


Lesenswert?

Amöbenrolf schrieb:

> Hmm... Wenn man das Ganze so auslegt, dass die Repräsentation einer
> (physischen) Schnittstelle genau einmal vorhanden und global verfügbar
> ist, wäre die Implementation als Singleton nicht so unüblich.

Durchaus.

> Das
> "gobal" ist zwar kein Muss, aber meist der Fall.

Mich hat das "in einer Klasse ein Objekt der Klasse "BufferedASyncSerial
erzeugen und auf dieses auch aus einer anderen Klasse heraus zugreifen!" 
gestört.

Man kann natürlich die übergeordnete Klasse als eine Art Resource 
Manager auffassen. Aber dann hat die ja sowieso dieses eine Objekt vom 
BuffereASyncSerial in der Verwaltung. OK, man kann das als eine Art 
Singleton auffassen. Aber so richtig üblich ist das meiner Meinung nach 
nicht. Ein Singleton ist eine Klasse, die auf sich selbst insofern 
aufpasst, dass es nur 1 Objekt geben kann, was von vorne herein eine 
gewisse Globalität verlangt.

: Bearbeitet durch User
von Georg Fr. (Gast)


Lesenswert?

Ok ich hab mich nun doch entschlossen, das Objekt auch erst in der 
Klasse zu erstellen, in der ich es benötige.
Dazu brauchte ich lediglich eine weitere Methode zum Konfigurieren des 
ComPorts aus einer XML-Datei hinzufügen (mit QtObject etc...)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.