J'ai des classes qui utilisent des collections. =C9videmment, ces
collections ne doivent =EAtre modifi=E9es qu'au travers des m=E9thodes de
mes classes. Par exemple :
public class ListeDePoints {
private Set _points;
private Map _couleurDuPoint;
public void add(Point point, Couleur couleur)
{
_points.add(point);
_couleurDuPoint.put(point,couleur);
}
// ....
}
Je veux que l'utilisateur ait acc=E8s =E0 certaines collections. Mais je
ne veux pas :
-- l'utilisateur puisse modifier les collections autrement que par mes
m=E9thodes
-- renvoyer un it=E9rateur (l'utilisateur peut vouloir l'ensemble et je
ne veux pas qu'il fasse une copie de l'ensemble ; d'ailleurs,
l'it=E9rateur lui permettrait de transgresser le premier point)
-- renvoyer une copie de l'ensemble (trop co=FBteux)
J'ai d=E9fini des classes Safe* (par exemple SafeIterator, SafeSet) qui
encapsulent les classes de java.util mais ne supportent pas les
m=E9thodes optionnelles (remove, add, etc.), et je renvoie une version
encapsul=E9e des collections.
public Iterator iterator()
{
return new SafeIterator(_points.iterator());
}
public Set points()
{
return new SafeSet(_points);
}
Connaissez-vous une impl=E9mentation d=E9j=E0 existante, =E9ventuellement p=
lus
efficace, de ce probl=E8me ?
Question subsidiaire :
dans mon exemple au dessus, est-il utile d'avoir un Set pour la liste
des points, ou serait-il aussi efficace d'utiliser
_couleurDuPoint.keySet() ? La m=E9thode keySet() a-t-elle un co=FBt ou est-
elle triviale (je parle des impl=E9mentations classiques) ? (Il est
entendu qu'avec keySet(), je ne peux pas faire d'ajout, mais ce n'est
pas grave.)
On Mar 22, 5:36 pm, Hervé AGNOUX informatique.com.zz> wrote:
Cela t'irait-il ?
Excellent ! C'est exactement ce que je cherchais.
Tu as une réponse pour ma question subsidiaire ?
Bonsoir,
Un coup d'il dans les sources te donneras t'en apprendra plus sur ce point ...
A+ TM
Hervé AGNOUX
MattBan wrote:
Tu as une réponse pour ma question subsidiaire ?
J'avoue être toujours ennuyé par ce genre de question... Pour décider d'écrire une méthode ou une classe, le principal est de savoir si elle correspond à quelque chose de la réalité, et non pas si elle est couteuse ou facile ; "Early Optimisation Is The Mother Of All Evil And Emmerdements", disait Zaratoustra.
Savoir si la méthode keySet a un cout ?... Non.
Si elle est facile ?... Oui.
... cela te va, comme réponse ? :-)
-- Hervé AGNOUX http://www.diaam-informatique.com
MattBan wrote:
Tu as une réponse pour ma question subsidiaire ?
J'avoue être toujours ennuyé par ce genre de question... Pour décider
d'écrire une méthode ou une classe, le principal est de savoir si elle
correspond à quelque chose de la réalité, et non pas si elle est couteuse
ou facile ; "Early Optimisation Is The Mother Of All Evil And
Emmerdements", disait Zaratoustra.
J'avoue être toujours ennuyé par ce genre de question... Pour décider d'écrire une méthode ou une classe, le principal est de savoir si elle correspond à quelque chose de la réalité, et non pas si elle est couteuse ou facile ; "Early Optimisation Is The Mother Of All Evil And Emmerdements", disait Zaratoustra.