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

Julién

Alter Hase

  • »Julién« ist der Autor dieses Themas

Beiträge: 717

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

1

03.08.2015, 14:28

Factory Pattern | Soll eine Klasse sich selber erstellen?

Hi,
ich bin gerade dabei mein jetziges Projekt etwas aufzupolieren.
Zur Zeit sieht es so aus,
dass ein Gerätekontext sich selber über eine statische Methode createDevice(Window& window, Config config = Config::default()) erstellt.

Diese "createDevice"-Methode hat jede meiner beiden Implementationen (WGLContext, GLXContext; beide haben identische Methodendeklarationen aber unterschiedliche Implementationen).
Ich fände es besser, wenn diese beiden Klassen jeweils von einem Interface "IContext" erben, damit diese die gleichen Methoden aber mit unterschiedlichen Implementationen haben.
Das geht jedoch nicht, da man keine Methoden haben kann, die sowohl statisch und virtuell sind.

Ist es also besser die Factory in eine eigene Klasse auszulagern?

LG Julien

P.S.: Ich nutze das Factory-Pattern an dieser Stelle, da das Instanzieren unter Umstände schief gehen kann und dann einfach ein "nullptr" zurückgegeben werden soll.
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

2

03.08.2015, 14:58

Eine Factory macht in Deinem Fall nur dann Sinn, wenn:
1) Die gelieferten Klassen polymorph sind
2) Die Factory selbst nicht Teil einer der beiden Klassen ist

Aktuell klingt es für mich so als ob Du zwei unabhängige Context-Klassen mit jeweils einer statischen create-Methode hast. Falls dem so ist, verstehe ich den Sinn dahinter nicht und würde auf einen normalen Konstruktor verweisen. In diesem Zusammenhang ergäbe es für mich auch keinen Sinn, dass eine dieser Konstruktoren einen nullptr statt einer vernünftigen Exception liefert.
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]

Julién

Alter Hase

  • »Julién« ist der Autor dieses Themas

Beiträge: 717

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

3

03.08.2015, 15:01

Tatsache, kann ja Exceptions liefern. :dash:
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

4

03.08.2015, 15:04

Genau dafür wurden sie ursprünglich übrigens erfunden. Auch wenn Objective-C und Swift der Meinung sind, dass ein Konstruktor auch nullptr liefern darf, sind sie in OO-Sprachen entworfen worden, weil Konstruktoren keine Rückgabecodes liefern können (und Error-Codes als Rückgabewerte auch ziemlich unschön sind).
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]

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

5

03.08.2015, 16:12

Auch wenn Objective-C und Swift der Meinung sind, dass ein Konstruktor auch nullptr liefern darf, ...

:golly:

Werbeanzeige