🚀 go-pugleaf

In <61qhJjBCr5B@devil.edition.bonbit.org> kay@edition.bonbit.org (Kay Hayen) writes:

>Sollte ich den Konstruktor von Kartendaten eher in zwei Teile aufspalten  
>und Initialisierungen der Unterobjekte in eine direkt nach dem Kostruktor  
>aufzurufende Memberfunktion "Init" verlegen ? Die Kartenobjekte koennten  
>dann ueber einen globalen Zeiger auf die Kartendaten zugreifen ? Den  
>koennte ich auch schon im Konstruktor setzen, aber Seiteneffekte von  
>Konstruktoren finde ich noch uneleganter.

Hm. Wenn diese Klasse wirklich nur ein Objekt hat, auf das von ueberall
drauf zugegriffen wird, finde ich es nicht schlimm es einfach (und
dreckig) global zu machen. Natuerlich ist das nicht die reine
objektorientierte Schule, aber doch relativ intuitiv und uebersichtlich
also in diesem Fall wohl vorzuziehen, oder?

Ich hatte dieses Problem auch schon oefter, und hab eigentlich immer
diese Loesung gewaehlt. Eine andere Moeglichkeit waere vielleicht die
Oberklasse friend zu den kleinen zu deklarieren. Ist aber eher
unuerbersichtlicher, oder?

Gruesse, Benni
-- 
http://www.uni-frankfurt.de/~benni/hello.html
"1024 Byte bilden ein Megabyte"
	aus einer Schrift des Bundesministerums fuer Wirtschaft zur
	"Informationsgesellschaft" 

Kay Hayen writes:
> ...Kartendaten, Kartenobjekte...

Ich versuchs mal (man nehme Cline/Lomow:"C++ FAQs" zur Hand...).

  FAQ 382: How is a static data member similar to a global variable?
  A static data member is like a global variable with a funny name
  that needn't be public.
  If your class has a static data member, there is only one copy
  of that datum even if there are many instances of the class. ...

-------------------------------------------------
class Kartendaten {...};

class Kartenobjekte 
{
public:
  static Kartendaten data;
  // diverse gemeinsame Members
};

class Seedaten : public Kartenobjekte {...}; //etc.
-------------------------------------------------

Ansprechen von Kartendaten geht dann von außen mit 
Kartenobjekte::Kartendaten.member() und von den Kartenobjekte-Members
aus mit data.member().

> ... Waere es nicht freundlicher, wenn moeglich zu antworten  
> und dann auf bessere Orte fuer Fragen zu dem Thema hinzuweisen ?

Das Beste wäre wohl, regelmäßig einen kurzen, freundlichen Hinweis
zu posten, und den Rest den Göttern zu überlassen.  Sigh...


ralf
--
PGP: 1024/0xA713ECE9 2047/0xC8E605F5

Kay Hayen (kay@edition.bonbit.org) wrote:
> PS: Ich hoffe keine C++ inhaltlichen Aspekte angesprochen zu haben und  
> wenn ich meine Meinung dazu sagen duerfte: Ich kann Ulrichs Position  
> verstehen, es gibt viele Fragen, die hier tatsaechlich sehr fehl am Platze  
> sind, aber die Netzstruktur ist nunmal nicht sehr uebersichtlich, da wird  
> sich immer jemand in dieses Brett "verirren" und Fragen stellen, die nicht  
> hierhergehoeren. Waere es nicht freundlicher, wenn moeglich zu antworten  
> und dann auf bessere Orte fuer Fragen zu dem Thema hinzuweisen ?

Ich habe das eine Zeitlang so gemacht, ich habe eine Zeitlang die Leute auch
per Mail darauf hingewiesen. In letzter Zeit haben die Off-Topic Postings
aber so ueberhand genommen, dass ich beschlossen habe, diese Diskussionen
oeffentlich zu fuehren, damit die potentiellen Poster von morgen das
mitbekommen und sich gleich Gedanken ueber die Gruppenwahl machen ohne dass
ich zuerst eine private Diskussion per Mail mit ihnen fuehre.

Zur Beruhigung fuer alle:
Ich habe nicht vor, das bis in alle Ewigkeit fortzufuehren. Sobald sich die
Anzahl der Off-Topic Postings wieder auf ein ertraegliches Mass vermindert
hat, werde ich auch wieder privat mit den Leuten darueber diskutieren.

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

kay@edition.bonbit.org (Kay Hayen) wrote:


>Hallo Leute.

>In meinem derzeiten Projekt ( ueber den Inhalt darf ich nichts andeuten,  
>sonst werde ich wohlmoeglich auch von Ulrich angeflamt :-) habe ich eine  
>Klasse "Kartendaten", von dieser Klasse gibt es maximal nur eine Instanz  
>mit einer Lebenszeit ueber fast das gesamte Programm.

>Die Daten, die diese Klasse verwaltet aehneln sich so sehr, dass ich eine  
>Klasse "Kartenobjekt" eingefuehrt habe, deren Ableitungen dann member von  
>Kartendaten sind. Die Konstruktoren dieser Ableitungen von Kartenobjekten  
>werden vom den Konstruktoren von Kartendaten aufgerufen.

Wieso Member? Eine Liste von Kartenobjekten, die alle nur über das
Kartenobjekt-Interface angesprochen werden, waere eine bessere Lösung.

>Dann erfolgt aber IMO ein Stilbruch, denn die "Kartenobjekte" muessen auf  
>Memberfunktionen von "Kartendaten" zugreifen und dazu muss ich jedem  
>Konstruktor einer Zeiger auf die "Kartendaten" mitgeben, was ich nicht als  
>sehr elegant empfinde.

Ist aber ok. Solltest du aus irgendwelchen Gründen plötzlich mehrere
Kartendaten benötigen, zahlt es sich aus.

>Sollte ich den Konstruktor von Kartendaten eher in zwei Teile aufspalten  
>und Initialisierungen der Unterobjekte in eine direkt nach dem Kostruktor  
>aufzurufende Memberfunktion "Init" verlegen ? Die Kartenobjekte koennten  
>dann ueber einen globalen Zeiger auf die Kartendaten zugreifen ? Den  
>koennte ich auch schon im Konstruktor setzen, aber Seiteneffekte von  
>Konstruktoren finde ich noch uneleganter.

Lesen die Kartenobjekte nur über diesen Zeiger (const machen!)? Das
waere ok, wenn sie schreiben und dadurch untereinander Informationen
austauschen, kannst du leicht einen Wartungsalptraum bauen.

Das Problem hast du allerdings auch wenn jedes Kartenobjekt seinen
eigenen Kartendaten-Pointer hat.

Joachim

"Man faengt Forellen mit der Hand, indem man zuerst ihr Vertrauen gewinnt 
und es dann missbraucht."                              Robert A. Heinlein

Hallo Leute,

ralf@ark.franken.de (Ralf W. Stephan)  meinte am 02.02.96
zum Thema "Re: Objekt Hierachie, wie am besten ?":

>Kay Hayen writes:
>> ...Kartendaten, Kartenobjekte...
>
>Ich versuchs mal (man nehme Cline/Lomow:"C++ FAQs" zur Hand...).
>
>  FAQ 382: How is a static data member similar to a global variable?
>  A static data member is like a global variable with a funny name
>  that needn't be public.
>  If your class has a static data member, there is only one copy
>  of that datum even if there are many instances of the class. ...
>
>-------------------------------------------------
>class Kartendaten {...};
>
>class Kartenobjekte
>{
>public:
>  static Kartendaten data;
>  // diverse gemeinsame Members
>};
>
>class Seedaten : public Kartenobjekte {...}; //etc.
>-------------------------------------------------
>
>Ansprechen von Kartendaten geht dann von außen mit
>Kartenobjekte::Kartendaten.member() und von den Kartenobjekte-Members
>aus mit data.member().

Oh, oh, ich habe ne Weile gebraucht, um mitzubekommen, dass Du so  
praktisch die Hierachie umdrehtst. Das ist erstmal eine tolle Idee, nur  
wie spreche ich dann von Kartendaten aus die Seedaten an ? Kartendaten  
sollte ja eine gemeinsame Schnittstelle zu allen Kartenobjekten werden.

Koennte ich da einfach eine Aufteilung von Kartendaten vornehmen. Also  
weiter die Kartenobjekte in dem Konstruktor einer auesseren Kartendaten  
Klasse erzeugen, aber den Zugriff ueber eine den Kartenobjekten gemeinsame  
Kartendaten_Shell Klasse, friend von Kartendaten, laufen zu lassen. Die  
muesste ja nur einmal initialisiert werden.

Nur wenn ich verschiedene Instanzen von Kartendaten haben wollte, wie  
bekomme ich es dann hin, dass ich den Kartenobjekten darin dann auch  
andere Kartendaten_Shell Instanzen zuweise ?

Ansonsten danke ich Dir fuer diesen Loesungshinweis, die letzte Frage  
bliebe aber noch zu klaeren.

        Mls, Kay


--
[...]

class Mensch Ich( "Kay Hayen", "Kay@Edition.bonbit.org", ... );
class Leser *Du;

[...]

if (( You->Nett() == TRUE ) || ( You->Konstruktiv() == TRUE )) {
   Ich.Gruss( Du );
   Ich.Sage(  Du, "Antworte mal wieder...." );
} else {
   Ich.Sage( Du, "Tschuess." );
}

Hallo Leute,

a2597420@athena.rrz.uni-koeln.de (Joachim Zobel)  meinte am 04.02.96
zum Thema "Re: Objekt Hierachie, wie am besten ?":

>kay@edition.bonbit.org (Kay Hayen) wrote:
>
>>Hallo Leute.
>
>>In meinem derzeiten Projekt ( ueber den Inhalt darf ich nichts andeuten,
>>sonst werde ich wohlmoeglich auch von Ulrich angeflamt :-) habe ich eine
>>Klasse "Kartendaten", von dieser Klasse gibt es maximal nur eine Instanz
>>mit einer Lebenszeit ueber fast das gesamte Programm.
>
>>Die Daten, die diese Klasse verwaltet aehneln sich so sehr, dass ich eine
>>Klasse "Kartenobjekt" eingefuehrt habe, deren Ableitungen dann member von
>>Kartendaten sind. Die Konstruktoren dieser Ableitungen von Kartenobjekten
>>werden vom den Konstruktoren von Kartendaten aufgerufen.
>
>Wieso Member? Eine Liste von Kartenobjekten, die alle nur über das
>Kartenobjekt-Interface angesprochen werden, waere eine bessere Lösung.

Die Kartendaten Klasse soll doch eigentlich dieses Interface sein. Mit  
Member habe ich mich sicher falsch ausgedrueckt, was ich exakt meine ist  
je ein Pointer auf die Erben von Kartenobjekt in der Klasse Kartendaten.

>>Dann erfolgt aber IMO ein Stilbruch, denn die "Kartenobjekte" muessen auf
>>Memberfunktionen von "Kartendaten" zugreifen und dazu muss ich jedem
>>Konstruktor einer Zeiger auf die "Kartendaten" mitgeben, was ich nicht als
>>sehr elegant empfinde.
>
>Ist aber ok. Solltest du aus irgendwelchen Gründen plötzlich mehrere
>Kartendaten benötigen, zahlt es sich aus.

Tja, ich hoffe, es ist doch irgendwie moeglich. Ralf hat in einem anderen  
Posting eine Moeglichkeit aufgezeigt,  aber ich verliere IMO allerdings  
die Option mehere Instanzen von Kartendaten haben zu koennen.

Geht es nicht doch irgendwie ? Anscheinend wohl nicht, aber vielleicht  
gibt es noch andere Ideen. Sonst werde ich mich fuer oder gegen mehere  
Instanzen entscheiden muessen.

>>Sollte ich den Konstruktor von Kartendaten eher in zwei Teile aufspalten
>>und Initialisierungen der Unterobjekte in eine direkt nach dem Kostruktor
>>aufzurufende Memberfunktion "Init" verlegen ? Die Kartenobjekte koennten
>>dann ueber einen globalen Zeiger auf die Kartendaten zugreifen ? Den
>>koennte ich auch schon im Konstruktor setzen, aber Seiteneffekte von
>>Konstruktoren finde ich noch uneleganter.
>
>Lesen die Kartenobjekte nur über diesen Zeiger (const machen!)? Das
>waere ok, wenn sie schreiben und dadurch untereinander Informationen
>austauschen, kannst du leicht einen Wartungsalptraum bauen.

Ich schreibe natuerlich nicht direkt in die Strukturen, sondern benutze  
Member-Funktionen, alles andere waere wohl extrem unuebersichtlich.

>Das Problem hast du allerdings auch wenn jedes Kartenobjekt seinen
>eigenen Kartendaten-Pointer hat.

Stimmt. Mensch sollte immer vermeiden, direkt an der Kontrolle von  
Funktionen einer Klasse in deren Daten zu schreiben. Die Klassen sollen  
doch die Daten kapseln, so sind Fehler aber schwer zu entdecken, bei  
groesseren Umstellungen muss dann auch noch der ganze source durchgegangen  
werden, um Aenderungen zu machen, anstatt nur eine Klasse. Alptraum wird  
es dann, wenn an wenigen Stellen die Aenderungen vergessen wurden....

>Joachim

        Danke auch fuer Deine Tips, Kay


--
[...]

class Mensch Ich( "Kay Hayen", "Kay@Edition.bonbit.org", ... );
class Leser *Du;

[...]

if (( You->Nett() == TRUE ) || ( You->Konstruktiv() == TRUE )) {
   Ich.Gruss( Du );
   Ich.Sage(  Du, "Antworte mal wieder...." );
} else {
   Ich.Sage( Du, "Tschuess." );
}

kay@edition.bonbit.org (Kay Hayen) wrote:


>Hallo Leute,

>a2597420@athena.rrz.uni-koeln.de (Joachim Zobel)  meinte am 04.02.96
>zum Thema "Re: Objekt Hierachie, wie am besten ?":

>>kay@edition.bonbit.org (Kay Hayen) wrote:

>>Lesen die Kartenobjekte nur über diesen Zeiger (const machen!)? Das
>>waere ok, wenn sie schreiben und dadurch untereinander Informationen
>>austauschen, kannst du leicht einen Wartungsalptraum bauen.

>Ich schreibe natuerlich nicht direkt in die Strukturen, sondern benutze  
>Member-Funktionen, alles andere waere wohl extrem unuebersichtlich.

>>Das Problem hast du allerdings auch wenn jedes Kartenobjekt seinen
>>eigenen Kartendaten-Pointer hat.

>Stimmt. Mensch sollte immer vermeiden, direkt an der Kontrolle von  
>Funktionen einer Klasse in deren Daten zu schreiben. Die Klassen sollen  
>doch die Daten kapseln, so sind Fehler aber schwer zu entdecken, bei  
>groesseren Umstellungen muss dann auch noch der ganze source durchgegangen  
>werden, um Aenderungen zu machen, anstatt nur eine Klasse. Alptraum wird  
>es dann, wenn an wenigen Stellen die Aenderungen vergessen wurden....

Kapseln hilft in der Situation, die ich im Kopf habe, wenig. Ich habe
zweimal verkettete Listen von Objekten geschrieben, die abgearbeitet
werden und dabei den Zustand des Listenobjektes ändern. Bei beiden bin
ich froh, wenn ich sie nicht aendern muss. Das Boese sind die vielen
verschiedenen (schlecht dokumentierten, ja.. seufz) Zustände dieses
Listenobjekts. Das hat aber vieleicht wenig mit deinem Problem zu tun.

Joachim

"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden 
koennen."                       - Bertolt Brecht - Das Leben des Gallilei

Kay Hayen writes:
> Oh, oh, ich habe ne Weile gebraucht, um mitzubekommen, dass Du so  
> praktisch die Hierachie umdrehtst. Das ist erstmal eine tolle Idee, nur  
> wie spreche ich dann von Kartendaten aus die Seedaten an ? Kartendaten  
> sollte ja eine gemeinsame Schnittstelle zu allen Kartenobjekten werden.

Na wenn Du von A B und von B A ansprechen willst, dann muß ich
gestehen, daß mir nur noch der Rat einfällt, Deine Hierarchie
nochmal zu überdenken.  Von Hierarchie kann dann nämlich keine
Rede mehr sein.  Oder eins der Hauptobjekte muß aufgeteilt werden.

Vielleicht gibt es irgendwo fertigen Code, von dem Du was
abschauen kannst?


Viel Glück,
ralf
--
PGP: 1024/0xA713ECE9 2047/0xC8E605F5

benni@hera.rbi.informatik.uni-frankfurt.de (Benjamin Baermann) wrote:

>Hm. Wenn diese Klasse wirklich nur ein Objekt hat, auf das von ueberall
>drauf zugegriffen wird, finde ich es nicht schlimm es einfach (und
>dreckig) global zu machen. Natuerlich ist das nicht die reine
>objektorientierte Schule, aber doch relativ intuitiv und uebersichtlich
>also in diesem Fall wohl vorzuziehen, oder?

hallo banni,

ich finde diese situation ist ein typischer anwendungsfall fuer
singleton-klassen. hast du dir schon mal das design-pattern-buch der
gang-of-four angeschaut? das sinngleton-pattern stellt sicher, dass
von einer klasse nur ein einziges objekt erzeugt werden kann. durch
eine statische klassenmethode kann man auf dieses objekt zugreifen.
vorteil: rein objektorientiert und schont den globalen namensraum.

class Singleton
{
public:
	static Singletin *getInstance();

private:
	Singleton() {...}

	static Singleton *theInstance;
};

Singleton *Singleton::theInstance=NULL;

Singleton *Singleton::getInstance()
{
	if (!theInstance)
		theInstance=new Singleton;

	return theInstance;
}

gruss haiko

p.s. kann es sein, dass wir uns von einer chippy-sendung im hr kennen?