Softwarearchitektur: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Thomas (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Roth (Diskussion | Beiträge) |
||
| (Eine dazwischenliegende Version von einem anderen Benutzer wird 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 === | ||
| Zeile 45: | Zeile 49: | ||
== 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. | ||
