Klasse Coin Refactoring:
-
CoinFactory-Klasse zur Initialisierung eines Coins erstellt und alle Methoden die einzig hierzu in der Klasse Coin vorhanden waren, herausgezogen (Paketstruktur müsste angepasst werden, sodass die Default- und Public-Sichtbarkeit besser genutzt werden können, z.B. über Package .models.coins. Momentan sind Dinge wegen der Einführung der Factory von außen zugreifbar, die es vorher nicht waren).
-
Ein Coin nimmt keinen Context mehr an, sondern direkt die SharedPreferences.
-
statische Konstante für die ständig frei genutzten <"Setttings", 0> Paare auf Coin eingeführt.
-
iconomi_daa in Coin statisch gemacht, da es nur lesende Zugriffe gab und einzig dafür ein Coin erstellt werden musste. Was auch immer das genau ist, es scheint eher Modul- denn Klassencharakter zu haben.
-
Toast.makeText aus Coin herausgezogen, da dafür der Context notwendig wäre. Methoden von void auf boolean, um es nach dem Aufruf zu entscheiden.
-
Wäre genau zu verstehen und zu prüfen, ob es überhaupt Sinn macht, dass ein Coin diese ganzen Tabellen hält. Wenn ja, wohl eher in einer extra Klassen zusammen fassen, anstatt so lose direkt in Coin. Wenn nein, statisch machen auf Coin oder einer extra Klasse nur dafür.
-
Die preferences und editor Klassenattribute wurden bei jedem Methodenaufruf geholt und gesetzt, obwohl, dass vorher im Konstruktor bereits geschah. Sollten diese nicht veränderlich sein und das halten einer Referenz damit nicht ausreichen, um Aktualisierungen direkt zu erfahren, funktioniert die App nun nicht mehr nach meinem Refactoring.
Klasse CoinLogo Refactoring:
- Context terminiert in Konstruktor und FileDirectory direkt als Parameter (zu überlegen, ob besser bei jeder Methode oder im Konstruktor, je nach Verwendungszweck)
- FileOutputStream, der vorher vom Kontext kam, nun als Parameter in entsprechender Methode.
Tests:
- Objekte können erstellt werden, mehr aber auch nicht.
- Auch nach dem jetzigen Refactoring kommt man nicht drumherum einen Mock für die SharedPreferences zu implementieren, da diese weiterhin genutzt werden auch wenn der Context aus dem Spiel ist.
- Ist die Frage wie der von Google gedachte Android-Weg dafür wirklich ist. Eher Refactoring und Activities und Models strikt trennen? Dann werden die Models nicht mehr viel können, und es gibt irgendeine Activity, die bspw. die dauerhaft genutzten SharedPreferences hält. Kanns das wirklich sein? Oder aber man macht es genau so wie der Kerl hier und mockt alles her für Tests. Gibt da ja bestimmt auch was vorgefertigtes. wenn man sich mit Android auskennt, wird man sicher fündig. Andernfalls implementiert man es einmal für seine Zwecke, aber dafür fehlt mir hier die Zeit und auch wirklich der Ansporn bei so einer Aufgabe :)