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!

Werbeanzeige

buggypixels

Treue Seele

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

11

11.04.2011, 12:17

Aber um auf die Frage einzugehen...
Du solltest Dich fragen, ob Du diese Extraschicht wirklich brauchst. Du hast ja anscheinend schon Factories. Willst Du dann noch eine Extraschicht, die dann einzelne Factories zusammenfasst? Generell könnest Du das konkrete Erzeugen eines Items (egal welcher Typ) in den jeweiligen Factories auch erledigen. Jede Schicht in solch einem System erhöht nur die Komplexität. Gerade in Spielen kann ich mir nur schwer vorstellen, warum man es so unnötig kompliziert macht. Auch in der Praxis wendet man das Pattern nicht "häufig" an. Zumindest mittlerweile nicht mehr, wo man sich doch eher um schlanke und leichtgewichtige System bemüht.
Aber das mußt Du selber wissen, ob Du diese Komplexität möchtest. Eventuell bringt es ja in Deinem Fall Dir Vorteile. Das kann man aber nicht generalisieren und hängt von Deinem Spiel/System ab.

buggypixels

Treue Seele

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

12

11.04.2011, 12:23

Ich hätte es wissen müssen.
Also ich sehe das etwas anders. Wenn man etwas Erfahrung hat, dann erkennt man die Stellen in seinem System automatisch und erkennt, wo man welches
Pattern verwenden kann und sollte. Hinterher zu schauen und zu sagen, "oh schau mal, hier habe ich ein Factory Pattern benutzt" ist für mich etwas schräg.
Ich denke eher, genau die andere Herangehensweise ist korrekt. Wenn man erkennt, dass man in seinem System Objekte generieren muss und diese auch mit
Werten füllen muß oder gewisse Methoden zur Initialisierung aufrufen muss, dann sieht man sofort, dass man hier ein Factory Pattern verwenden sollte (EIN BEISPIEL!).
Das einfach so zu programmieren und hinterher dann passende Pattern zu erkennen, halte ich persönlich für etwas schräg.
Aber das ist meine persönliche Meinung. Meine Erfahrung ist, dass im Laufe der Jahre Pattern einem in Fleisch und Blut übergehen und man eher weniger darüber nachdenkt, sondern man die Stelle und das passende Pattern automatisch erkennt und sie dann auch einsetzt.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

13

11.04.2011, 13:05

@buggypixels: Aber da entscheidet man ja eben doch anhand des Problems, welches Pattern sich eigenet, bzw. schlägt man eine Lösung vor, die eventuell einem Pattern entspricht. Aber nicht nach dem Motto: "So, ich habe hier ein Problem und will jetzt Pattern XY verwenden."
Klar, wenn man ein Problem hat und feststellt: "Hmm, hier würde ich eine Factory oder eine Bridge oder sowas eignen", dann ist das so. Aber das ist analytisch aus der Anforderung heraus und ginge auch mit einer anderen Lösung. Bridge und Factory sind aber schon bekannt und auch die Umsetzung vermutlich schon erprobt.
Im Gegensatz dazu steht: "Ich will eine Bridge nutzen, mal schauen wohin ich die packen kann" bzw. noch schlimmer: "So, ich bin jetzt fertig, aber kann ich da Pattern XY drüber ziehen?".
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]

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

14

11.04.2011, 13:52

ich muss bluecobold und Schorsch zustimmen. ich hab einige pattern schon lang bevor ich was von ihnen gehört oder gelesen habe eingesetzt. hier kann man die frage von dem huhn und dem ei klar beantworten. das design war zuerst da und man hat patterns erfunden um es zu benennen und beschreiben. sie bieten inspiration und eine möglichkeit mit anderen entwicklern zu kommunizieren. ausserdem versteht man fremden code unter umständen besser wenn man ein pattern kennt das ähnlich funktioniert.

edit: bevor jetzt jemand auf die idee kommt mein schönes bild zu zerstören XD natürlich schlüpft das design nicht aus dem pattern ;) es scheint in manchen augen aber so auszusehen.
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »NachoMan« (11.04.2011, 14:01)


Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

15

11.04.2011, 14:22

Was wohl auch daran liegt, dass Patternneulinge oft damit übertreiben;) Bei mir selbst war es auch so. Man sieht viele tolle Sachen die super aussehen und will sie gerne Umsetzen. Sieht ja auch alles auf den ersten Blick ganz toll aus. Und natürlich soll man Patterns an das Design anpassen. Aber natürlich schlägt man dabei normal den Weg ein den BLueCobold beschreibt. Man überlegt sich das Klassendesign und dort tauchen dann von allein diese Patterns auf. Zum Teil ist es auch so, dass man vor einem Problem steht und sich überlegt wie man es lösen kann, bis einem dann ein bestimmtes Pattern einfällt, welches genau dieses Problem löst. Mit anpassen meinte ich, dass man Patterns selten 1zu1 verwenden kann. Kann mich an ein Projekt aus der Uni erinnern. Sollten im Projekt MVC einsetzen. Hat auch Sinn gemacht, bis auf kleinere Design fragen. Da sich das Team aber unbedingt an das Muster halten wollte und keinen Millimeter davon abweichen wollte, wurds dann nicht fertig. Hätten wir das Pattern leicht auf unsere wünsche Angepasst, wäre es kein Problem gewesen. Entwurfsmuster benennen wie schon gesagt Lösungswege und Methoden um bestimmte Probleme zu lösen. Dabei geben sie einen Ansatz der verbreitet und sinnvoll ist. Durch den zugehörigen Namen können Entwickler sich schneller Verstehen. Man versteht einen Code viel schneller wenn man schon in etwa weiß welches Prinzip dahinter steckt.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

16

11.04.2011, 22:41

oh, hier wurde ja noch richtig viel geschrieben :P

also bin jetzt mit nem ersten entwurf fertig, aber iwie ist das schon noch bischen komisch.

zur erklärung am bsp. von einheiten:

ich habe jetzt eine unitcontroller klasse, die für das erstellen/entfernen/updaten von einheiten zuständig ist und um eine schnittstelle für die funktionalität einer einheit zur verfügung zu stellen (derzeit noch nicht vollständig). mein ziel war es nun, dass ich referenzen beim erstellen zurückgebe, sodass es für den anwender (der schlussendlich dann eh ich bin, aber egal:D) "einfacher" zu benutzen ist. natürlich will ich jetzt nicht, dass der anwender von außen z.b. den destruktor von unit aufrufen kann oder set methoden aufrufen kann ohne das über den controller zu lösen sonst wäre der controller ja irgendwie unsinnig.

also habe ich die rückgabewerte auf const unit& umgeändert. doch jetzt kommts:
jede einheit krigt jetzt also beim erstellen eine id zugewiesen, die gleich ihrer position im vector vom unitcontroller ist. dadurch kann ich zum einen zwischen einheiten unterscheiden und zum anderen hab ich dadurch schon "einzigartige" ids für diese objekte.

da ich aber const unit& zurückgebe, müssen natürlich auch alle methoden vom controller const unit& erwarten. da benutze ich jetzt derzeit einen trick:
void foo( const unit& bla )
{
Unit& btmp = *_units.at( bla.getID() );

// benutze setter mittels btmp
}


was ich hier unschön finde ist, dass eigentlich ja const unit& übergeben wird, das objekt jedoch aber dennoch manipuliert werden kann (z.b. einheit erhält schaden).


sehe da aber iwie derzeit keine bessere lösung :/


hier noch die momentanen quellcodes zum eventuellen besseren verständnis (ohne kommentare und sonstigem, da ich noch am herumtüfteln bin).

Unit.h
Unit.cpp
UnitController.h
UnitController.cpp

idontknow

unregistriert

17

11.04.2011, 23:00

Ich hätte wohl die Attribute in ein struct und die UnitTypes in einen std::vector gepackt :P. Ansonsten ganz interessant :)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

18

12.04.2011, 06:46

An der Stelle hilft eine Konvention vermutlich mehr, als die schlechte Verwendung von const& quer durch den gesamten Quellcode.
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]

19

12.04.2011, 09:08

An der Stelle hilft eine Konvention vermutlich mehr, als die schlechte Verwendung von const& quer durch den gesamten Quellcode.

kannst mir noch verraten,was du damit meinst? ;)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

20

12.04.2011, 09:23

Um da konkreter zu werden müsste erst einmal geklärt werden welche Methoden aus welchen Gründen nicht aufgerufen werden dürfen. "Destructor aufrufen" fällt ohnehin flach. Wenn du "Objekte löschen" meinst, dann reicht die Festlegung, dass dies nicht gemacht werden darf, sondern nur über eine Methode des Controllers zu erfolgen hat - eine Eigentümer-Konvention. Im Falle einer Nichtbefolgung würde es dann eh Fehler zur Laufzeit hageln, da der Controller vermutlich weiter auf gelöschten Objekten arbeiten würde.
Darüber hinaus ist mir aber unklar, warum gewisse Set-Methoden nicht aufgerufen werden dürfen und wieso du dafür nicht einfach nur ein abgespecktes Interface nach außen zurück gibst, sondern das detaillierte Objekt und versuchst den Aufruf durch irgendwelche Parameter-Eigenschaften zu verhindern.
Jedenfalls ist die Verwendung von const& natürlich sehr irreführend, da sich das Objekt intern natürlich trotzdem ändert. Das impliziert unschöne und unabschätzbare Seiteneffekte. Const sollte natürlich verwendet werden, wo es Sinn macht. Aber Seiteneffekte durch interne Zustandsänderungen sollten damit meiner Meinung nach nicht verdeckt werden.
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]

Werbeanzeige