|
JLI Spieleprogrammierung
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Jonathan_Klein Living Legend
Alter: 37 Anmeldedatum: 17.02.2003 Beiträge: 3433 Wohnort: Siegerland Medaillen: Keine
|
Verfasst am: 12.08.2006, 17:18 Titel: Zugriff auch pirvate Elemente |
|
|
Also, amn benötigt ja oft bestimmte Daten einer Klasse, die normalerweise allesamt pirvat sind.
Dazu gibt es aj verschiedene Möglichkeiten, im Prinzip sind das, die Elemente public machen (keine gute Idee), für jedes Element eine Get()-Methode schreiben, oder einzelne Klasse friend machen.
Eigentlich finde ich letze Methode gar nicht so dumm, damit kann man ja einfach die Verwaltung von der Visualisierung trennen.
Allerdings fände ich es jetzt auch noch schön wenn es noch eine Methode gäbe, etwas ähnliches wie friend, für die aber alle Daten constant sind. D.h. man kann alle lesen aber nicht verändern.
Ginge natürlich alles über Get()-Methoden, aber ich finde das ein wenig unschön 25 Get()-Methoden zu haben. Irgendwie mildert das die Übersicht.
Gibts zufällig ne Lösung dafür? _________________ https://jonathank.de/games/ |
|
Nach oben |
|
|
Maxim Senior JLI'ler
Anmeldedatum: 28.03.2004 Beiträge: 249
Medaillen: Keine
|
Verfasst am: 12.08.2006, 18:31 Titel: |
|
|
pirvate? die davon gehört
Ich glaube, es gibt keine andere Methoden, außer der oben genannten. Das wäre auch gegen die OOP. (Es gibt doch eine Möglichkeit, aber die sollte man lieber nicht verwenden, denn dass ist gegen OOP. Wenn man was in OOP nicht umsetzen kann, dann ist das Konzept falsch.)
Eine Möglichkeit wäre alle privaten Daten, die du brauchst, in eine Struktur bzw. eine weitere Klasse einzuschließen und dann eine Get()-Methode schreiben, die eine konstate Referenz(-n Zeiger) auf die Struktur zurückgibt. |
|
Nach oben |
|
|
Kampfhund Super JLI'ler
Alter: 42 Anmeldedatum: 20.07.2002 Beiträge: 408
Medaillen: Keine
|
Verfasst am: 12.08.2006, 18:36 Titel: |
|
|
Ich glaube dass du da um die Get und Set Methoden nicht herum kommen wirst.
Wenn du 25 Get Methoden in einer Klasse hast, solltest du dir vielleicht überlegen, ob du die Klasse nicht überladen hast. Eventuell kannst du bestimmte Dinge in andere Klassen auslagern. Manche Get und Set Methoden kannst du vielleicht auch zusammenfassen oder ganz weglassen.
Friend würde ich nur sehr begrenzt verwenden. Denn:
Du hast die Klassen A und B. A hat B als friend, dh B kann auf A zugreifen.
* Dadurch werden die Klassen von einander abhängig. Du kannst in A die Member-Namen nicht mehr einfach so wechseln (gut, mit heutigen Refactoring-Tools geht das wohl).
* Du kannst außerdem die interne implementierung von A nicht so einfach ändern, denn B ist darauf angewiesen, dass die Member danach dieselbe Bedeutung haben. Du kannst also zB nicht den Wertebereich eines Members von A ändern ohne B auch zu ändern.
* Hinzu kommt: A wird undurchschaubarer, denn B kann von außen die Member ändern ohne dass A etwas davon mitbekommt.
* Vielleicht muss wegen einer Umstrukturierung von A beim Ändern bestimmter Member noch etwas anderes in A angepasst werden. B bemerkt davon nichts.
Bei Get und Set Methoden treten diese Probleme nicht auf. Den geringfügigen Verlust an übersicht sollte man in Kauf nehmen. Man kann die Get und Set Methoden ja in der Header/Cpp Datei etwas weiter nach unten schieben.
Get und Set Methoden bieten noch einen weiteren Vorteil:
Du kannst in der Set Methode überprüfen, ob der Wert der gesetzt werden soll auch ein gültiger Wert ist.
Bei mir sehen die Methoden häufig so aus:
CPP: | void SetExitButton(Button* exit_button)
{
assert(exit_button != null);
mExitButton = exit_button;
}
Button* GetExitButton()
{
assert(mExitButton != 0);
return mExitButton;
}
|
Nennt sich "Design by Contract". Programmierfehler lassen sich so schnell aufspüren. _________________ Kochen ist ein NP-schweres Optimierungsproblem. |
|
Nach oben |
|
|
Jonathan_Klein Living Legend
Alter: 37 Anmeldedatum: 17.02.2003 Beiträge: 3433 Wohnort: Siegerland Medaillen: Keine
|
Verfasst am: 12.08.2006, 20:23 Titel: |
|
|
Naja gut, einiges davon gilt eigentlich auch für Get() und Set() Methoden. Außerdem macht es natürlich imemr Probleme wenn 2 Klasse miteinander verzahnt sind und eine geändert werden muss.
Aber das doofe ist ja, wenn man alles Super abkapslet und trennt und so, dann hat man am Ende gar nix mehr, weil irgendwie muss es ja noch zusammenhängen. Daher ist ein Programm in den allermeistne Fällen doch eine enge Verzahnung der einzelnen Klassen. Man hat vielelihct mal eine, die von keiner andern abhängig ist, dafür sind dann aber einige Klasse von dieser abhängig.
friend benutze ich in der Regel auch nicht so oft, alelrdings hab ich die Spielerklasse quasi von einer universellen Spielobjekt Klasse abgeleitet und hab dann noch ne weitere Klasse die das gesamte HUD rendert, die muss dann halt alle Informationen über den Spieler haben. Da muss man entweder für jede zweite Member ne Get() Methode schreiben oder die friend machen. Naja.
Ich schätze mal ich werd erstmla ein paar Get() Methoden benutzen, sollte auch reichen. _________________ https://jonathank.de/games/ |
|
Nach oben |
|
|
Kampfhund Super JLI'ler
Alter: 42 Anmeldedatum: 20.07.2002 Beiträge: 408
Medaillen: Keine
|
Verfasst am: 12.08.2006, 21:47 Titel: |
|
|
Jonathan_Klein hat Folgendes geschrieben: |
Aber das doofe ist ja, wenn man alles Super abkapslet und trennt und so, dann hat man am Ende gar nix mehr, weil irgendwie muss es ja noch zusammenhängen. Daher ist ein Programm in den allermeistne Fällen doch eine enge Verzahnung der einzelnen Klassen. Man hat vielelihct mal eine, die von keiner andern abhängig ist, dafür sind dann aber einige Klasse von dieser abhängig.
|
Richtig, es geht aber nicht um abhängig oder nicht abhängig, sondern um die stärke der Abhängigkeit. Man sollte die Komponenten also möglichst schwach koppeln. Totale unabhängigkeit funktioniert - wie du bereits sagtest - natürlich nicht.
Zitat: |
alelrdings hab ich die Spielerklasse quasi von einer universellen Spielobjekt Klasse abgeleitet und hab dann noch ne weitere Klasse die das gesamte HUD rendert, die muss dann halt alle Informationen über den Spieler haben. |
Gut, das HUD ist wohl auch eine Ausnahme. Mir fällt auch keine tolle Lösung dafür ein. _________________ Kochen ist ein NP-schweres Optimierungsproblem. |
|
Nach oben |
|
|
DirectXer Dark JLI'ler
Anmeldedatum: 05.02.2005 Beiträge: 1201 Wohnort: Köln Medaillen: Keine
|
Verfasst am: 12.08.2006, 23:34 Titel: |
|
|
anstatt für jede Variable eine Get- und eine Set-Methode zu schreiben, kann man auch einfach eine Funktion mit dem Namen der Variable überladen. Sowas steht z.B. in "Effektiv C++ programmieren"; Bsp:
CPP: | class Foo
{
float bla;
public:
void bla(float _bla) { bla = _bla; }
float bla() { return bla; }
};
|
ist natürlich kein bedeutender Unterschied, hat IMHO aber eine schönere Logik... Geschmackssache
Gruß DXer |
|
Nach oben |
|
|
GreveN JLI Master
Alter: 38 Anmeldedatum: 08.01.2004 Beiträge: 901 Wohnort: Sachsen - Dresden Medaillen: Keine
|
Verfasst am: 13.08.2006, 11:08 Titel: |
|
|
Ich mach's genauso wie DirectXer, empfinde ich einfach als schöner.
CPP: | friend benutze ich in der Regel auch nicht so oft, alelrdings hab ich die Spielerklasse quasi von einer universellen Spielobjekt Klasse abgeleitet und hab dann noch ne weitere Klasse die das gesamte HUD rendert, die muss dann halt alle Informationen über den Spieler haben. Da muss man entweder für jede zweite Member ne Get() Methode schreiben oder die friend machen. |
Das HUD ist die Schnittstelle zwischen GUI und Spieler-Objekt (quasi eine Dreiteilung a la MVC-Pattern), von daher finde ich es vertretbar, wenn es Infos vom Spieler holt und diese an GUI-Objekte zum Rendern weiterleitet. Ich würde prinzipiell Methoden zur Objekt-Interaktion vorziehen, Gründe gegen 'friend' hat Kampfhund ja eigentlich genug genannt. Einziger Grund, der für mich für 'friend' spricht ist, dass man Daten vor Missbrauch durch dumme Nutzern schützen kann und trotzdem andern Klassen den Zugriff ermöglicht. |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group Deutsche Übersetzung von phpBB.de
|