Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

"Data-hiding" mittels modulen against Singletons

Werbeanzeige

muin gelir

Treue Seele

  • »muin gelir« ist der Autor dieses Themas

Beiträge: 319

  • Private Nachricht senden

1

12.11.2003, 17:18

"Data-hiding" mittels modulen against Singletons

Hi,

weil hier, im C++Forum, schon lang nix mehr los war, will ich jetzt mal eine kleine Diskussion starten.
"Data-hiding" mittels modulen against Singletons

Wer Davids Buch gelesen hat, kennt die tbDirect3D-Klasse! David hat dort alle Elemente statisch gemacht, damit wir kein Objekt brauchen um die Methoden aufzurufen. Na super, wozu hat er dann überhaupt eine Klasse gemacht? Ganz einfach! Alle diese Methoden gehören irgendwie zusammen! Allerdings gibt es "elegantere" Methoden als Davids statische Klasse.

1. Eine Singletonklasse, d.h eine Klasse von dem es nur eine Instanz geben darf!
2. Ein Modul mit "Data-hiding"



zu 1: (Singleton)

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14

//datei: musterD3D.h
class ST_D3D
{
public:
    bool Init(...);
    static ST_D3D GetInstance();
    //...
 private:
    ST_D3D();

    int heigth;
    int width;
    //...
};

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11

//datei: musterD3D.cpp
bool ST_D3D::Init()
{
    //...
}

static ST_D3D ST_D3D::GetInstance()
{
    static ST_D3D lonely;
    return lonely;
}



zu 2: "Data-hiding" mittels Modulen:

Quellcode

 
1
2
3
4
5
6

//datei: DHM_D3D.h
namespace DHM_D3D
{
    bool Init(...);
    //...
}

Quellcode

 
1
2
3
4
5
6
7
8

//date: impl_DHM_D3D.h
#include"DHM_D3D.h"

namespace DHM_D3D
{
    int width;
    int height;
}

Quellcode

 
1
2
3
4
5
6

//datei: DHM_D3D.cpp
#include"impl_DHM_D3D.h"
bool DHM_D3D::Init(...)
{
    //...
}

Dem user darf dann nur die Datei DHM_D3D.h zur verfügung gestellt werden, damit er keinen Zugriff auf die Variablen hat.



Was haltet ihr von der ganzen Sache??
Ein Gespenst geht um in Europa...

Bastian

Frischling

Beiträge: 22

  • Private Nachricht senden

2

12.11.2003, 20:24

mmmh....ich bevorzuge klar das Singleton verfahren, weil ich das andere nicht verstehe ;)

Also Du willst eine globale Funktion einfach in einen Namespace packen und dem User nur den Header mit den Funktionen geben, nicht aber den mit den Daten?
Wenn das so funktioniert ist das sicherlich auch eine möglichkeit.
Aber wie willst Du das anstellen das man doch das D3D Device Objekt bekommt???
Du müsstest eine Funktion in DHM_D3D.h haben die das Objekt aus impl_DHM_D3D.h zurückgibt und schon hätte der User wieder etwas aus der eigentlich nicht benutzbaren Struktur....
und müsstest zusätzlich, damit der Compiler nicht meckert, die Datei impl_DHM_D3D.h einbinden.

Naja ich würde Singletons nehmen. Damit holt man sich dann einfach eine Referenz auf die Klasse von überall her und fertig.
Und mit nem Reference Counting System kann man noch die Sicherheit erhöhen.
Das einzige was dagegen spricht ist, dass der User sich wirklich daran halten muss immer getInstance() und Release() aufzurufen.

Gruß
Bastian

PS ich hoffe ich hab das Data Hiding mit Modulen richtig verstanden 8)

muin gelir

Treue Seele

  • »muin gelir« ist der Autor dieses Themas

Beiträge: 319

  • Private Nachricht senden

3

12.11.2003, 21:36

Zitat von »"Bastian"«


PS ich hoffe ich hab das Data Hiding mit Modulen richtig verstanden 8)

Nein, hast du nicht.

Zitat von »"Bastian"«


Also Du willst eine globale Funktion einfach in einen Namespace packen und dem User nur den Header mit den Funktionen geben, nicht aber den mit den Daten?

Naja, was heißt globale Funktion in einen Namensbereich packen. Entweder ist sie statisch oder global!
Ja natürlich nicht mit den Daten, sonst hätte er ja zugriff darauf. Das selbe wie private bei Klassen.

Zitat von »"Bastian"«


Aber wie willst Du das anstellen das man doch das D3D Device Objekt bekommt???
Du müsstest eine Funktion in DHM_D3D.h haben die das Objekt aus impl_DHM_D3D.h zurückgibt und schon hätte der User wieder etwas aus der eigentlich nicht benutzbaren Struktur....

Nicht benutzbar? Nicht sichtbar! Die Funktionen können drauf zugreifen, weil sie sie "sehen". Das ist genau das selbe wie private bei Klassen.

Zitat von »"Bastian"«


und müsstest zusätzlich, damit der Compiler nicht meckert, die Datei impl_DHM_D3D.h einbinden.

:rolleyes: falsch. siehe oben!

Zitat von »"Bastian"«


Naja ich würde Singletons nehmen. Damit holt man sich dann einfach eine Referenz auf die Klasse von überall her und fertig.

Bei den Namespaces musste dir nix holen, das spart auch nochmal was!
Ein Gespenst geht um in Europa...

Bastian

Frischling

Beiträge: 22

  • Private Nachricht senden

4

12.11.2003, 23:19

naja...
Aber wie gesagt. Ich würd die Klasse trotzdem als Singleton schreiben.
es ist, meiner Meinung nach(subjektiv!), besser zu lesender und zu verwendender Code, übersichtlicher(immerhin braucht man nur zwei Datein und nicht drei) und man behält alle OOP Features(Vererbung, Operator Überladungen für andere Klassen), man kann genau nachverfolgen welcher Programmteil denn nun die Render Klasse nutzt.
Außerdem sind sie auch wunderbar für API unabhängige Render-/Sound-/Networkinterfaces geeignet(Stichwort dynamisch geladene Plugins).
Das geht mit einer Funktion die eine Instanz einer Klasse zurückgibt deutlich einfacher als wenn man jede Funktion einzeln aus einem Plugin laden muss.
Andere Sache: wenn man später eine größere Engine schreibt die möglichst Flexibel sein soll. Z.B. für einen "Task"-Manager der alle möglichen Klassen übergeben bekommt und diese dann der Reihe nach ausführt, mit der Modul ansatzweise sehr schwer zu implementieren. Singleton: einfach von einer Grundklasse ableiten, eine Funktion die in der Grundklasse definiert werden muss(z.B. Execute) überschreiben und die Render Klasse wird automatisch vom Manager geupdated.
Ist nur ein Bsp. was mir grade so einfgefallen ist.


PS hast du zu dem Data Hiding mittels Modulen vielleicht irgendeinen Link? Ich hab das noch nie in einem Programmm oder Buch gesehen und irgendwie hab ich das Gefühl, das das nur eine Notlösung ist...aber ich laß mich gern eines besseren belehren

muin gelir

Treue Seele

  • »muin gelir« ist der Autor dieses Themas

Beiträge: 319

  • Private Nachricht senden

5

13.11.2003, 15:26

Ne, links hab ich nicht. Das ist aber eine Technik von Stroustrup persönlich :) die er auch in seinem Buch beschreibt!
Zu dem, mit den PlugIns kann ich nicht viel sagen, weil ich net genau weiß, wie das funktioniert.
Übrigens: Vererbung und überladen von Operatoren ist in Modulen auch möglich!
Ein Gespenst geht um in Europa...

Bastian

Frischling

Beiträge: 22

  • Private Nachricht senden

6

13.11.2003, 18:24

hmmm...na dann wird er sich dabei was gedacht haben ;) :)

muin gelir

Treue Seele

  • »muin gelir« ist der Autor dieses Themas

Beiträge: 319

  • Private Nachricht senden

7

13.11.2003, 19:58

ja, ich glaub auch :)
Ein Gespenst geht um in Europa...

Werbeanzeige