C++ seltsames Verhalten eines Pointers

Alter Hase

Wohnort: Paderborn

Beruf: Informatik Student

06.07.2014, 10:30

Aber die Buttons im UIContainer zu speichern ist doch denke ich die beste Methode oder nicht? Das UI besteht ja wie gesagt aus den UIContainern und ner Menge anderem Gedöns und die Buttons sind ja auch in den UIContainern. Irgendwie muss man jetzt ja von ausserhalb mit Hilfe der UI Klasse auf die Buttons zugreifen können. Deswegen dachte ich, dass die Pointer eine sinnvolle Idee sind. Man könnte natürlich auch eine Methode in der UI Klasse implementeiren, die den Namen des Buttons übergeben bekommt und diesen dann bei den UIContainern anfordert, allerdings wäre diese aufwendiger in Sachen Rechenzeit.

Zum Seitenanfang

Alter Hase

Wohnort: Paderborn

Beruf: Informatik Student

06.07.2014, 10:50

Irgendwie verstehe ich das nicht so ganz.

Wenn die UI Klasse eine Methode hat, die von den UIContainern einen Pointer auf einen Button zurückgibt (siehe Pseudocode) ist es in Ordnung.
Pseudocode:

	C-/C++-Quelltext
1 2 3 4 5	Button* UI::GetButton(string name) { Container.getButtonPointer(name); //Eigentlich müsste hier ja noch eine Schleife hin, weil es mehrere Container gibt }

Aber hat die UI Klasse direkt die Pointer auf die Buttons und so schnelleren Zugriff, ist es nicht okay?

Das Ergebnis ist ja das gleiche.

EDIT:
Der Fehler entstand ja auch nur dadurch, dass ich das mit dem realloc beim vector nichtwusste und deswegen falsch implementiert habe.

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

06.07.2014, 12:09

Nein, das Problem kommt daher, dass die Klasse UI zu viele interne Details über UIContainer weiß. Du hast jetzt zwei Klassen, die beide eine Menge von UI-Elementen verwalten. Eine davon ist stark abhängig von der Implementierung der anderen. Es geht nicht darum, wer was zurückliefert, sondern darum, welche Annahmen eine Klasse über die Details der anderen treffen muss. UI sollte unabhängig davon funktionieren, was UIContainer intern genau tut. Er sollte sich rein auf die öffentlichen Schnittstellen verlassen können. Und das ist hier verletzt. Wohin das führt, das hast Du ja schon gesehen. Es ist immer eine schlechte Idee, wenn eine Menge von Instanzen an mehreren Stellen verwaltet wird.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Alter Hase

Wohnort: Paderborn

Beruf: Informatik Student

06.07.2014, 12:50

Aber irgendwie muss die UI Klasse ja Zugriff auf die Buttons haben

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

06.07.2014, 13:12

Die Lösung dafür hast Du doch sogar schon präsentiert in Beitrag #13. Wobei sich dann die Frage stellt, ob "UI" überhaupt noch notwendig ist.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Alter Hase

Wohnort: Paderborn

Beruf: Informatik Student

06.07.2014, 13:26

Okay, dann werde ich es so implementieren. UI ist notwendig, es gehören noch weitere Dinge als die blossen Container zum UI, ausserdem beinhaltet UI viele Funktionen um alles vom UI zu verwalten, weil es zumindest in der finalen Version nicht mehr statisch ist und sich oft verändert.

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

06.07.2014, 13:34

Wer verwaltet dann also? UI oder UIContainer? :rolleyes:

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Alter Hase

Wohnort: Paderborn

Beruf: Informatik Student

06.07.2014, 13:50

Also UI beinhaltet Dinge wie die UIContainer, von denen es verschiedenen Arten gibt, eine Minimap(kommt zumindest) und zB das ingame menu(Bei ESC klick), also eigentlich alles was anklickbar und nicht auf dem "Spielfeld" ist. Die UIContainer haben selber Methoden zur Kollisionsabfrage mit der Maus und wenige mehr. Das gesamte UI soll dabei zentral von der UI Klasse verwaltet werden. In UI::Update wird manches an die UIContainer gegeben und diese prüfen auf Dinge wie Collision, aber vor allem weil die UIContainer sich auch gegenseitig beeinflussen können (Buttonklick in einen verändert den anderen) habe ich die UI Klasse, die das alles sammelt und so eine Schnittstelle bietet.

Zum Seitenanfang

Community-Fossil