@ -17,6 +17,8 @@ Im folgenden Abschnitt wird die Implementierung mit Provider \autocite[branch=pr
Das Thema Skalierbarkeit und Änderbarkeit zeigt sich als ambivalent bei Providern. Bei der Änderbarkeit muss man sagen, dass hier Provider einen Vorteil bietet, da durch das Konzept der Provider eine einheitliche Abstraktion für Zustandsverwaltungen geschaffen werden. Somit ist es nicht von Belang, ob ein Zustand über einen Stream, Future oder einen ChangeNotifier abgebildet werden. Dies bietet damit einen Vorteil für Änderbarkeit, da sich Zustände zu einem späteren Zeitpunkt einfach auf ein anderes Zustandsverwaltungsmodell abändern lassen, ohne das Anpassungen außerhalb dieses Zustands von Nöten wären.
Eine Designentscheidung von Provider zum Nachteil der Änderbarkeit ist es, dass Provider alleine über Ihren Klassentyp per Generic in Widgets injiziert werden. Dabei kann zur Kompilierungszeit nicht geprüft werden, ob der referenzierte Zustand sich auch tatsächlich in der Widget-Hierarchie befindet. Somit können bei Änderungen in der Hierarchie von Widgets zu einem späteren Zeitpunkt Laufzeitfehler auftreten, die nicht durch den Compiler gefunden werden können.
Zur Skalierbarkeit lässt sich sagen, dass in der Dokumentation bereits Limitationen für den Einsatz von Providern gezeigt werden. So träten ab der Verwendung von mehr als 150 Providern StackOverflowErrors auf. \autocite{providerReadme} Zudem ist die Koppelung von Zuständen stark begränzt. Dies liegt daran, dass es für jede Anzahl der zu koppelnden Zustände eine entsprechende Klasse in der Provider-Bibliothek geben muss. Aktuell ist dies mit der Klasse ProxyProvider6 auf sechs Klassen begrenzt. Ob diese Limitation in der Realität jedoch tatsächlich relevant ist, ist fraglich, da es wohl architekturell besser wäre in diesem Fall, die Zustände in mehrere Zustände zusammenzufassen.
Aufgrund der eingeschränkten Skalierbarkeit, wird die Änderbarkeit/Skalierbarkeit mit \textquote{teilweise erfüllt} bewertet.
Jonas Franz
2 years ago