[Java] Le topic-passage-obligé pour débutants !

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 24 25 26 27 28 29 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [Java] Le topic-passage-obligé pour débutants !

boulax

Inserer phrase hype en anglais

Reprise du message précédent :
Les interfaces

Une interface java est un type de données servant de modèle que des classes peuvent choisir de suivre. On parle alors de classes qui implémentent telle ou telle interface. Une classe peut implémenter plusieurs interfaces. A quoi cela-sert-il ? En définissant une interface, nous pouvons coder des comportements communs à des classes qui à priori n'ont rien en commun. Cela permet également de séparer la spécification du codage à proprement parler.

En tant que modèle pur, une interface ne contient pas de code mais uniquement les prototypes des méthodes qu'impose le modèle. Prenons un exemple:

Code :

public interface Mangeable
{
public void manger();
public boolean aCuire();
}

Nous avons défini une interface "Mangeable". Il y a deux méthodes qui caractérisent l'interface. Vous allez vite comprendre l'interêt par la suite.

Parlons implémentation: les classes voulant se plier au modèle "Mangeable" doivent implémenter chacune des méthodes de cette classe, c'est à dire en fournir le code. Rien ne vous empêche par ailleurs de ne pas en metttre (comme c'est le cas dans la famille des classes Adapter de awt.event mais c'est une autre histoire). L'indispensable, c'est à dire ce que le compilateur impose, c'est de redéfinir les méthodes. Imaginons deux classes:

Code :

class Patate
{
private int calibre;
public boolean estPourrie;
public Patate(int _calibre, boolean _estPourrie)
{
this.calibre = _calibre;
this.estPourrie = _estPourrie;
}
public int getCalibre()
{
return calibre;
}
public Frite frire()
{
[...]
}
// etc...
}
class Radis
{
private int force;
private boolean estSale;
public Radis(int _force, boolean _estSale)
{
[...]
}
public int getForce()
{
return force;
}
public void setSale( boolean sel)
{
estSale = sel;
}
// etc ...
}

A priori ces classes n'ont rien en commun niveau codage mais on sent bien qu'elle sont sémantiquement proches ( [:neuf] ). Laissons opérer la magie des interfaces. Nous allons implémenter l'interface "Mangeable" avec ces deux classes Patate et Radis en utilisant le mot-clé implements, le principal étant de redéfinir les méthodes manger et aCuire.

Code :

class Patate implements Mangeable
{
private int calibre;
public boolean estPourrie;
public Patate(int _calibre, boolean _estPourrie)
{
this.calibre = _calibre;
this.estPourrie = _estPourrie;
}
public Frite frire()
{
[...]
}
// implementation de l'interface Mangeable
public void manger()
{
Frite f = Frire();
// imaginons que frite implémente Mangeable
f.manger();
}
public boolean aCuire()
{
return true;
}
}
class Radis implements Mangeable
{
private int force;
private boolean estSale;
public Radis(int _force, boolean _estSale)
{
[...]
}
public int getForce()
{
return force;
}
public void setSale( boolean sel)
{
estSale = sel;
}
// implementation de l'interface Mangeable
public void manger()
{
setSale(true);
}
public boolean aCuire()
{
return false;
}
}

Vous commencez à saisir le truc. En implémentant l'interface "Mangeable" dans ces deux classes, nous en avons fait des sortes de cousines. L'interface étant un type de données au même titre que les classes, nous pouvons écrire des algorithmes souples et élégant avec ces types.

Attention toutefois: une interface ne peu pas s'instancier, cela n'a pas de sens A l'éxecution, ce sont des classes qui implémentent l'interface qui seront utilisées.

Nous pouvons imaginer ceci:

Code :

class Test
{
public void mangePresqueTout(Vector v)
{
Enumeration e = v.elements();
while ( e.hasMoreElements() )
{
Mangeable m = (Mangeable) e.next();
// on est un peu faineant ^^
if ( ! m.aCuire() )
{
m.manger();
}
}
}
public static void main(String [] args)
{
Vector menu = new Vector();
menu.add( new Patate() );
menu.add( new Radis() );
mangePresqueTout(menu);
}
}

Et voila

Message édité par boulax le 03-06-2005 à 08:34:11

---------------
Posté depuis des chiottes, sales. Me gusta.

Publicité

the real moins moins

boulax > c'est bien mais il me semble qu'il y a des imprécisions, et, perso, dans ce topic je voyais plutot des trucs de 5 lignes maxi quoi (avec renvois vers des trucs plus complets si necessaires)

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

darklord

You're welcome

comme tu le casses

boulax

Inserer phrase hype en anglais

j'ai l'habitude

---------------
Posté depuis des chiottes, sales. Me gusta.

Giz

Lunatik3 a écrit :

il y a une version plus recente de think in java, en français

voila

java 2 (1.2), tu appelles ca récent ? :sarcastic:

Giz

boulax ou kk1 d'autre > suite aux interfaces, ce serait bien de raconter l'histoire des compareTo() ou equals() à surcharger pour ne pas avoir de comportements bizarres du prog
...bon hashCode() on s'en sert pas tous les jours pis la pour bien expliquer,faut partir dans "comment fonctionne le hashCode" et donc dans ce cas je renvoie au topic de benou (...que j'ai la flemme de rechercher )

nraynaud

lol

Giz > certes, mais il est interdit de toucher à equals sans toucher à hashCode. Et il est fortement recomandé (" It is strongly recommended" ) que equals et compareTo soient en phase. ce qui veut dire qu'on touche généralement aux 3 d'un coup.

---------------
trainoo.com, c'est fini

Giz

ben t'en que tu utilises pas de map, hashCode() tu t'en fiches. Sinon tu as parfaitement raison, c'est chiant d'avoir à tout coder d'un coup dès qu'on se sert d'une de ces méthodes (ce que je ne fais pas systématiquement d'ailleurs [:ke-c] )

nraynaud

lol

Giz a écrit :

ben t'en que tu utilises pas de map, hashCode() tu t'en fiches.

[:xx_xx] et qui te dit que quelqu'un d'autre n'en utilisera pas ?

edit : je dis ça parce le coup de l'objet qu'on retrouve pas dans une hashmap, c'est 3h de debug avant d'engueuler le responsable, donc autant tout éviter d'un coup. et c'est pas compliqué à éviter.

edit 2 : un truc aussi con que spring ou un framework d'injection des dépendances par les constructeurs a toutes les chances d'utiliser une hashmap en interne par exemple.

Message édité par nraynaud le 06-06-2005 à 01:26:23

---------------
trainoo.com, c'est fini

Giz

Bingo, encore un point, décidément jme tais ! mais va expliquer le hashCode() au débutant...ca devient long après, c'est pas ce que veux TR-- [:spamafote] .
Bref encore une fois, j'ai juste soulevé le problème .

Bon je crois qu'il faut arreter le chat la...ca rôde .

Publicité

nraynaud

lol

Giz a écrit :

Bingo, encore un point, décidément jme tais ! mais va expliquer le hashCode() au débutant...ca devient long après, c'est pas ce que veux TR-- [:spamafote] .

c'est exactement mon point de vue :
1) c'est typiquement le truc à pas expliquer trop tôt
2) c'est un truc dont le besoin peut arriver assez vite pour les débutants

=> c'est chiant, mais ne parler que de equals() séparément n'est pas une solution.

Je pense par contre qu'on peut oublier compareTo() dans les premières approches.

D'autre part, je pense qu'il est *extrèmement* important de parler de pédagogie (surtout de confronter les points de vue), la science de l'enseignement. Donc si -- n'est pas jouasse, :fuck:

---------------
trainoo.com, c'est fini

benou

nraynaud a écrit :

pas d'accord ...
écrire la méthode compareTo, c'est implémenter Comparable. Et implémenter Comparable c'est la plupart du temps une connerie ! Les objets naturellement comparables sont très très rares (ex : Integer l'est, String l'est déjà moins). La comparaison des objets est la plupart du temps une notion qui dépend du contexte d'utilisation de l'objet et pas une propriété intrinsèque de l'objet.
Bref, la plupart du temps il est préférable de faire un Comparator à côté de l'objet plutot que d'implémenter Comparable.

Ce qui est "strongly recommended" c'est que si tu déclares compareTo, equals soit synchrone avec cette définition. Ce n'est pas du tout qu'il faut déclarer compareTo si tu déclares equals.

---------------
ma vie, mon oeuvre - HomePlayer

nraynaud

lol

benou a écrit :

[:ah_bon] [:kiki]

---------------
trainoo.com, c'est fini

benou

nraynaud a écrit :

[:ah_bon] [:kiki]

trop d'argumentation tue l'argumentation ? :??:

---------------
ma vie, mon oeuvre - HomePlayer

R3g

fonctionnaire certifié ITIL

Moi j'suis assez d'accord avec Benou

---------------
Au royaume des sourds, les borgnes sont sourds.

Jubijub

Parce que je le VD bien

Job's done (avec la voix des peons dans Warcraft en VO)

http://forum.hardware.fr/hardwaref [...] 2053-1.htm

---------------
Jubi Photos : Flickr - 500px

the real moins moins

1ere page updated [:joce]

(la concision et toi ça fait vraiment deux hein??? [:nofret] )

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

Jubijub

Parce que je le VD bien

ben le but c d'éviter un tas de question...mais c difficile à évaluer, tu peux toujours contester le choix...

et pis merde, au moins g contribué...

---------------
Jubi Photos : Flickr - 500px

the real moins moins

mais oui

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

Profil supprimé

drap

Jubijub

Parce que je le VD bien

stiky :pfff:

---------------
Jubi Photos : Flickr - 500px

Harkonnen

Modérateur
Un modo pour les bannir tous

we've got a winner [:rofl2]

---------------
J'ai un string dans l'array (Paris Hilton)

the real moins moins

ben, ça te met un drapeau quand y'a des nouveautes, ça peut etre interessant.
et la pollution-> [] please.

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

veryfree

hello,
pourquoi ca ne passe plus -mx64m le jre 1.5 ?

the real moins moins

parce que ça a toujours été -Xmx et pas -mx ?
(spa un topic de discute ici, et spa trop une question de noob ça [:icon12] )

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

veryfree

merci pour l'info j'ai toujours été dans le faux avec ce truc alors [:boidleau]

the real moins moins

j'crois, oui [:pamplemousse]
vérifie:
http://java.sun.com/docs/hotspot/VMOptions.html
http://blogs.sun.com/roller/resour [...] -list.html

Message édité par the real moins moins le 21-06-2005 à 12:49:29

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

Master_Jul

sircam a écrit :

Jubijub >

Citation :

toute autre méthode utilisant la première méthode doit "catcher" l'exception, c'est à dire utiliser un bloc try/catch/(finally) pour indiquer au programme ce qui doit se passer si une exception est générée. Ce try/catch est obligatoire pour toutes les exceptions, sauf pour les RuntimeException, pour lesquelles il est facultatif.

C'est bien entendu incorrect - je suppose que tu as voulu trop simplifier. Il est bien sûr possible et souvent souhaitable de laisser l'exception se propager.

Par contre, j'insisterais lourdement sur la pratique à prohiber du catch and burry :

Code :

try {
... // code qui peut générer une exception
}
catch (Exception e) {
}

C'est acceptable dans des cas tout à fait exceptionnel, et ça s'accompagne toujours d'un commentaire adéquat dans le catch.

Hello tout le monde, bon c'est une remontée un peu vieille mais toujours d'actualité je pense.

J'aimerais que quelqu'un puisse m'expliquer plus clairement ce post, qu'est ce qu'il y a de mal dans la méthode du try / catch tel qu'il est exposé ici ? Dans quel cas est-il utile voir nécessaire de laisser se propager une exception ? Je précise que je débute en programmation C++ et plus particulièrement C# en ce moment. Je viens de finir un chapitre sur les exceptions.

Merci :hello:

Message édité par Master_Jul le 26-06-2005 à 18:19:03

chrisbk

la il recupere tout ce qui passe et fait rien du tout. Le fait qu'il y ait eu une erreur, et les infos sur cette erreur sont perdus

Master_Jul

Qu'est ce qu'il aurait fallu faire ?

Utiliser e.Message dans le catch ?

En C# il y également InnerException qui précise. En tout cas on apprend dans le livre que je lis actuellement à cibler d'abord les exceptions qui sont susceptibles de se produire. Voir à créer et lancer ses propres exceptions puis à attraper des exceptions plus générales à la fin, toujours en explicitant le problème. On nettoie avec finally pour libérer les ressources ou fermer les connexions.

Message édité par Master_Jul le 26-06-2005 à 18:28:29

the real moins moins

y'avait pas un topic sur les exceptions ?

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

Master_Jul

Enfin il aurait mis :

Code :

try {
... // code qui peut générer une exception
}
catch (Exception e) {
// On ne fait rien mais on est content d'avoir intercepté l'exception
}

J'aurais compris que c'était effectivement con.

benou

-- : un lien sympa à rajouter : http://java.sun.com/jugs/pointers.html?feed=JSC

---------------
ma vie, mon oeuvre - HomePlayer

the real moins moins

chuis pas sur de voir l'interet direct pour les debutants ?

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

benou

the real moins moins a écrit :

chuis pas sur de voir l'interet direct pour les debutants ?

pas faux ...
j'ai confondu avec la FAQ Java ...

je me trompe pas, tu l'avais bien refaite, nan ?

---------------
ma vie, mon oeuvre - HomePlayer

the real moins moins

la faq java? je vois pas comment je l'aurais refaite chuis ni modo ni l'auteur [:joce]

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?

benou

the real moins moins a écrit :

la faq java? je vois pas comment je l'aurais refaite chuis ni modo ni l'auteur [:joce]

dans un autre topic ... comme ce topic ci ...

Jubijub

Parce que je le VD bien

je sais pas si c dans le focus du topic, mais dans la mesure où c une espèce de fac, on pourrait grouper les libs classiques, genre le parser Xerces, le jGoodies Looks, etc...

par ailleurs faudrait me dire ce que vous souhaitiez que j'enlève/ajoute/corrige sur le truc des exceptions

---------------
Jubi Photos : Flickr - 500px

victorus_ecl

PIBCAK

je sais pas trop si ça a sa place ici, à l'auteur du topic de voir:
http://catice.ac-bordeaux.fr/argos [...] DevV2/view

J'ai trouvé que c'était plein de bon conseils pour les débutants.

By the way

Je voulais savoir si c'était possible de conserver le ratio d'une fenetre...

Quand l'utilisateur change les dimmentions, la fenetre garde toujour le ratio (800:600).

Merci d'avance

Message édité par By the way le 11-08-2005 à 20:22:33

Jubijub

Parce que je le VD bien

je sais pas si c possible pendant le drag, mais t'a toujours moyen qd le gars lache la souris de recalculer un des coté à partir de la valeur de l'autre pour garder l'homotétie 4/3 ....

cela dit je pense qu'on est hors sujet plus ou moins là...un sujet dédié serait plus approprié...

Ces propos sont garbage-collectables

Message édité par Jubijub le 11-08-2005 à 20:32:57

---------------
Jubi Photos : Flickr - 500px

Publicité

Page : 1 2 3 4 5 .. 24 25 26 27 28 29

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

Divers

[Java] Le topic-passage-obligé pour débutants !

Sujets relatifs
[Java] Outil de gestion de "composants"; GraphEdit "like"	[Java/xml] Caractères à la con ds un .xml généré en dom
Cryptage md5 & java	Génération d'images en Java (server side)
[Java] [Resolu] Erreur ODBC État de curseur non valide	[JAVA] caractères accentué différents selon OS
[JAVA] Pb affichage caractère	créer un répertoire en java
copier-coller en java	passage de c++ a php
Plus de sujets relatifs à : [Java] Le topic-passage-obligé pour débutants !

Page générée en 0.127 secondes