bank kata kotlin
1.0.0
J'ai pratiqué la banque Kata par Sandro Mancuso
Mes objectifs où pratiquer un mélange de mix de TDD à l'extérieur + classique de TDD (une idée de Manuel Rivero)
Garder une trace du temps à l'aide de Git Commits.
J'ai implémenté la fonctionnalité de transferts sûrs: le compte peut être configuré pour demander un code (par exemple, OTP) pour vérifier le transfert de fil, tous deux sortants (par exemple, la plupart des banques ont ceci) comme entrant.
J'ai étudié les moyens de conserver les propriétés acides, plutôt que de choisir un système finalement cohérent.
Comme paramètres de la classe de compte: code
Il s'agit de l'approche la plus simple: dépendez du type du paramètre pour décider du comportement de la classe.
En tant que machine d'état: code
Configurez les états et les transitions en tant que partie interne / externe de la classe de transfert, ce qui le rend plus générique et à l'épreuve du temps (yagni?)
Cela peut être représenté en utilisant l'héritage d'une classe commune (dans ce cas, transfert) ou à l'aide d'un wrapper (état <>) pour signifier l'état actuel. Pour le premier, il y a le code de production. Pour ce dernier, une partie de la partie implémentant une bibliothèque de machines d'État (en utilisant une voiture + son usine comme domaine)
Dans l'implémentation, il est moins sécurisé, moins à l'aise pour travailler avec cette implémentation, car les signatures de méthode sont assez ambiguës: tout état est représentable dans l'objet de transfert.
Comme (c'est-à-dire un calcul raté): code
Soit vous permet de représenter deux résultats de calcul explicites. La gauche a été utilisée pour signifier un transfert bloqué / sûr et à droite pour signifier un transfert non bloqué.
Cela ne permet de représenter que deux valeurs, de manière implicite: le consensus de l'équipe indique la gauche et la droite pour ces significations.
De plus, il est difficile de voir un Either<T,T> où les T sont les mêmes. Il est possible que cela soit causé par la machine d'état implicitement (héritée d'une classe commune) + le soit.
Comme Thunks (c'est-à-dire des calculs retardés): code
Un thunk a été passé comme paramètre et exécuté lorsqu'il est nécessaire. Ce système ne permet pas une persistance / stockage facile, car les fonctions ne peuvent pas être sérialisées / désérialisées.
En tant que flux de travail (c'est-à-dire, un ensemble d'étapes prédéfinies): [code] [https://github.com/alvarogarcia7/bank-kata-kotlin/tree/variant/control-safe-transfers-as-workflow]
Ce flux de travail a un ensemble d'étapes (qui peuvent être validés ou non), et à la fin, il y a un ensemble d'actions.
Sur la base de la façon dont il a été mis en œuvre (seules les données sont passées, mais pas le comportement), cela pourrait être sérialisé / exposé au repos.
f log --format="%s;%ct"|grep CLOCK|cut -d";" -f1 donne les messages f log --format="%s;%ct"|grep CLOCK|cut -d";" -f2 donne le temps en millis
Ensuite, copiez sur une feuille de calcul et calculez la différence lors de l'arrêt
