/* Topic des codeurs [7] */

Rolinh · Le 04/07/2012, à 10:01

Woaw, c'est IRC ici maintenant?

J'avoue ne pas tout avoir lu en détail mais j'ai l'impression qu'il y a un malentendu à la base. L'un parle modélisation et l'autre documentation:

The Uploader a écrit :

ArkSeth a écrit :
– sont une présentation formelle de la pré-conception (on pourrait tout-à-fait envisager un programme qui te les génère depuis le diagramme de classe, ou réciproquement). Ça peut être plus lisible (beaucoup plus, parce qu'on y met plus d'infos concrètes) qu'un diagramme de classe pour comprendre la structure et les relations du programme.
Ruby :
Class.methods
rdoc..

Avoir de la doc sur le code, sa structure et les relations interclasses c'est bien, poser un modèle avant de coder, c'est mieux. Les deux n'ont juste pas le même but...

valAa a écrit :

un bon design (fut il par contrat) ne demande pas du tout d'écrire une interface par classe, ou alors java c'est encore plus pénible que ce que je pensais.

Je ne peux que plussoyer. J'ai même envie de dire que créer une interface par classe est un signe qu'il y a un sérieux problème de design!

The Uploader · Le 04/07/2012, à 10:18

Rolinh a écrit :

Avoir de la doc sur le code, sa structure et les relations interclasses c'est bien, poser un modèle avant de coder, c'est mieux. Les deux n'ont juste pas le même but...

Si j'veux modéliser avant de coder, je fais tout sauf du code..

Si j'veux avoir plus que ça, j'vais voir le code, c'tout. Je ne vois pas en quoi ne pas avoir le code d'implémentation (comme c'est le cas dans un .h) rend ça plus lisible qu'une simple classe. J'trouve même que séparer les deux peut être moins lisible.

Et puis, y'a des IDE qui peuvent générer un diagramme de classes, par exemple.

Dernière modification par The Uploader (Le 04/07/2012, à 10:27)

Elzen · Le 04/07/2012, à 10:27

Le coup du « une interface par classe », ç't'un peu exagéré (d'ailleurs je ne crois pas me rappeler avoir dit explicitement qu'il en fallait une pour chacune des classes) ; cependant un bon design (en tout cas, de la façon dont je l'ai apprit) nécessite quand même un certain nombre d'interfaces.

En particulier avec le principe d'encapsulation : tout ce qui est interne à un package donné n'a aucune raison d'être connu de l'extérieur : les classes communiquent directement entre elles à l'intérieur de leur package, mais ce qui en sort du doit être connu par une interface, et non pas par une implémentation.

Basiquement, quand je fais une petite appli rapide en MVC, je commence par faire des interfaces pour les classes de la partie modèle ; par contre je n'en fais pas pour les classes du contrôleur (ni de la vue, pour laquelle je ne développe mes propres classes que dans les rares cas où j'ai besoin de définir mes propres composants), qui n'ont pas de finalité à être appelées depuis l'extérieur.

Dernière modification par ArkSeth (Le 04/07/2012, à 10:27)

The Uploader · Le 04/07/2012, à 10:33

ArkSeth a écrit :

En particulier avec le principe d'encapsulation : tout ce qui est interne à un package donné n'a aucune raison d'être connu de l'extérieur : les classes communiquent directement entre elles à l'intérieur de leur package, mais ce qui en sort du doit être connu par une interface, et non pas par une implémentation.

L'interface peut être dans l'implémentation ou autrement dit, "les contrats peuvent se trouver dans les classes".

Et ce n'est pas sale par principe.

Ne pas avoir d'interfaces au sens Java n'empêche pas l'encapsulation. Tout ce dont tu as besoin pour ça, c'est d'avoir/émuler la notion public/private (et protected aussi, c'est pas mal non plus..)

Rolinh a écrit :

Woaw, c'est IRC ici maintenant?

Dernière modification par The Uploader (Le 04/07/2012, à 10:45)

Elzen · Le 04/07/2012, à 10:45

Je crois que ç'n'est pas la peine de continuer à troller : nous avons manifestement deux conceptions radicalement différentes de ce qu'est la propreté dans ce contexte précis.

À moins que, comme ta dernière phrase le laisserait sous-entendre, tu ne t'entêtes encore à calquer ta manière de concevoir la programmation en Ruby au Java sans prendre en compte les différences plus ou moins importantes de de logique (et donc de propreté) qui existent entre ces deux langages ?

The Uploader · Le 04/07/2012, à 10:46

ArkSeth a écrit :

À moins que, comme ta dernière phrase le laisserait sous-entendre, tu ne t'entêtes encore à calquer ta manière de concevoir la programmation en Ruby au Java sans prendre en compte les différences plus ou moins importantes de de logique (et donc de propreté) qui existent entre ces deux langages ?

Je te retourne la question :

The Uploader a écrit :

L'interface peut être dans l'implémentation ou autrement dit, "les contrats peuvent se trouver dans les classes".

Même en Java, tu ne perds pas l'encapsulation si tu ne fais pas d'interface Java, ça n'a juste rien à voir.

L'ensemble des méthodes publiques d'une classe (ou un ensemble de fonctions en C), c'est déjà une interface.

Ce que permet les Interfaces dans le monde Java, c'est de standardiser les interfaces (pense à une prise éléctrique).

Un langage dynamique le fait avec le duck typing.

Dernière modification par The Uploader (Le 04/07/2012, à 10:50)

Elzen · Le 04/07/2012, à 10:50

The Uploader a écrit :

L'interface peut être dans l'implémentation ou autrement dit, "les contrats peuvent se trouver dans les classes"

Ç'n'est juste pas la façon dont Java est pensé, c'est tout.
Par ailleurs, j'ai bien dit que c'était l'interface qui devait sortir du package et non l'implémentation, donc le fait qu'on puisse sortir les deux en même temps, ça n'y répond pas.

(C'est quand même terrible, ces gens qui reconnaissent eux-mêmes ne pas être spécialiste dans un domaine, mais voudraient quand même donner des leçons dessus… si demain je fais du code Ruby et que tu viens me dire que j'n'ai pas fait les choses correctement, bah j'écouterai, et je tenterai de revoir ma copie, parce que manifestement, tu connais le Ruby mieux que moi. Par contre, quand tu appliques la même logique au Java, au C ou à n'importe quel langage basé sur des concepts différents de celui du Ruby, il faut quand même que tu te rendes compte que ta critique est beaucoup moins recevable.)

Dernière modification par ArkSeth (Le 04/07/2012, à 10:52)

The Uploader · Le 04/07/2012, à 10:57

ArkSeth a écrit :

Ç'n'est juste pas la façon dont Java est pensé, c'est tout.
Par ailleurs, j'ai bien dit que c'était l'interface qui devait sortir du package et non l'implémentation, donc le fait qu'on puisse sortir les deux en même temps, ça n'y répond pas.

J'abandonne. Une implémentation, c'est déjà une interface, c'tout. Même en Java (ou en C#, d'ailleurs).

ArkSeth a écrit :

(C'est quand même terrible, ces gens qui reconnaissent eux-mêmes ne pas être spécialiste dans un domaine, mais voudraient quand même donner des leçons dessus… si demain je fais du code Ruby et que tu viens me dire que j'n'ai pas fait les choses correctement, bah j'écouterai, et je tenterai de revoir ma copie, parce que manifestement, tu connais le Ruby mieux que moi. Par contre, quand tu appliques la même logique au Java, au C ou à n'importe quel langage basé sur des concepts différents de celui du Ruby, il faut quand même que tu te rendes compte que ta critique est beaucoup moins recevable.)

Rien à voir. Si tu lis bien j'aborde des principes généraux. Ceux de l'OO (ou pas, d'ailleurs), ceux qu'on m'a appris bien avant Ruby.

Java et Ruby sont tous les deux basés sur les concepts OO, tu sais.

Et puis j'ai beau ne pas être un spécialiste Java, j'en ai fait, et je connais un minimum le langage, et les concepts sur lesquels il se repose.

Dernière modification par The Uploader (Le 04/07/2012, à 11:16)

Rolinh · Le 04/07/2012, à 11:05

The Uploader a écrit :

Si j'veux modéliser avant de coder, je fais tout sauf du code..

Bah évidemment. Sinon on ne parle plus de modélisation...

The Uploader a écrit :

Si j'veux avoir plus que ça, j'vais voir le code, c'tout. Je ne vois pas en quoi ne pas avoir le code d'implémentation (comme c'est le cas dans un .h) rend ça plus lisible qu'une simple classe. J'trouve même que séparer les deux peut être moins lisible.

Question de point de vue. Note que je n'ai jamais donné mon avis sur les .h, etc hein. Pour moi, la façon de faire du Ruby me convient très bien de même que les .h ne me dérangent pas.

The Uploader a écrit :

Et puis, y'a des IDE qui peuvent générer un diagramme de classes, par exemple.

Franchement, je trouve l'intérêt plus que limité voir franchement inutile. Il me semble qu'il a déjà été fait mention ici du fait qu'il faut baser le code sur le concept et non modifier le concept d'après le code! Générer un squelette de code à partir d'un diagramme UML est bien plus utile bien que comme l'ait soulevé gim7reaper, ce n'est pas vraiment au point et donc, de mon point de vue, plutôt inutile pour le moment.

Dr Le Rouge · Le 04/07/2012, à 11:09

Mais faites les taire -_____-

The Uploader · Le 04/07/2012, à 11:10

Rolinh a écrit :

Question de point de vue. Note que je n'ai jamais donné mon avis sur les .h, etc hein. Pour moi, la façon de faire du Ruby me convient très bien de même que les .h ne me dérangent pas.

Bah dans le contexte du C, c'est très utile. Après, si on peut l'automatiser c'est bien que quelqu'un s'est dit "j'en ai plein le derrière de les maintenir, je vais automatiser tout ça è_é ", non ?
Donc ça peut être une plaie.

Rolinh a écrit :

Franchement, je trouve l'intérêt plus que limité voir franchement inutile. Il me semble qu'il a déjà été fait mention ici du fait qu'il faut baser le code sur le concept et non modifier le concept d'après le code! Générer un squelette de code à partir d'un diagramme UML est bien plus utile bien que comme l'ait soulevé gim7reaper, ce n'est pas vraiment au point et donc, de mon point de vue, plutôt inutile pour le moment.

Bah ça permet de bien voir comment s'agencent les classes dans la pratique (quand tu découvres un projet, c'est pas mal). Mais oui, c'est marginalement utile.

Elzen · Le 04/07/2012, à 11:18

The Uploader a écrit :

Rien à voir. Si tu lis bien j'aborde des principes généraux. Ceux de l'OO (ou pas, d'ailleurs), ceux qu'on m'a appris bien avant Ruby.
Java et Ruby sont tous les deux basés sur les concepts OO, tu sais.
Et puis j'ai beau ne pas être un spécialiste Java, j'en ai fait, et je connais un minimum le langage, et les concepts sur lesquels il se repose.

Toutes proportions gardées, j'ai l'impression de lire quelqu'un qui se plaint qu'il n'y a pas d'objets en Lisp…

Les concepts de programmation objet sont des concepts assez génériques, qui ont été mis en place de plusieurs manières radicalement différentes ; notamment sur la notion de typage fixe ou dynamique.

La notion de duck typing, par exemple, je ne comprends toujours pas ce qu'elle est venue faire dans une discussion sur Java, puisqu'elle n'a juste pas de sens, en Java (bon, ou alors, je l'ai mal comprise, mais de ce qu'il me semble, il s'agit de désigner un objet après-coup en fonction des possibilités qu'il offre, ce qui ne peut avoir de sens que dans un contexte de typage dynamique).

Une implémentation peut proposer une interface quand il n'y a vraiment rien de mieux à disposition, oui ; ç'n'est juste pas comme ça qu'on est censé utiliser une interface en Java (dans d'autres langage, je n'dis pas, ça peut être super adapté et tout, mais là, on parle de Java, donc on essaye de penser selon la logique Java, sinon ça n'a aucun sens).

Figure-toi que dans certains cas, il est même vivement conseillé de créer plusieurs interfaces différentes pour la même classe, afin de restreindre le nombre de méthodes visibles, pour adapter au client qui va devoir l'utiliser ; c'est une approche fondamentalement différente de celle du typage dynamique (il faudrait vraiment que je remette la main sur mes cours, ne serait-ce que pour retrouver les noms et les références…)

Rolinh · Le 04/07/2012, à 11:22

The Uploader a écrit :

Bah ça permet de bien voir comment s'agencent les classes dans la pratique (quand tu découvres un projet, c'est pas mal). Mais oui, c'est marginalement utile.

Ce que te donnes le diagramme UML (ou autre moyen de modélisation) que tu as fait au préalable et que tu as utilisés comme modèle pour ton code? Donc c'est bien ce que je disais, c'est inutile.

The Uploader · Le 04/07/2012, à 11:23

ArkSeth a écrit :

Une implémentation peut proposer une interface quand il n'y a vraiment rien de mieux à disposition, oui ; ç'n'est juste pas comme ça qu'on est censé utiliser une interface en Java (dans d'autres langage, je n'dis pas, ça peut être super adapté et tout, mais là, on parle de Java, donc on essaye de penser selon la logique Java, sinon ça n'a aucun sens).
Figure-toi que dans certains cas, il est même vivement conseillé de créer plusieurs interfaces différentes pour la même classe, afin de restreindre le nombre de méthodes visibles, pour adapter au client qui va devoir l'utiliser ; c'est une approche fondamentalement différente de celle du typage dynamique (il faudrait vraiment que je remette la main sur mes cours, ne serait-ce que pour retrouver les noms et les références…)

ArkSeth a écrit :

Une implémentation peut proposer une interface quand il n'y a vraiment rien de mieux à disposition, oui 

Ah c'ayez, 3 pages pour y arriver. Dur.

Rolinh a écrit :

Ce que te donnes le diagramme UML (ou autre moyen de modélisation) que tu as fait au préalable et que tu as utilisés comme modèle pour ton code? Donc c'est bien ce que je disais, c'est inutile.

Théorie != pratique.

Mon diagramme de base était toujours valide, mais l'implémentation peut dériver marginalement selon le langage.

Dernière modification par The Uploader (Le 04/07/2012, à 11:26)

Elzen · Le 04/07/2012, à 11:25

ArkSeth a écrit :

 ; ç'n'est juste pas comme ça qu'on est censé utiliser une interface en Java (dans d'autres langage, je n'dis pas, ça peut être super adapté et tout, mais là, on parle de Java, donc on essaye de penser selon la logique Java, sinon ça n'a aucun sens).

S'tu veux que je tronque des quotes pour donner l'impression que tu « admets des trucs au bout de trois pages » alors que tu ne les as jamais niés mais que tu fais juste remarquer que c'est crade et hors sujet, ça peut se faire aussi, hein.

The Uploader · Le 04/07/2012, à 11:27

C'est crade en Java

Elzen · Le 04/07/2012, à 11:28

Ouais, voilà. C'est exactement ce que je disais, si tu relis en arrêtant de caricaturer mes propos.

The Uploader · Le 04/07/2012, à 11:30

J'caricature pas. J'réponds honnêtement, c'tout.

Pas de ma faute si tu n'es pas clair.

Elzen · Le 04/07/2012, à 11:33

ArkSeth a écrit :

Les .h n'apportent effectivement pas grand chose par rapport au ruby, mais c'est le simple fait de se ramener au ruby pour envisager les .h qui n'a pas de sens, puisque les deux sont basés sur des concepts différents.
Les fichiers d'en-tête sont fichtrement utiles quand ils sont envisagés d'une certaine manière, et chiants quand ils sont envisagés autrement ; tout comme les pointeurs, l'héritage multiple, les exceptions, les annotations, ou tout autre élément spécifique à une manière donnée de programmer.
Ç't'en partie pour ça qu'il y a autant de langages différents, d'ailleurs.

ArkSeth a écrit :

si demain je fais du code Ruby et que tu viens me dire que j'n'ai pas fait les choses correctement, bah j'écouterai, et je tenterai de revoir ma copie, parce que manifestement, tu connais le Ruby mieux que moi. Par contre, quand tu appliques la même logique au Java, au C ou à n'importe quel langage basé sur des concepts différents de celui du Ruby, il faut quand même que tu te rendes compte que ta critique est beaucoup moins recevable.

ArkSeth a écrit :

(dans d'autres langage, je n'dis pas, ça peut être super adapté et tout, mais là, on parle de Java, donc on essaye de penser selon la logique Java, sinon ça n'a aucun sens).

Y a quoi de pas clair ?

The Uploader · Le 04/07/2012, à 11:34

J'sais pas (faudrait revenir sur tous les posts pour pointer, je pense pas que ça serve à grand chose. Puis faut que je bosse), mais si on a fait 4 pages alors qu'on dit la même chose, y'a un problème quelque part.

Dernière modification par The Uploader (Le 04/07/2012, à 11:37)

Elzen · Le 04/07/2012, à 11:37

Bah sauf erreur de ma part (j'peux me planter, hein, si c'est le cas, mes plates excuses), j'n'ai pas arrêté, tout au long de la discussion, à faire des cloisonnements entre les différents langages en disant qu'un concept donné a du sens si on le prend dans la logique de ce langage-là, mais n'en a pas dès qu'on change de logique ; et c'est toi qui n'arrêtais pas de ramener tous les points que j'avançais au seul point de vue Ruby, mais bon…

The Uploader · Le 04/07/2012, à 11:38

Bah de mon côté j'croyais que tu ramenais tout à Java pour dire "c'est comme ça que c'est propre!"

Bon, au moins le topic revit.

Désolé.

(note : j'ai quand même beaucoup plus de respect pour Java que pour PHP )
(note 2 : sauf les JSP. C't'horrible, les JSP)

Dernière modification par The Uploader (Le 04/07/2012, à 11:40)

Rolinh · Le 04/07/2012, à 11:57

The Uploader a écrit :

(note : j'ai quand même beaucoup plus de respect pour Java que pour PHP )
(note 2 : sauf les JSP. C't'horrible, les JSP)

Il ne te suffit pas ton dernier troll?

The Uploader · Le 04/07/2012, à 12:03

Ce n'est pas un troll, mais une citation tronquée d'un message d'apaisement.

Sinon, j'aimerais savoir pourquoi j'me tape une accusation pareille dans la tronche ?

Rolinh · Le 04/07/2012, à 12:06

Bah ça y ressemblait pourtant
De quelle accusation tu parles?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1201 Le 04/07/2012, à 10:01

Re : /* Topic des codeurs [7] */

#1202 Le 04/07/2012, à 10:18

Re : /* Topic des codeurs [7] */

#1203 Le 04/07/2012, à 10:27

Re : /* Topic des codeurs [7] */

#1204 Le 04/07/2012, à 10:33

Re : /* Topic des codeurs [7] */

#1205 Le 04/07/2012, à 10:45

Re : /* Topic des codeurs [7] */

#1206 Le 04/07/2012, à 10:46

Re : /* Topic des codeurs [7] */

#1207 Le 04/07/2012, à 10:50

Re : /* Topic des codeurs [7] */

#1208 Le 04/07/2012, à 10:57

Re : /* Topic des codeurs [7] */

#1209 Le 04/07/2012, à 11:05

Re : /* Topic des codeurs [7] */

#1210 Le 04/07/2012, à 11:09

Re : /* Topic des codeurs [7] */

#1211 Le 04/07/2012, à 11:10

Re : /* Topic des codeurs [7] */

#1212 Le 04/07/2012, à 11:18

Re : /* Topic des codeurs [7] */

#1213 Le 04/07/2012, à 11:22

Re : /* Topic des codeurs [7] */

#1214 Le 04/07/2012, à 11:23

Re : /* Topic des codeurs [7] */

#1215 Le 04/07/2012, à 11:25

Re : /* Topic des codeurs [7] */

#1216 Le 04/07/2012, à 11:27

Re : /* Topic des codeurs [7] */

#1217 Le 04/07/2012, à 11:28

Re : /* Topic des codeurs [7] */

#1218 Le 04/07/2012, à 11:30

Re : /* Topic des codeurs [7] */

#1219 Le 04/07/2012, à 11:33

Re : /* Topic des codeurs [7] */

#1220 Le 04/07/2012, à 11:34

Re : /* Topic des codeurs [7] */

#1221 Le 04/07/2012, à 11:37

Re : /* Topic des codeurs [7] */

#1222 Le 04/07/2012, à 11:38

Re : /* Topic des codeurs [7] */

#1223 Le 04/07/2012, à 11:57

Re : /* Topic des codeurs [7] */

#1224 Le 04/07/2012, à 12:03

Re : /* Topic des codeurs [7] */

#1225 Le 04/07/2012, à 12:06

Re : /* Topic des codeurs [7] */

Pied de page des forums