Discussion :

[spidermario]

Ce qui me gène surtout c'est que ça détourne une utilisation existante d'un opérateur pour faire autre chose. En toute logique, un opérateur se devrait de retourner un résultat sans interagir avec autre chose que ces opérandes et rester sans effet de bord (sauf pour les opérateurs d'affectation)

En quoi ça devrait être différent pour les opérateurs d'affectation ?
Entre += et <<, y a-t-il une bonne raison pour que seul += ait le droit d'effectuer une action ?
Je ne pense pas.

Ce que je trouve gênant c'est que les outils pour mettre en œuvre ces bonnes pratiques(comme les pointeurs intelligents) ne fassent pas partie du langage ni même de la bibliothèque standard. monde est d'accord.

Les pointeurs intelligents font partie de la bibliothèque standard (classe auto_ptr, il faut inclure memory).

[hegros]

Cet objet étant déclaré comme static final, il ne peux pas être modifié, même pas par héritage, donc il me semble au contraire très bien encapsulé.

L'encapsulation s'intéresse à la visibilité de l'attribut, pas qu'il soit static final ou en readonly. L'encapsulation dans l'absolu c'est tout les attributs avec une visibilité private et java pour un langage objet absolu ne respecte pas ce principe contrairement au c++ qui ne l'est pas en tout cas pour l'exemple d'écriture sur la sortie standard.


Ce que tu disais c'est plus l'argument du code sale parce que oui on peut écrire un code illisible et sale en surchargeant tout et n'importe quoi n'importe comment mais cela n'est pas lié à la technique particulière de la surcharge des opérateurs plus au programmeur.

Il y a autant de mauvaise façon d'utiliser la surcharge des opérateurs que d'écrire du code objet.

[spidermario]

L'encapsulation s'intéresse à la visibilité de l'attribut, pas qu'il soit static final ou en readonly. L'encapsulation dans l'absolu c'est tout les attributs avec une visibilité private et java pour un langage objet absolu ne respecte pas ce principe contrairement au c++ qui ne l'est pas en tout cas pour l'exemple d'écriture sur la sortie standard.


Ce que tu disais c'est plus l'argument du code sale parce que oui on peut écrire un code illisible et sale en surchargeant tout et n'importe quoi n'importe comment mais cela n'est pas lié à la technique particulière de la surcharge des opérateurs plus au programmeur.

Il y a autant de mauvaise façon d'utiliser la surcharge des opérateurs que d'écrire du code objet.

Est-ce que System est vraiment un objet ? En Java, la résolution d'espace de nom se fait par '.', comme l'accès aux membres d'une classe, donc peut-être que System est un espace de nom dont out est un objet (et non un membre au sens des classes, donc), et que l'encapsulation n'est pas violée, par conséquent.
Je vérifierai ça.

Edit : il semblerait que j'aie raison

Code Java :

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

1
2
3
4
5
6
7
8
/* test.java*/
class test
{
    public static void main(String arguments[])
    {
        System.out.println(System);
    }
}

Code Console :

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

1
2
3
4
5
6
7
8
$ javac test.java
test.java:5: cannot find symbol
symbol  : variable System
location: class test
        System.out.println(System);
                           ^
1 error
$

Exemple bidon, bien entendu, mais il fallait que j'utilise System quelque part.
Que constate-t-on ? Le compilateur ne trouve pas de variable appelée "System", donc System n'en est effectivement pas une et est, par conséquent un espace de nom. Donc, accéder à System.out ne viole pas l'encapsulation.

[Uther]

Non, System est bien une classe du package java.lang qui est le package de base (automatiquement importé par défaut). Un package est a peu près l'équivalent Java d'un espace de nom en C++)

Ton programme de test n'est pas exact. Le paramètre d'une fonction doit être une variable, or tu utilises un nom de classe. Quelle que soit la classe que tu met comme paramètre, tu aura une erreur. Si tu veux une variable représentant la classe il faudrait que tu face :

Code :

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

System.out.println(System.class);

Le plus simple étant tout de meme de vérifier la doc: http://java.sun.com/javase/6/docs/ap...ng/System.html

L'encapsulation s'intéresse à la visibilité de l'attribut, pas qu'il soit static final ou en readonly. L'encapsulation dans l'absolu c'est tout les attributs avec une visibilité private et java pour un langage objet absolu ne respecte pas ce principe contrairement au c++ qui ne l'est pas en tout cas pour l'exemple d'écriture sur la sortie standard.

Que ce soit l'objet qui soit visible ou son accesseur, si dans la pratique ça ne change rien, je ne vois pas trop le problème.

Les pointeurs intelligents font partie de la bibliothèque standard (classe auto_ptr, il faut inclure memory).

Je suis pas un expert C++, mais à ce que j'en ai lu, l'implémentation actuellement utilisée dans la bibliothèques standard est plutôt limitée car elle ne fait pas de comptage de référence.
http://cpp.developpez.com/faq/cpp/?p...NTEURS_autoptr

[Alp]

Vive TR1, qui contient les pointeurs intelligents ... "plus utiles".
TR1 est une sous-partie de la bibliothèque standard.

std::tr1::shared_ptr par exemple.

Et ce ne sont pas que des mauvais profs. Je connais beaucoup d'étudiants qui font des études pour passer le temps, pas par amour/passion de ce qu'ils font. Ce n'est pas facile de leur apprendre des choses à cela. C'est le genre de gars qui vient me demander de lui coder le truc à sa place. Ce à quoi je réponds en général "Et quand ton patron dans 5 ans te demandera de coder un truc, tu feras quoi ? T'aimerais pas mériter ton salaire ? Donc si tu veux je t'explique les différentes choses qu'il faut utiliser, mais certainement pas le faire à ta place".

Et pour l'histoire des opérateurs, tout simplement, c'est une question de goût. Faut pas non plus essayer d'imposer son avis comme le seul valable sur une question qui est subjective.

[hegros]

Et ce ne sont pas que des mauvais profs. Je connais beaucoup d'étudiants qui font des études pour passer le temps, pas par amour/passion de ce qu'ils font. Ce n'est pas facile de leur apprendre des choses à cela. C'est le genre de gars qui vient me demander de lui coder le truc à sa place. Ce à quoi je réponds en général "Et quand ton patron dans 5 ans te demandera de coder un truc, tu feras quoi ? T'aimerais pas mériter ton salaire ? Donc si tu veux je t'explique les différentes choses qu'il faut utiliser, mais certainement pas le faire à ta place".

S'ils ne savent pas enseigner à ceux qui n'ont pas 'l'amour et la passion' et à ceux qui ne montrent pas une débrouillardise pour le codage, autant dire être élitiste, dans ce cas ce ne sont pas des professeurs mais des nounous qui attendent la fin du mois pour toucher leur chèque c'est tout.

Bref, par rapport au C++ ou JAVA c'est enseigné plus ou moins bien, c'est plus une difficulté d'enseignement que de surcharge d'opérateur ou de programmation objet ou de technique. Dire qu'un débutant ne comprendras rien au concept c'est une connerie c'est reconnaître son incapacité à l'enseigner.

[Alp]

S'ils ne savent pas enseigner à ceux qui n'ont pas 'l'amour et la passion' et à ceux qui ne montrent pas une débrouillardise pour le codage, autant dire être élitiste, dans ce cas ce ne sont pas des professeurs mais des nounous qui attendent la fin du mois pour toucher leur chèque c'est tout.

Ah oui, c'est SYSTÉMATIQUEMENT la faute du prof, évidemment !
Y'en a qui, faudrait mieux les éduquer, leur apprendre le respect, leur faire prendre conscience de l'importance des études, etc.
Vas voir dans les école d'ingé, les IUT, les université, aujourd'hui, et on en reparlera.

[millie]

Je ne comprend pas trop où vous voulez en venir.

On dirait que vous supposez que l'apprentissage d'un langage passe systématiquement par un professeur ? Est-ce vraiment le cas ?

A l'école, on voit rarement plus de 3 langages (en général du C, un langage fonctionnel que la plupart des élèves oublis et un langage orienté objet type smalltalk, java, C#). (je parle pas des langages vu vite fait comme de l'assembleur).
Les gens apprennent surtout sur le tas et dans des bouquins (je n'utilise aucun langage appris à l'école professionnellement)


Sinon, le dicton me semble complètement débile. J'ai connu de très bon prof, tous les élèves ne devenaient pas magiquement doués (et oui, il y a des élèves qui ont du mal naturellement et d'autres qui en ont rien à foutre et d'autres qui ne bossent pas)... La seule chose de sûr, c'est qu'un mauvais prof n'aide pas

[hegros]

Ah oui, c'est SYSTÉMATIQUEMENT la faute du prof, évidemment !

Y'en a qui, faudrait mieux les éduquer, leur apprendre le respect, leur faire prendre conscience de l'importance des études, etc.
Vas voir dans les école d'ingé, les IUT, les université, aujourd'hui, et on en reparlera.

D'accord la responsabilité est bien de 100% pour l'étudiant et 100% pour le professeur. C'est SYSTEMATIQUEMENT la faute des 2

EDIT : milie est plus dur les professeurs ne sont bons qu'à une introduction à un langage et dresser une liste des livres à se procurer. C'est oublier un peu les prof de TP.

[millie]

EDIT : milie est plus dur les professeurs ne sont bons qu'à une introduction à un langage et dresser une liste des livres à se procurer. C'est oublier un peu les prof de TP.

Je ne sais pas où tu as lu ça
Alors, j'ai simplement dit que la plupart des langages utilisés professionnellement ne sont pas appris par un professeur en cours mais sont souvent appris sur le tas, directement au boulot (pas à cause des profs, mais simplement parce que le langage n'a pas pu être étudié à l'école ou que la personne n'a pas étudié l'informatique à l'école (reconversion, il y en a plein)). C'est une constatation. Je n'ai absolument pas jugé de la pertinence des cours en école.

De plus, la plupart du temps, par exemple dans un cours de "Langage fonctionnel", le rôle du professeur n'est pas d'enseigner le lisp ou le caml , mais d'enseigner les concepts des langages fonctionnels. De même, dans un cours de POO, le rôle du prof est d'enseigner les principes de la programmation objet, pas d'enseigner le java.
C'est rare en école d'avoir un cours sur un langage pour avoir un cours sur un langage (sauf éventuellement le premier langage étudié). Le langage sert surtout à illustrer des concepts bien plus généraux.
Et je trouve que c'est tant mieux !

Dans les peu de langages qui servent à illustrer les cours, c'est finalement pas fréquent d'avoir à bosser sur ces langages dans le monde professionel.
Quel est le pourcentage de gens qui ont eu vrai cours sur un langage (dans le cas où ils ont pu étudier l'informatique à l'école) et l'utilise professionnellement ? (en tout cas, je n'en fais pas partie) Du genre smalltalk ou lisp ou même C...

[Tommy31]

Pour afficher une chaîne sur la sortie standard soit une console windows ou unix.

En C++

Code :

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

cout << "ma chaine sur la sortie standard";

On a surchargé l"opérateur << de la classe de l'objet cout moyennant une fonction amie.


En Java

Code :

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

System.out.println("ma chaine sur la sortie standard");

C'est la méthode println de l'objet out qui doit être appelée qui est un attribut de System accessible de l'extérieur en cela on a brisé un principe élémentaire de la POO à savoir l'encapsulation(out est une donnée membre public).

Nope, c'est justement l'inverse. En C++ la fonction amie contrevient à l'encapsulation de l'instance (certes, de son fait), pas en java pour lequel la méthode println est déclarée classiquement.

Ne te focalise pas sur le System qui est une classe, et non une instance. Elle définit, au même titre que std en C++ un espace de nommage, dont l'attribut public 'out' est constant (final). D'ailleurs en java 1.5 il est possible d'écrire cela :

Code :

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

1
2
3
4
5
6
7
8
import static java.lang.System.out;

public class Toto {
public static void main(String[] args) {
    out.println("Hello world");
}
}

[Luc Hermitte]

Ce qui est anormal c'est que justement a l'origine il ne s'agit pas d'opérateurs de flot mais d'opérateurs de décalage de bit, dont l'usage est détourné pour les faire ressembler à des opérateurs de flots Unix alors que leur fonctionnement n'a rien a voir.

A l'origine j'ai appris à définir mes blocs avec Begin et End, et non pas avec { et }.
Pourquoi supposer que le débutant C++ doive nécessairement apprendre à manipuler des champs de bits avant d'écrire sur la console?
Mais oubliez donc cette fichue approche historique.

En cela, je rejoins ce que dit Garulfo : le débutant (qu'il soit en classe de Cours Préparatoire (vers l'âge de 6ans) où il apprend à compter, ou qu'il soit bien plus grand à débuter la programmation), il découvre toujours des nouveaux sigles qui au départ ne veulent pas dire grand chose pour lui.
Et puis un jour il apprend qu'un même sigle peut être utilisé pour exprimer plusieurs choses -- sommes-nous incapables de faire la différence entre un "bureau" et un "bureau" ?

Nope, c'est justement l'inverse. En C++ la fonction amie contrevient à l'encapsulation de l'instance (certes, de son fait), pas en java pour lequel la méthode println est déclarée classiquement.

Non, non. C'est le contraire. L'amitié renforce l'encapsulation. Plutôt que de pousser les développeurs à commettre le sacrilège de violer Déméter et sa loi (en exposant des détails internes au travers de mutateurs et accesseurs), elle permet de lister un nombre fini de fonctions externes à la classe qui auront les mêmes privilèges d'accès que les fonctions qui appartiennent à la classe. C'est juste que syntaxiquement elles sont à l'extérieur. L'encapsulation s'en trouve renforcée. En fait, on considère l'interface étendue des classes qui va comprendre celle "héritées" des langages bridés OO, et les fonctions qui s'appliquent sur les instances de ces classes.
Maintenant, je ne considère pas que System.out soit une faille d'encapsulation. Pour moi, il s'agit d'une faille de conception que le langage partage avec d'autres langages bridés OO comme Eiffel, mais pas une faille d'encapsulation -- le modèle avec des classes remplies de membres statiques n'est pas extensible (essayez d'ajouter une fonction sigmoïde au paquetage de fonctions mathématiques).

[Garulfo]

[...]
Etant débutant je ne me souviens pas avoir trouvé cet opérateur illisible il faut dire que j'avais un bon professeur pour me l'enseigner [...]

Donc il a du te l'enseigner ! QED. Merci d'illustrer ce que je disais

[hegros]

Donc il a du te l'enseigner ! QED. Merci d'illustrer ce que je disais

Oui il y a des professeurs qui savent enseigner heureusement, pas de quoi s'éffriter ou crier eureka

[Furikawari]

Oui il y a des professeurs qui savent enseigner heureusement, pas de quoi s'éffriter ou crier eureka

... Ce qu'il voulait dire (je pense m'avancer sans trops de risques là) c'est que pour assimiler l'opérateur il a fallu que quelqu'un te l'enseigne, sinon c'est plutôt obscur.

[CedricMocquillon]

Sur la question de l'opérateur de flux, il n'y a absolument rien qui l'oblige à être amis de la classe en C++. Si le besoin est d'afficher des informations concernant l'objet alors on doit le faire par l'intermédiaire des méthodes de classe (accesseurs) (les détails d'implémentation n'ont pas à être connus, rien ne justifie donc l'amitié). Si l'idée est de sérialiser l'objet alors on utilise des bibliothèques faites pour (cette fois ci, les détails d'implémentation sont nécessaires pour sérialiser et justifie donc l'amitié Edit: ce qui renforce alors l'encapsulation comme l'a souligné Luc Hermitte).

[hegros]

... Ce qu'il voulait dire (je pense m'avancer sans trops de risques là) c'est que pour assimiler l'opérateur il a fallu que quelqu'un te l'enseigne, sinon c'est plutôt obscur.

Beh oui avant j'étais maçon que se soit un opérateur ou une déclaration de variable c'était tout autant obscur puis les livres qui se vendaient n'étaient pas accessibles au débutant contrairement à aujourd'hui. Ce n'est pas lié UNIQUEMENT à l'opérateur...

[koala01]

@Alp et @hergos

Je serais vous, je ne focaliserais pas uniquement sur les profs et les élèves...

Bien sur, le duo gagnant est celui du bon prof (qui sait de quoi il parle et qui sait l'expliquer) et du bon élève (qui en veut, qui sait apprendre et qui comprend vite)...

Force est d'avouer qu'il est rare de trouver un tel cocktail

Mais ce dont il faut être conscient, c'est du temps *réel* d'apprentissage avant de pouvoir estimer que l'on maitrise effectivement un langage, quel qu'il soit...

On peut apprendre les bases de n'importe quel langage en une trentaine d'heure, et on peut se sentir " tout à fait à l'aise " après une soixantaine, si ce temps a été utilisé pour présenter "les bonnes pratiques"...

Mais cela prend facilement plusieurs années avant d'en avoir fait un tour "suffisamment large" pour pouvoir estimer que l'on en a une vue cohérente et complète pour le maitriser.

Alors, ne nous méprenons pas: à moins de partir sur l'idée d'études dans lesquelles nous serions partis pour 10 ans, où l'on matraquerait les différents langages à longueur de journée au dépends d'autres matières (comme l'algorithmique ou les méthodes de conception), il est impossible de pouvoir estimer que les seuls cours puissent suffire à quelqu'un d'estimer maîtriser un langage...

Comptez qu'un étudiant en cours du jour, qui a trois fois deux heures (de 50 minutes) par semaine cours sur un langage particulier tout au long de l'année ne va au final, entre les vacances, les jours fériés et... les grèves (car c'est vraiment d'actualité, pour l'instant) avoir au mieux 120 à 150 heures de cours sur ce langage au long de l'année.

Comptez que, pour pouvoir avancer dans ce langage particulier, il lui manquera encore les notions d'algorithmique ou de conception qui, si elles sont vues durant le cours sur le langage, se font au dépends de l'apprentissage de notions propres au langage.

Comptez enfin sur le fait que tout le monde n'a pas forcément l'esprit suffisamment logique pour être en mesure de créer des algorithmes qui tiennent la route...

Tout cela mis ensemble, il faut être honnête: ce n'est pas au sortir de l'école que l'on peut s'attendre, espérer ni prétendre réellement maitriser le langage

[gorgonite]

Tout cela mis ensemble, il faut être honnête: ce n'est pas au sortir de l'école que l'on peut s'attendre, espérer ni prétendre réellement maitriser le langage

tu oublies dans ton équation un ENORME point : quid du travail personnel, et de la rigueur de ce travail...
parce qu'une fois qu'on a acquis certaines connaissances, le langage peut être vu comme un "détail" syntaxique

[Jedai]

On peut apprendre les bases de n'importe quel langage en une trentaine d'heure, et on peut se sentir " tout à fait à l'aise " après une soixantaine, si ce temps a été utilisé pour présenter "les bonnes pratiques"...

Mais cela prend facilement plusieurs années avant d'en avoir fait un tour "suffisamment large" pour pouvoir estimer que l'on en a une vue cohérente et complète pour le maitriser.

Ca dépend pas mal du langage et des connaissances préalables tout de même... Je suis relativement sûr que je serais capable de maitriser bien plus que les bases de C# en une trentaine d'heure, alors qu'un programmeur moyen issu d'une Java school essayant d'apprendre Haskell mettra bien plus qu'une trentaine d'heure avant d'acquérir un sens basique du langage.

(NB : je ne suis pas un surhomme, j'ai juste une connaissance de C, Java et un éventail relativement large de langages exotiques (dont certains dont C# s'est inspiré pour ses fonctionnalités "originales", Haskell entre autres), une fondation en algorithmique et structures de données, ainsi que des bonnes bases théoriques et pratiques en théorie des langages)

--
Jedaï