Problème pour utiliser méthodes et constructeurs

[Premium]

Bonjour,

A la compilation, d'un programme, j'obtiens ceci :

./QueryFactoryImpl.java:74: non-static method and(Query,Query) cannot be referenced from a static context
			return QueryFactory.and(query1, query2);
							   ^
./QueryFactoryImpl.java:80: non-static method or(Query,Query) cannot be referenced from a static context
			return QueryFactory.or(query1, query2);
							   ^
./QueryFactoryImpl.java:84: non-static method query(java.lang.CharSequence) cannot be referenced from a static context
			return QueryFactory.query(exp.substring(1));
							   ^
./QueryFactoryImpl.java:88: non-static method query(java.lang.CharSequence) cannot be referenced from a static context
			return QueryFactory.query(exp);
							   ^
4 errors

[Sentinel]

Il suffit que les méthodes qui appellent Query.or, Quary.and, etc ne soient pas statiques.

[Sentinel]

Et sur la méthode create, donc, sinon tu reportes le problème d'un cran...

Tu sais au moins à quoi ça sert, static ? J'ai plutôt l'impression que tu as copié/collé mon code sans chercher à comprendre comment ça fonctionnait...

[Premium]

Et sur la méthode create, donc, sinon tu reportes le problème d'un cran...

Tu sais au moins à quoi ça sert, static ? J'ai plutôt l'impression que tu as copié/collé mon code sans chercher à comprendre comment ça fonctionnait...

Si je comprends l'utilisation de static

La méthode pow de Math (par exemple) utilise ce principe

Le problème que j'avais est que je ne savais pas très bien comment retourné un objet Query dans la méthode create et getSpe...

Les return sont donc de la bonne forme ?

[Sentinel]

Ben oui, il suffisait de remplacer Matcher par Query, puisque tes objets s'appellent comme ça...

[Baldurien]

Non, mais je crois qu'il n'a pas trop voire pas du tout pigé le but des méthodes fournies par l'interface.

A la base, tu as une interface - Query - qui permet certainement (je dis ça, je dis rien) à un utilisateur externe de faire deux trois trucs sans trop savoir qui implémente la dîte interface.

Le problème d'avoir une interface c'est justement que tu ne sais pas qui/que/quoi l'implémente.

Tu as plusieurs choix :

1. tu es en mesure de l'implémenter (c'est le cas de Runnable, FileFilter, KeyListener, etc) et donc tu peux le faire toi même

2. tu as d'autres objets derrière (Index?) et certainement un ensemble plus complexe: celui qui va donc se servir de tes classes n'a pas à chercher quoi fait quoi, tu vas lui fournir une usine (miam les design pattern) qui saura construire des objets de type requête qui fonctionneront en fonction de tes besoins.

Et concrêtement, tu as ça :

public class MachinFactory implements QueryFactory {

 public Query or(Query a, Query b) {
return new Query() {
   // TODO 
};
 }

 public Query and(Query a, Query b) {
return new Query() {
   // TODO 
};
 }

 public Query query(String word) {
return new Query() {
   // TODO 
};
 }

 public Query query(Pattern regexp) {
return new Query() {
   // TODO 
};
 }
}

Me suis pas fait chier à faire 4 classes pour chaque méthode, mais le coeur y est (bon, c'est des classes anonymes).

Tu me diras "mais c'est ce que je fais", je te répondrais que non. Ce n'est pas ce que tu fais.

Toi tu crée juste un objet qui n'a pas l'air de faire ce qu'il doit faire : l'utilité d'une méthode "factory" c'est pour créer l'objet en fonction de quelque chose (ici : or, and, etc) pas de faire ce que doit faire l'objet. En l'occurrence, la méthode execute() doit faire tout ce sale boulot, pas la méthode factory...

(bon je dois avouer : je sais où se trouve le sujet de votre projet :>)