Exemples d'applications Eiffel autour du concept de compte bancaire
Olivier Ligot
Nous venons d'opensourcer quelques exemples d'applications Eiffel autour du concept de compte bancaire.
Ils implémentent le patron de conception Model-View-Controller avec les propriétés intéressantes suivantes :
- 3 vues différentes :
* interface en ligne de commande
* interface graphique (utilise EiffelVision2)
* interface web (utilise HTML5 et Ajax du côté client et EiffelWebFramework du côté serveur)
- les 3 vues utilisent les mêmes classes pour la partie modèle et la partie contrôleur
- tire avantage des dernières avancées technologiques d'Eiffel, en particulier :
* ECF
* Void-Safe
* agent
* Action sequence
Il y a aussi un fichier pdf qui expliquer
* l'architecture
* les spécifications
* l'analyse
des applications
Le projet est disponible sur Github : https://github.com/GroupeS/bank_account
N'hésitez pas à le cloner, le forker, introduire des pull requests, ...
En espérant que ça vous plaise...
Cordialement,
Olivier Ligot
Group S
Jocelyn Batton
Jocelyn Batton
Paul G. Crismer
Salut Jocelyn,
Merci de votre intérêt pour le projet "bank_account".
Il s'agit du projet « exemple » construit pour un cours « Application de l'Orienté-Objet avec Eiffel ».
La première chose que j'enseigne, c'est l'abstraction. C'est-à-dire de raisonner sur les choses et pas sur leur représentation.
Créer BANK_ACCOUNT_NUMBER est intéressant parce que cela met en valeur la notion-même de numéro de compte bancaire.
Comme premier jet on enrobe juste un string. Cela ne mange pas de pain.
D'autre part cela met en valeur le fait que le numéro associé à un compte n'est pas juste un entier ou une chaîne de caractères et qu'il y a des contraintes et une sémantique à respecter. Enfin, cela décomplexe le développeur débutant qui a « peur » de créer une classe, mais est à l'aise d'utiliser ce qui existe déjà.
Dans la réalité cette classe exposerait certainement d'autres services très utiles. Selon le point de vue, juste un numéro ou une chaîne de caractères. Mais aussi la banque, l'agence, un nombre de contrôle, une correspondance européenne avec BIC et IBAN, etc...
Enfin du point de vue typage, la classe BANK_ACCOUNT_NUMBER se justifie parce que j'ai pas envie qu'on vienne mettre n'importe quel numéro ou chaîne de caractères; quelle différence entre un integer et un integer ? Par contre le compilateur m'aide parce qu'il distingue très bien une instance de BANK_ACCOUNT_NUMBER et de SOCIAL_SECURITY_NUMBER. Vous me suivez?
Idem pour BANK_ACCOUNT_TRANSACTIONS. Cette abstraction représente bien des
transactions bancaires dans le domaine du problème.
Le fait qu'on utilise un stack, une file, ou autre chose est vraiment secondaire.
Imaginez qu'on veuille ajouter une opération « purge », qui purge les transactions vieilles de n mois. Avec BANK_ACCOUNT_TRANSACTIONS, c'est facile à ajouter : la méthode 'purge' et son implémentation. Un client écrirait ainsi 'transactions.purge'. Et le code se rapproche de l'analyse...
Avec une LINKED_STACK comment on ferait ?
Je serais curieux de voir comment vous réagissez à ma
réponse.
Cordialement,
Paul G. Crismer
Jocelyn Batton
Désolé pour la lenteur de ma réponse.
si l'on se réfère à la notion d'ADT évoquée dans le livre de Bertrand
Meyer, il faut appliquer le "principe d'égoïsme" i.e ne considérer une
entité que pour ce qu'elle apporte. Dans le cas présent, le numéro de
compte ne possède aucune "opération" spéciale digne de ce nom. Je vous
l'accorde, c'est une application "simple" (aucune connotation
péjorative dans cet adjectif) et une notion de "numéro bancaire"
pourrait naître.
Cependant, ce "pourrait" ne doit pas, selon moi, engendrer une
création "abusive" de classes. Par là j'entends que ce comportement
pourrait tenter le concepteur (vos élèves) de créer à tort et à
travers une classe qui ne "servirait" pas.
J'ai vu assez souvent des classes dans d'autres langages ne comprenant
qu'une seule routine et dont le nom de la routine était le nom de la
classe ou un nom s'en approchant grandement => la classe n'en est pas
une, c'est une simple routine appartenant à une classe qui n'a pas
identifiée.
En d'autres termes, la règle fondamentale que je m'impose lorsque je
crée une classe est : y-a-t-il des opérations pertinentes sur ce type
que j'envisage de créer ? Si oui, alors une classe émerge. Sinon, je
ne tente pas de prévoir le "futur".
Concernant "Enfin du point de vue typage, la classe
mettre n'importe quel numéro ou chaîne de caractères; quelle
envisager que le numéro de compte ne soit qu'un attribut de type
INTEGER ou STRING de la classe "BANK_ACCOUNT". Cet attribut pourrait
être engendré "automatiquement" à la création du compte en banque dont
la valeur serait généré à l'aide d'une autre entité, peut-être
"BANK_ACCOUNT_HANDLER" chargé de gérer tous les comptes en banque avec
en particulier la responsabilité du bon format du numéro ? (ceci n'est
qu'une première idée). Ceci entrainerait bien évidemment la
disparition du setter sur "number" dans votre classe.
Cette idée m'est venue car dans le setter de number, rien n'empêche de
créer deux instances de "BANK_ACCOUNT" avec le même numéro de compte
en banque, et ce, même si l'on crée une classe spéciale
"BANK_ACCOUNT_NUMBER" (même si on peut le mettre comme précondition du
setter...)
>
> Idem pour BANK_ACCOUNT_TRANSACTIONS. Cette abstraction représente bien des
> transactions bancaires dans le domaine du problème.
>
> Le fait qu'on utilise un stack, une file, ou autre chose est vraiment
> secondaire.
>
> Imaginez qu'on veuille ajouter une opération « purge », qui purge les
> transactions vieilles de n mois. Avec BANK_ACCOUNT_TRANSACTIONS, c'est
> facile à ajouter : la méthode 'purge' et son implémentation. Un client
> écrirait ainsi 'transactions.purge'. Et le code se rapproche de l'analyse...
>
> Avec une LINKED_STACK comment on ferait ?
liste (à prendre dans le sens français et non informatique du terme)
de "BANK_ACCOUNT_TRANSACTION" qui ne possède pas d'opération "digne de
ce nom". Si la notion de purge est évoquée plus tard alors je suis
tout à fait d'accord qu'une telle classe se justifiera.
L'idée sous-jacente pour tout ceci est bien de ne pas essayer de "tout
prévoir à l'avance".
> Je serais curieux de voir comment vous réagissez à ma réponse.
>
> Cordialement,
>
> Paul G. Crismer
discussion très intéressante.
Cordialement,
Jocelyn Batton
Olivier Ligot
Juste pour vous dire que j'ai mis à jour le projet pour qu'il fonctionne avec la version de EWF qui est livrée avec EiffelStudio 7.2.
A noter qu'une version du projet est toujours disponible pour les utilisateurs d'EiffelStudio 7.1 via l'étiquette ise7.1.
Cordialement,
Olivier
Jocelyn Batton
--Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Groupe des Eiffelistes Francophones.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
Victorien Elvinger
Victorien ELVINGER