“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 284 — #294
i
i
i
i
i
i
i
i
284
6
• La programmation orientée objet
de transferts avec batchTransfer. Remarquez que batchTransfer appelle
transfer pour chaque transfert.
class Account
attr balance:0
meth transfer(Amt)
balance:=@balance+Amt
end
meth getBal(Bal)
Bal=@balance
end
meth batchTransfer(AmtList)
for A in AmtList do {self transfer(A)} end
end
end
Figure 6.6 Un exemple de classe Account.
Nous étendons Account pour tenir un journal, c’est-à-dire pour garder une trace de
toutes les transactions. Une solution est d’utiliser l’héritage pour redéfinir la méthode
transfer :
class LoggedAccount from Account
meth transfer(Amt)
{LogObj addEntry(transfer(Amt))}
...
end
end
où LogObj est un objet qui garde le journal. Nous créons un compte avec un journal
qui a un solde initial de 100 :
LogAct={New LoggedAccount transfer(100)}
Que se passe-t-il quand nous appelons batchTransfer ? Appelle-t-elle l’ancienne
transfer dans Account ou la nouvelle transfer dans LoggedAccount ?
Nous pouvons déduire la réponse, si nous supposons qu’une classe définit une abstraction de données en style objet. L’abstraction de données a un ensemble de méthodes.
Pour LoggedAccount, cet ensemble contient les méthodes getBal et batchTransfer définies dans Account et la nouvelle méthode transfer définie dans
LoggedAccount elle-même. Par conséquent, la réponse est que batchTransfer
doit appeler la nouvelle transfer dans LoggedAccount. Ce choix s’appelle un
lien dynamique. On l’écrit comme un appel à self, c’est-à-dire {self transfer(A)}.