Discussion :

[Jamming Ed]

Bonjour,

J'ai un petit problème de conception dont je n'arrive pas à me sortir.

J'ai une classe abstraite définie comme suit (simplifiée pour l'exemple) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public abstract class TableItem
{
	@com.google.gson.annotations.SerializedName("id")
	public long mId;
 
	@Override
	public boolean equals(Object o)
	{
		if(o instanceof TableItem)
		{
			TableItem item = (TableItem)o;
 
			return item.mId == this.mId;
		}
 
		return false;
	}
 
	public abstract JsonElement toJsonElement();	
	public abstract TableItem fromJsonElement(JsonElement je)
}

J'aimerais ensuite contruire une collection abstraite à partir de cette classe abstraite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public abstract class TableItemCollection extends ArrayList<TableItem>
{
	private static final long serialVersionUID = 8571119192423778503L;
 
	public TableItemCollection()
	{
	}
 
	public void add(JsonElement e)
	{
		TableItem item = new TableItem();
		this.Add(item.fromJsonElement(je));
	}
 
	public boolean exists(TableItem item)
	{
		for(TableItem i : this)
		{
			if(item.equals(i))
			{
				return true;
			}
		}
 
		return false;
	}
 
	public TableItem getItem(long id)
	{
		for(TableItem i : this)
		{
			TableItem item = (TableItem)i;
 
			if(item.mId == id)
			{
				return item;
			}
		}
 
		return null;
	}
}

La méthode "add" est fausse : En effet, il est impossible d'instancier TableItem dans la mesure où cette classe est abstraite. J'ai donc essayé de voir s'il était possible de déclarer la méthode fromJsonElement static pour l'appeler sans instancier la classe, mais c'est interdit en Java. Je tourne donc un peu en rond.

Cela veut-il dire que je suis obligé d'implémenter une collection pour chaque type dérivé de TableItem ?

JE.

[Nico02]

Salut,

Bon tu fais des choses un peu bizarre

Peux tu nous expliquer de façon claire ce que tu souhaites faire (et pourquoi donc écrire une classe qui redéfinie ArrayList ? ).

A mon avis tu as un gros problème de conception à la base

[Jamming Ed]

Salut,
Bon tu fais des choses un peu bizarre

C'est possible. Je suis assez tordu comme gars

But final en quelques mots :

Je bosse sur une application Android connecté au cloud Azure. Cette application utilise notamment plusieurs tables de données.

Jusqu'à présent, j'ai créé deux classes par table : L'une représentant un élément de la table, l'autre étant un ArrayList<Element> pour recueillir les éléments de façon synchrone avec la table correspondante dans le cloud + les méthodes (insert, update, delete, select / refresh).

Vient maintenant le moment de refactorer tout cela pour avoir quelque chose de plus cohérent (et surtout moins dupliqué). J'ai commencé par abstraire les éléments (c'est la classe TableItem) et j'aimerais faire de même avec les collections.

Est-ce assez clair comme explication ? Dois-je entrer plus dans les détails ?

JE.

[thelvin]

Je sais bien que quand on connaît pas vraiment, ArrayList ou juste List, ça a l'air d'être une bonne interface DAO.
Mais c'est pas le cas. Tout ce qui est à base d'index ça n'a rien à faire dans un DAO et ça ne peut causer que des problèmes, pas des avantages. Et ArrayList ne jure que par les indexes.
Mais bon ça n'a rien à voir avec ton problème. Je te dis juste que cette façon de faire est mauvaise. Mais le problème que tu as, tu l'auras quelle que soit la méthode.

La méthode fromJsonElement() ne peut pas rester dans cette classe. C'est ridicule de demander à un objet de se créer lui-même. Il te faut une nouvelle interface

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
JsonDeserializer<E> {
  E fromJsonElement(JsonElement je);
}

et ta "List" quand tu la crées, tu dois lui donner une instance de cette classe, qui ainsi pourra créer les objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public class TableItemCollection<E extends TableItem> extends ArrayList<E> {
 
  protected final JsonDeserializer<E> deserializer;
 
  public TableItemCollection(JsonDeserializer<E> deserializer) {
    this.deserializer = deserializer;
  }
 
  public void addFromJson(JsonElement e) {
    this.add(deserializer.fromJsonElement(je));
  }
 
}

[Jamming Ed]

Tout d'abord, merci pour ta réponse. Il y en a beaucoup plus que je n'attendais !

Je sais bien que quand on connaît pas vraiment, ArrayList ou juste List, ça a l'air d'être une bonne interface DAO.
Mais c'est pas le cas. Tout ce qui est à base d'index ça n'a rien à faire dans un DAO et ça ne peut causer que des problèmes, pas des avantages. Et ArrayList ne jure que par les indexes.

La gestion des données sera extrêmement simple et les aller-retours avec la base limités. Est-ce que ça vaut vraiment le coup d'utiliser une lib plus complexe ? Si oui laquelle me conseillerais-tu ?

La méthode fromJsonElement() ne peut pas rester dans cette classe. C'est ridicule de demander à un objet de se créer lui-même. Il te faut une nouvelle interface

On est bien d'accord. C'est même pour cela que je voulais la déclarer static pour pouvoir faire des appel du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
TableItem item = TableItem.fromJsonElement(e);

Mais à priori, c'est n'est pas possible de dire que la méthode dans la classe fille sera statique. Je vais essayer ta méthode. Question subsidiaire : Quand tu dis "interface" est-ce une interface au sens Java ? Si oui, où dois-je implémenter cette interface ?

et ta "List" quand tu la crées, tu dois lui donner une instance de cette classe, qui ainsi pourra créer les objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public class TableItemCollection<E extends TableItem> extends ArrayList<E>

J'avais bien tenté un truc à base de classe générique, mais sans rien arriver à faire. Je ne connais pas cette notation. Veut-elle dire que le type E doit forcément hériter de TableItem ?

[Jamming Ed]

Petit update :

La solution proposée fonctionne parfaitement bien. J'ai créé une interface comme préconisé + un classe qui implémentant cette interface par classe dérivée de TableItem. Ces objets de désérialisation spécialisés sont passés dans le constructeur des classes dérivées de TableItemCollection et le tour est joué.

Merci pour le coup de main.

[thelvin]

Bien joué.

Est-ce que ça vaut vraiment le coup d'utiliser une lib plus complexe ? Si oui laquelle me conseillerais-tu ?

Ça vaudrait le coup de planquer l'ArrayList à l'intérieur d'un autre objet muni du add(JsonElement) et des méthodes utiles, au lieu de juste hériter de ArrayList et avec elle plein de méthodes de List qui n'ont rien à faire là.

Après, voir si un HashMap ou un HashSet ne serait pas plus utile qu'une ArrayList. Mais bon, pas forcément.

Je ne connais pas cette notation. Veut-elle dire que le type E doit forcément hériter de TableItem ?

Oui. Il serait plus exact de dire que E a obligation d'être un sous-type de TableItem (ou TableItem lui-même.)