@ -21,15 +21,64 @@ Zur Skalierbarkeit lässt sich sagen, dass in der Dokumentation bereits Limitati
Aufgrund der eingeschränkten Skalierbarkeit, wird die Änderbarkeit/Skalierbarkeit mit \textquote{teilweise erfüllt} bewertet.
\paragraph{\nameref{sec:testability}}
\paragraph{\nameref{sec:testability}} Zur Testbarkeit lässt sich sagen, dass sowohl die Geschäftslogik als auch verwendende Widgets sich ohne Änderungen am Quelltext der Anwendung testen lassen.
Bei der Geschäftslogik lassen sich die Zustandsklassen komplett ohne die Verwendung von Flutter oder von Provider an sich testen. Somit ist es auch nicht nötig, etwaige Abhängigkeiten zu Mocken oder Widget-Tests zu benutzen.
Bei den Tests der Widgets, die auf Zustände zugreifen, lässt sich sagen, dass das Mocking hier unaufwendig ist, da Provider die jeweiligen Zustände abstrahiert und so es möglich ist, einfache \textquote{Value}-Provider zu injizieren, wie in \autoref{lst:providertest} zu sehen ist. Diese können dann wie im Beispiel zu sehen ist, einfache Klassen injizieren, die die Eigenschaften der ursprünglichen Zustandsklasse überschreiben.
\begin{lstlisting}[caption={Widget-Test bei Provider in total\_price\_test.dart \cite{repo}}, label={lst:providertest}]
class CartStoreMock extends CartStore {
@override
double get totalPrice => 10.0;
}
void main() {
testWidgets('test total price', (tester) async {
final widgetTree = MaterialApp(
home: ChangeNotifierProvider.value(
value: CartStoreMock() as CartStore,
child: const TotalPriceText(),
),
);
await tester.pumpWidget(widgetTree);
final correctText = find.text("Gesamtpreis: 10.00");
expect(correctText, findsOneWidget);
});
}
\end{lstlisting}
Da sowohl Widget-Tests als Geschäftslogik-Tests implementierbar waren, wird die Testbarkeit mit \textquote{vollständig erfüllt} bewertet.
\paragraph{\nameref{sec:efficiency}} Nach der Ausführung der Teststrecke, ergaben die Zähler folgendes Ergebnis:
\lstinputlisting[caption={Anzahl der Render-Vorgänge bei Provider}]{results/provider/benchmarks.txt}
\paragraph{\nameref{sec:complexity}} Die Auswertung der Metriken (vgl. \autoref{metrics:provider}) ergab eine \ac{mi} von 83 für das gesamte Projekt.
\paragraph{\nameref{sec:readability}}
\paragraph{\nameref{sec:readability}}Die Verständlichkeit und Lesbarkeit lässt sich hier anhand mehrerer Aspekte bewerten.
\paragraph{\nameref{sec:documentation}}
Bei Provider werden hauptsächlich bereits bestehende Konzepte von Flutter erweitert. Dies kann beispielsweise an der Injizierung der Zustandsklassen in Widgets beobachtet werden. Hier wird ein ähnliches Syntax wie bei anderen Flutter-Komponenten genutzt wie auch im Beispiel in \autoref{lst:providerof} zu sehen ist. Jedoch muss hier auch angemerkt werden, dass es empfehlenswert ist, immer eine Zustandsklasse zu erstellen, auch wenn die an die Widgets zu übergebenden Zustände einem trivialen Datentyp wie einem \texttt{String} entsprechen, da für das Injizieren immer das Klassen-Name der zu injizierenden Klasse verwendet wird. So ist es also nicht möglich, mehrere Zustände vom Type \texttt{String} gleichzeitig zu verwenden. Diese zusätzlichen Klassen können somit die Lesbarkeit erschweren.
\paragraph{\nameref{sec:structure}}
\begin{lstlisting}[caption={Vergleich des Abrufs von Zuständen zwischen Flutter und Provider}, label={lst:providerof}]
// Abruf der Bildschirmausrichtung
// aus der Flutter-Standardbibliothek
MediaQuery.of(context).orientation;
// Abruf des Einkaufwagenzustands
Provider.of<CartStore>(context).cart;
\end{lstlisting}
Die Zustandsklassen an sich führen auch keine neuen Konzepte ein und Verwenden bereits bekannte Konzepte wie die ChangeNotifier. Diese Zustandsklassen bieten auch eine gute Lesbarkeit, da hier direkt über Variabeln auf den Zustand zugegriffen wird und über Funktionen dieser direkt geändert wird. Hier muss also keine Spezialbehandlung aufgrund der Zustandsverwaltung genutzt werden.
Auf der anderen Seite werden Konstrukte wie der ProxyProvider, welcher die Verknüpfung von mehreren Zuständen ermöglicht, schnell auf Grund der vielen Parameter unübersichtlich.
Der letzte untersuchte Aspekt, ist ob das Zustandsverwaltungssystem, der tiefen Verschachtlung wirksam entgegentritt. Dazu lässt sich konstatieren, dass hier durch die Einführung eines sogenannten \texttt{MultiProvider} dieses Problem umgangen wird. Zwar muss bei Provider, alle Provider in den Widget-Baum eingesetz werden, allerdings kann ein \texttt{MultiProvider} eine Liste von Providern entgegen nehmen und in den Widget-Baum einsetzen. Somit kommt es nicht zu einer tiefen Verschachtlung.
Zusammenfassend wird dieser Bewertungsaspekt mit \textquote{teilweise erfüllt} bewertet.
\paragraph{\nameref{sec:documentation}} Zur Dokumentation \autocite[siehe][]{providerReadme} lässt sich sagen, das diese die Grundkonzepte verständlich erklärt und zusätzlich umfangreiche Beispiele beinhaltet. Jedoch ist die Struktur als einzelne Markdown-Datei nicht übersichtlich. Zusätzlich gibt es einen großen Umfang an Drittveröffentlichungen unter anderem in der offiziellen Flutter-Dokumentation.
Die Dokumentierung wird mit \textquote{vollständig erfüllt} bewertet.
\paragraph{\nameref{sec:structure}} Zur Strukturbestimmung lässt sich sagen, dass Provider keinen wesentlichen Einfluss auf die Struktur der Anwendung hat. Zudem gibt sie kein einheitliches Vorgehensmodell bei der Implementierung einer Zustandsklasse vor, da hier wie bereits beschrieben, aus mehreren möglichen Modellen wie ChangeNotifier oder Stream gewählt werden kann.
Daher wird die Strukturbestimmung mit \textquote{nicht erfüllt} bewertet.
Jonas Franz
2 years ago