Discussion :

[Magicien d'Oz]

Salut,

Alors voilà le truc. La dernière fois, j'ai fait une classe avec une méthode main et plein d'autres méthodes super pratique pour le calcul matriciel et vectoriel. Des simples boucles sur des tableaux, mais pratiques. Bref, là je vais faire un autre programme qui va aussi manipuler des matrices et j'aurai voulu réutiliser toutes ces méthodes sans faire un copier coller. Comment-puis je faire ? Ya t il possibilité de faire un genre de package assez simplement ?

Merci et bonne journée.

[sozie9372]

Tu as 2 possibilités...
Soit tu ajoutes ta classe "Utile" a ton projet et tu crées un objet "Utile". Tu pourras ainsi appeler les méthodes publiques de cet objet sans avoir à faire de copier/coller.
Soit tu crées un jar contenant ta classe "Utile" que tu importeras dans le classpath de ton projet. Tu pourras alors, comme précédement, créer un objet "Utile" grâce auquel tu appeleras les méthodes publiques de la classe "Utile"

[KiLVaiDeN]

Salut,

Il va falloir modifier ta Classe existante, pour la transformer en une sorte de librairie de fonctions.

Pour ça, par exemple, tu la nommeras "MatriceUtilities.java", et elle contiendra des méthodes "static" qui seront donc accessibles directement, sans instancier d'objet. De toutes façons je pense qu'elles sont déjà en static, si tu les utilisais directement dans le main. Tu appelleras les méthodes par : MatriceUtilities.calculMatrice(); par exemple.

Ensuite, pour l'inclure dans un nouveau projet, tout dépend de l'outil que tu utilises pour coder. Sous Eclipse par exemple, tu pourras faire de la dépendance de projet, en créeant un projet qui serait ta librairie ( contenant donc ta classe de Matrices ).

Une façon plus propre de faire cela ( je la signale quand même ) serait de faire de ta classe un singleton (cf le net pour savoir ce que c'est).

Ensuite, tu appellerais ta méthode avec MatriceUtilities.getInstance().calculMatrice();

A+

[Magicien d'Oz]

Ok, merci beaucoup.

Mais juste pour chipoter, il n'y a pas moyen d'éviter d'écrire à chaque fois "MatriceUtilities.", on peut pas mettre juste le nom de la méthode ?

[KiLVaiDeN]

Le fait est que Java est un langage par objets.

Donc quand tu fais appel à une méthode, il est courant et normal ( même obligatoire dans la plupart des cas ) de nommer l'objet qui contient la méthode, ou dans le cas de méthode statiques, de la classe.

Donc dans ton cas, oui il faudra toujours préciser MatriceUtilities.

Par contre, dans le cas que j'ai donné de l'utilisation d'un singleton, tu peux avoir quelque chose de plus compacte :

Code :

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

1
2
MatriceUtilities mu = MatriceUtilities.getInstance(); // Récupération de l'instance
mu.calculerMatrice();

Tu es toujours obligé d'utiliser le nom de l'objet ici, mais il est plus court, tu pourrais le nommer comme tu veux.

[Magicien d'Oz]

ok et merci

Au vu de l'utilisation que je vais en faire, je pense que je vais juste utiliser la première solution : un fichier regroupant toutes les méthodes appelée à chaque fois par MatriceUtilities.SommeMatrice par exemple.

Merci

[le y@m's]

Ok, merci beaucoup.

Mais juste pour chipoter, il n'y a pas moyen d'éviter d'écrire à chaque fois "MatriceUtilities.", on peut pas mettre juste le nom de la méthode ?

C'est possible depuis Java 5 avec l'import static
cf FAQ : [Java 5.0] Qu'est-ce que l'import static ?

[KiLVaiDeN]

Bien vu, le y@m's

Mais l'utilisation d'un singleton est bien plus puissante de toutes façons que celle d'une classe statique : en effet, on peut alors avoir un vrai objet en mémoire, qui aura ses attributs et ses propres liens, vers d'autres objets, je pense par exemple aux systèmes de Logs, aux liens vers d'autres objets métiers, etc..

Dans le cas d'une classe statique, ces liens seraient à refaire à chaque appel de la méthode.

[le y@m's]

Bien vu, le y@m's

Mais l'utilisation d'un singleton est bien plus puissante de toutes façons que celle d'une classe statique : en effet, on peut alors avoir un vrai objet en mémoire, qui aura ses attributs et ses propres liens, vers d'autres objets, je pense par exemple aux systèmes de Logs, aux liens vers d'autres objets métiers, etc..

Dans le cas d'une classe statique, ces liens seraient à refaire à chaque appel de la méthode.

Ce que tu dit est vrai mais je ne pense pas que dans ce cas un singleton sois utile. En effet, les méthodes n'ont, a priori, aucun lien entre elles et sont toutes static. De ce fait il me parait inutile de vouloir construire une architecture ayant un semblant d'objet alors que l'on est dans une logique toute procedurale.
Le singleton trouve toute sont utilité dans le cadre d'une classe de type factory mais n'apporte, ici, rien du tout (aucun lien entre les differentes méthodes, aucun attribut n'est rattaché à une instance (que du static)).

Personnellement j'ai plusieurs classes de ce genre (avec uniquement des méthodes static) et je me contente de déclarer le constructeur par défaut private afin d'empécher l'instanciation de la-dite classe, ensuite un simple import static et le tour est joué .

[KiLVaiDeN]

Le fait est que dans les applications que je fais, je mets constamment des singletons, plutot que des classes avec des méthodes statiques; comme tu dis, il y a des cas où ça sert, mais rien que pour les cas où on a besoin d'un singleton, je me dis qu'il vaut mieux tout homogéiniser, et avoir un système qui fonctionne pour la globalité et qui donc puisse évoluer simplement

[sozie9372]

Eh ben avec tout ca Magicien d'Oz si tu n'y arrives pas

[mavina]

Le fait est que dans les applications que je fais, je mets constamment des singletons, plutot que des classes avec des méthodes statiques; comme tu dis, il y a des cas où ça sert, mais rien que pour les cas où on a besoin d'un singleton, je me dis qu'il vaut mieux tout homogéiniser, et avoir un système qui fonctionne pour la globalité et qui donc puisse évoluer simplement

han

La logique du "ca marche partout ? je ne fais que ca" est un peu périmée
Je pense que Yams a raison, on est dans une logique de travail sur des matrices, et l'on n'a pas trop d'interet à faire un objet. Dans son cas (pas de copier coller), passer ses methodes en static et faire un import static me parrait la meilleure solution.

Bien à vous

Fred

[Magicien d'Oz]

Ah j'avais pas vu tout ça !!

Merci, je garde l'idée de l'import static. Mais je met quoi derrière, le nom de mon fichier, le chemin sur le disque ?

[KiLVaiDeN]

han

La logique du "ca marche partout ? je ne fais que ca" est un peu périmée
Je pense que Yams a raison, on est dans une logique de travail sur des matrices, et l'on n'a pas trop d'interet à faire un objet. Dans son cas (pas de copier coller), passer ses methodes en static et faire un import static me parrait la meilleure solution.

Bien à vous

Fred

C'est pas une logique de type "ça marche partout, je ne fais que ça" mais plutot "c'est plus puissant et évolutif, même si je n'ai pas besoin tout de suite d'un objet type singleton pour le lier à d'autres objets, on ne sait jamais, le besoin pourrait se présenter"

Ah j'avais pas vu tout ça !!

Merci, je garde l'idée de l'import static. Mais je met quoi derrière, le nom de mon fichier, le chemin sur le disque ?

J'ai pas compris ta question.. l'import statique, c'est juste comme un import java classique, donc tu fournis le chemin de la classe Java dans ta hierarchie de package de ton projet

[le y@m's]

Merci, je garde l'idée de l'import static. Mais je met quoi derrière, le nom de mon fichier, le chemin sur le disque ?

J'ai pas compris ta question.. l'import statique, c'est juste comme un import java classique, donc tu fournis le chemin de la classe Java dans ta hierarchie de package de ton projet

Pour être plus précis tu peux
soit importer toutes les méthodes static d'une classe en spécifiant le nom de la classe (packages inclus) suivant de .*

Code :

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

import static packages.MaClasse.*;

soit spécifier directement la ou les méthodes voulues (si tu n'as besoin que de deux méthodes alors que ta classe en contient 50, inutile de toutes les importer )

Code :

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

1
2
import static packages.MaClasse.methode1;
import static packages.MaClasse.methode2;

[Magicien d'Oz]

Bon je déterre un peu le topic là mais je bloque sur un truc là.

J'ai ma classe QuadOpt, et ma classe Matrix qui contient toutes mes méthodes static de calcul matriciel. Je dois donc faire import static dans la classe QuadOpt pour importer les méthodes de la classe Matrix.
Quelle est la syntaxe à utiliser ?

J'ai essayé import static Matrix.* mais ça marche pas.

[KiLVaiDeN]

Bon je déterre un peu le topic là mais je bloque sur un truc là.

J'ai ma classe QuadOpt, et ma classe Matrix qui contient toutes mes méthodes static de calcul matriciel. Je dois donc faire import static dans la classe QuadOpt pour importer les méthodes de la classe Matrix.
Quelle est la syntaxe à utiliser ?

J'ai essayé import static Matrix.* mais ça marche pas.

Il faut donner le chemin de tes packages:

Code :

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

import static packages.Matrix.*;

en considérant que ta classe Matrix, se trouve dans un répertoire ( package ) "packages".

[Magicien d'Oz]

ouais mais j'ai pas de packages. Jsuis sous eclipse et j'ai juste fait un nouveau projet. Sinon le chemin physique c'est
/home/toto/PROJETS/Méthode\ du\ gradient/

[KiLVaiDeN]

Tu l'as ajouté donc au package par défaut ?

Je te conseillerais de créer un package et de la mettre dedans, il est fortement déconseillé d'utilisé le package par défaut.

Place toi en perspective Java, et tu verras les packages. Tu peux cliquer droit sur ta classe pour la déplacer ( Refactore / Move ).

Ensuite tu pourras mettre le bon chemin.

[Magicien d'Oz]

Ah ok, j'ai compris et ça marche !

Mais je vois pas la différence entre le (default package) et mon package à moi, à part que dans le premier, j'ai pas choisi le nom.

Merci en tout cas !