You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
39 lines
2.9 KiB
39 lines
2.9 KiB
\section{InheritedWidget}
|
|
\label{eval:inheritedwidget}
|
|
|
|
Wie in \autoref{sec:inheritedWidget} beschrieben, stellen InheritedWidgets einen Lösung für das Zustandsverwaltung dar, die ohne externe Bibliotheken auskommt und somit nur Bordmittel des Flutter-Frameworks benutzen.
|
|
|
|
\subsection{Implementierung}
|
|
|
|
Für die Implementierung dieses Ansatzes wurden mehrere Stores konstruiert, welche den Anmeldezustand, die geladenen Produkte und die im Warenkorb befindliche Anzahl der Produkte modellieren. Ein Store besteht dabei immer aus einem InheritedWidget und einem StatefulWidget. Das InheritedWidget erhält dabei vom StatefulWidget die Daten und Methoden, welche nach außen abrufbar sein sollen. Zustandsänderungen und Verknüpfungen mit anderen Stores finden ausschließlich im StatefulWidget statt.
|
|
|
|
Die Benutzeroberfläche greift auf die Stores ausschließlich über die InheritedWidgets zu, wie bereits im \autoref{sec:inheritedWidget} beschrieben wurde.
|
|
|
|
Der Funktionsumfang konnte dabei ohne Einschränkungen vollständig implementiert werden.
|
|
|
|
\subsection{Bewertung}
|
|
|
|
Im folgenden Abschnitt wird die Implementierung mit InheritedWidget \autocite[branch=inheritedwidget]{repo} anhand der definierten Bewertungskriterien bewertet.
|
|
|
|
\paragraph{\nameref{sec:changeablility}} Bei der Änderbarkeit und Skalierbarkeit wird dieses Zustandsverwaltungssystem mit \textquote{teilweise erfüllt} bewertet.
|
|
|
|
Eines der Merkmale von skalierbaren und änderbaren Zustandsverwaltungssystemen ist es, dass sich mehrere Zustände untereinander verknüpfen lassen. Dies ist hier eingeschränkt möglich, da um auf einen anderen Zustand zuzugreifen es erforderlich ist, dass dieser im Widget-Baum oberhalb des zugreifenden Zustandswidgets angeordnet ist. Falls dies der Fall ist, lässt sich der Zustand aber wie bei der Benutzeroberfläche (vgl. \autoref{sec:inheritedWidget}) über einen Methoden-Aufruf abrufen.
|
|
|
|
Negativ bewertet wird hier aber die Tatsache, dass ein Zustand beziehungsweise Store immer aus mindestens drei Klassen bestehen muss. Dies macht es erforderlich, alle nach außen zugängliche Funktionen oder Variablen per Konstruktoraufruf von dem StatefulWidget zum InheritedWidget zu übergeben. Bei wachsender Größe eines Zustands wird dies unübersichtlich.
|
|
|
|
Ein weiter Nachteil ist es, dass es erforderlich ist, im InheritedWidget eine Methode zu implementieren, die feststellt, ob sich der Zustand im Vergleich zu einem anderen Zustand verändert hat. Dies wird bei wachsender Größe oder Datenstrukturkomplexität eines Zustands unübersichtlich und auch komplex.
|
|
|
|
\paragraph{\nameref{sec:testability}}
|
|
|
|
\paragraph{\nameref{sec:efficiency}}
|
|
|
|
\lstinputlisting[caption={Anzahl der Render-Vorgänge bei InheritedWidget}]{results/inheritedwidget/benchmarks.txt}
|
|
|
|
\paragraph{\nameref{sec:complexity}}
|
|
|
|
\paragraph{\nameref{sec:readability}}
|
|
|
|
\paragraph{\nameref{sec:documentation}}
|
|
|
|
\paragraph{\nameref{sec:structure}}
|
|
|
|
|