Softwarearchitektur: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Thomas (Diskussion | Beiträge) Ein bisschen Text zu Boundaries |
Roth (Diskussion | Beiträge) |
||
| (2 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| Zeile 36: | Zeile 36: | ||
=== In Use Cases denken statt in Implementierungsdetails === | === In Use Cases denken statt in Implementierungsdetails === | ||
Funktionen und Komponenten können auf verschiedene Weisen gruppiert werden: einzelne Methoden werden in Klassen zusammengefasst. Klassen werden in Namespaces gehalten. Und eventuell wird all das in Bibliotheken verteilt (letzteres aber wohl nicht im Softwarepraktikum). Als Richtlinie gilt hier, dass diese Kategorisierung danach gewählt werden sollte, wie und von wem die Funktionen verwendet werden. Nicht danach, wie genau die Funktion implementiert wurde. | |||
Selbiges gilt natürlich auch für Methoden, die von Klassen bereitgestellt werden ("public"). In der Praxis interessiert es den Nutzer einer Datenstruktur meist nicht, ob diese eine ausgeklügelte Baumstruktur hat, Hashing verwendet oder einfach nur ein Array durchläuft. Wichtig ist bei der Verwendung nur, dass die erwartete Funktionalität bereitstellt (und in diesem Fall ihr Laufzeitversprechen hält). Beim Design von Komponenten sollte also immer der spätere Nutzer im Blick behalten werden. Beim Softwarepraktikum sind das zuallererst die anderen Mitglieder des Entwicklerteams. | |||
=== Trennung nach Funktionalität === | === Trennung nach Funktionalität === | ||
Es hat sich herausgestellt, dass es eine gute Idee ist unterschiedliche Funktionalitäten (oder vielleicht besser: Funktionalitätsarten) voneinander zu treffen. Am einfachsten verständlich ist das an einem Beispiel: | |||
Hat eine Komponente die Aufgabe Daten auf die Festplatte zu schreiben, dann tut sie auch nur das. In dieser Komponente ist keine Spiellogik enthalten. Auch kommt kein Code vor, der irgendwas mit Grafik oder Sound macht. Damit wird die Verwendung erleichtert und Fehler sind ebenfalls leichter zu finden. Ein weiterer ganz besonderer Vorteil ist außerdem, dass hier später auch Interfaces verwendet werden können. Haben wir erst eine stabile DiskWriter-Klasse, kann diese schnell mit einem WriterInterface ausgetauscht werden. So können später auch weitere Klassen einfach eingesetzt werden, die z.B. einen Netzwerksockel beschreiben (für Netzwerk-Kommunikation) oder einfach nur Dinge im temporären Speicher ablegen. | |||
== Besonderheiten bei der Entwicklung von Videospielen == | == Besonderheiten bei der Entwicklung von Videospielen == | ||
Videospiele nehmen in der Softwarewelt eine Besonderheit ein. Nicht nur technologisch, da unterschiedlichste Subsysteme in Echtzeit zusammenarbeiten müssen. Auch die Entwicklung ist davon geprägt, dass es sich | Videospiele nehmen in der Softwarewelt eine Besonderheit ein. Nicht nur technologisch, da unterschiedlichste Subsysteme in Echtzeit zusammenarbeiten müssen. Auch die Entwicklung ist davon geprägt, dass es sich an sich um ein verbrauchbares Konsumgut handelt (die meisten Videospiele hat man irgendwann ausgespielt). Entsprechend unwichtiger ist langfristige Wartbarkeit, da sich der Lebenszyklus des Spiels kaum vorhersehen lässt. Dies äußert sich natürlich auch in der Architektur:<ref>[https://godotengine.org/article/how-actually-make-your-dream-game How to make your dream game, publish it and not die in the process]</ref> | ||
* Auf '''Applikationsebene''' (also der Code, der unmittelbar für das Spielgeschehen verantwortlich ist) möchte man flexibel bleiben. Hier muss es nicht immer hübsch und korrekt zugehen. Man möchte schnell herausfinden ob Dinge funktionieren und ob es Spaß macht. | * Auf '''Applikationsebene''' (also der Code, der unmittelbar für das Spielgeschehen verantwortlich ist) möchte man flexibel bleiben. Hier muss es nicht immer hübsch und korrekt zugehen. Man möchte schnell herausfinden ob Dinge funktionieren und ob es Spaß macht. | ||
