Discussion :

[Jimalexp]

Salut,

Jusqu'à présent on m'as toujours fais comprendre que dans la philosophie objet on devais se limiter à écrire des méthodes qui ont un rapport avec un objet.

Mais, est-ce que des écarts sont tolérés à ce niveau ? En procédural on décide de créer une fonction pour éviter la redondance de code ou pour avoir à sa disposition un morceau de code à caractère "utilitaire".

Selon l'un de mes formateurs un mélange des styles peut nuire à la performance d'un système. Dans ce cas, je me demande comment certains problèmes complexes où il y a beaucoup de manipulations sont résolus.

[HerQuLe]

Je suis pas tres experimenté mais je pense que tu peux tres bien faire des methodes utilitaires dans un objet pour les appeler, meme si ces methodes n'ont pas de rapport direct avec l'objet en question. Tu peux les déclarer private histoire qu'elles ne soient pas accessibles de l'extérieur.

Tu peux aussi créer une classe Outil avec toutes tes methodes en static

Tu peux aussi (cf ton exemple et comme l'a deja dit quelqu'un) créer la methode WeaponIsOk() dans ta classe Weapon directement et dans ta classe "controleur" faire un " w.WeaponIsOk()" plutot qu'un "WeaponIsOk(w)" (cf 3eme vs 1ere solution)




Etant donné que ta methode sera utilisée sur des objets Weapon uniquement la 3eme solution semble la plus adaptée a mon avis mais je peux me tromper ^^

[Jimalexp]

Je suis pas tres experimenté mais je pense que tu peux tres bien faire des methodes utilitaires dans un objet pour les appeler, meme si ces methodes n'ont pas de rapport direct avec l'objet en question. Tu peux les déclarer private histoire qu'elles ne soient pas accessibles de l'extérieur.

Ok, donc il s'agit bien d'une pratique acceptable. Ca me rassure parcequ'au fur et à mesure que j'avance, je me rends compte que l'approche que j'ai vu aux cours est de plus en plus contraignant. Sans doute as t-on voulu trop simplifier le concepte.

Au niveau maintenance c'est sans doute un plus. Par exemple, dans un exercice j'ai remarqué qu'un simple changement de table en Vector peut engendrer énormément de modifications. Si j'avais utilisé des méthodes intermédiaires (ex: une méthode next() ou previous() pour aller chercher des informations), il y aurais moins de travail. Ca s'appliquerais à toute forme de stockage d'informations.

Tu peux aussi créer une classe Outil avec toutes tes methodes en static

Est-ce que c'est courant de créer une classe qui peut être utilisée à la fois en statique et instantantié ? J'ai remarqué que les classes du genre String ne Java propose des méthodes qui sont valables dans les deux contextes. Par exemple, on peut faire un String.valueOf( reference) ou un string.valueOf(), string étant un objet de type String.

Tu peux aussi (cf ton exemple et comme l'a deja dit quelqu'un) créer la methode WeaponIsOk() dans ta classe Weapon directement et dans ta classe "controleur" faire un " w.WeaponIsOk()" plutot qu'un "WeaponIsOk(w)" (cf 3eme vs 1ere solution)

Etant donné que ta methode sera utilisée sur des objets Weapon uniquement la 3eme solution semble la plus adaptée a mon avis mais je peux me tromper ^^

Cette question est bien en rapport avec l'autre sujet. D'ailleurs, lorsqu'on a évoqué cette possibilité de grouper des tests, je me suis empressé de l'appliquer et cette approche est très satisfaisante.

[HerQuLe]

Je pense que cette pratique est acceptable en effet, par contre je ne vois pas l'interet de le faire dans ton cas dans la mesure ou tu as un objet Weapon sur lequel tu peux directement coder ta methode... Car de toute facon ta methode tu va la lancer sur une instance de l'objet weapon donc bon

[Tommy31]

Est-ce que c'est courant de créer une classe qui peut être utilisée à la fois en statique et instantantié ?

Non, et cela enfreint une règle qualité qui veut que si la classe possède une méthode statique, elle doit être appelée statiquement.

The static method valueOf( xxx ) from the type String should be accessed in a static way

[alex_pi]

De mon point de vue (mais je suis loin de vraiment maitriser la "modélisation" dans le monde objet), on devrait globalement suivre les règles suivantes pour savoir si l'on fait une méthode (donc dans la classe) ou une "procédure" (donc en dehors).
Si la fonction travaille sur une un objet d'une classe donnée ou de ses descendante, alors c'est une méthode. Typiquement, la longueur d'une chaine, la liste des voisin d'un nœud dans un graphe, l'age du capitaine, ou le type d'une arme.
Si la fonction travaille sur plusieurs objets de la même classe, ça dépend Si tous les objets sont "au même niveau", il semblerait raisonnable de définir un méthode statique dans la classe. Par exemple, mais c'est très discutable, une fonction de comparaison.
Si par contre un des objets a un rôle plus spécifique, ce serait plus une méthode que l'on appellerait sur l'objet spécifique avec les autres en argument. Par exemple si on a des objets imbriqués, on pourrait avoir une méthode "contient" pour savoir si a contient b (a.contient(b)).
Si la fonction travaille sur une interface, on est assez forcé de faire une procédure, sauf dans le cas où l'on a de l'héritage multiple au quel cas on peut étendre la classe. Je m'explique : si j'ai une interface pour les conteneurs qui fourni un itérateur sur les éléments (comparables) contenus, je peux vouloir définir une fonction max une fois pour toute. En java, il faut que je définisse une procédure (méthode statique dans une classe ConteneursUtils par exemple), qui attend un Conteneur<A> et retourne un A. Avec de l'héritage multiple, je peux fournir une classe abstraite Max, contenant les méthodes abstraites définissant un itérateur et la méthode concrete max. En faisant hériter mes classes de conteneurs de cette classe Max, j'ajoute "gratuitement" une méthode max. Néanmoins, ça ne couvre pas tous les cas d'utilisation de l'approche "procédure" puisque si une librairie me retourne un Conteneur sans l'avoir fait hériter de Max, je n'ai pas de méthode max à disposition. Une possibilité serait de l'encapsuler dans un autre conteneur qui ne fait qu'appeler les méthodes de l'objet sous jacent et ajoute une méthode max, mais ça ajoute un niveau d'indirection potentiellement lourd.

Il y a bien sûr d'autre cas, mais c'est pour dire qu'il ne me semble pas qu'on puisse dire "tout dans les méthodes" sans créer des situations totalement artificielle où l'on met finalement une procédure dans une méthode. En revanche, "un maximum dans les méthodes" me semble être effectivement assez proche de la "philosophie objet", et une approche plutôt saine.

[Jimalexp]

alex_pi, merci pour ton intervention. Je relirais ca plus tard pour y apporter une réponse.

Je pense que cette pratique est acceptable en effet, par contre je ne vois pas l'interet de le faire dans ton cas dans la mesure ou tu as un objet Weapon sur lequel tu peux directement coder ta methode... Car de toute facon ta methode tu va la lancer sur une instance de l'objet weapon donc bon

En fait, c'est un détail mais il y a certaines contraintes dues à la particularité de l'environnement. La classe Weapon est une classe standard comme String en Java. Subtituer une classe parent n'est évidemment pas possible (à moins qu'on ne soit disposé à réécrire toutes les classes enfants). Le script étant conçu pour un serveur, des modifications vont engendrer une incompatibilité avec les clients.

Aussi, autre particularité, les classes Actor comme Weapon sont à la fois instantié et "enregistré" auprès d'une partie avant de paraître à l'écran. J'utilise donc des agrégations faibles.

Non, et cela enfreint une règle qualité qui veut que si la classe possède une méthode statique, elle doit être appelée statiquement.

C'était un mauvais exemple. Il y a peut être une méthode qui corresponds mieux dans la classe Math. Prenons une classe Personne avec une méthode setNom() et une méthode getNumeroId() avec plusieurs surcharges :

En Java :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Personne p;

[...]

p.setNom( "Sarko" ); // public void setNom( String nom );

int id1 = p.getNumeroId(); // public int getNumeroId();

Personne.setNom( p, "Obama" ); // public static void setNom( Personne p, String nom );

int id2 = Personne.getNom( p ); // public static int getNumeroId( Personne p);

[Tommy31]

Oui, saches qu'en java, les statics ne sont pas une bonne pratique, et ceci pour diverses raisons, dont notamment l'extensibilité. Il vaut mieux déclarer une classe avec toutes les méthodes membres, et dont l'usage se fera par instanciation, et ceci même si l'objet est sans état.

Si l'instanciation doit être optimisée ou pour des raisons de praticité, il est possible d'appliquer sur la classe un pattern de singleton (ou de recourir à un framework proposant l'IOC.)