Aller au contenu

Introduction décente à l'orienté objet ?


Yozz

Messages recommandés

Pour moi Apple et Merdosoft c'est pour les attardés mentaux. Entre être autiste et être abruti, je préfère encore être autiste.

Ce sont les mecs comme toi qui bousillent la réputation de linux. :angry:

Lien vers le commentaire

Pour moi Apple et Merdosoft c'est pour les attardés mentaux. Entre être autiste et être abruti, je préfère encore être autiste.

:lol:

être un abruti heureux ça me va.

Windows c'est bien, ça fait ce que je veux et ça me rend heureux.

Lien vers le commentaire

Yep, comme on a formé une génération a croire que la modélisation objet n'était pas UN outil, mais l'OUTIL et qui se tripotent a s'échanger de l'UML dans leur asile pendant que d'autres travaillent :P

+1

On peut aussi arrêter d'être autiste et utiliser ce qui marche en fonction de ses besoins.

+2

L'objet c'est bien parce que ça rend le code modulaire. C'est le seul avantage. Et c'est pas la peine de faire du "vrai" objet, comme disent les puristes ; un langage imparfait comme C++ ou python suffit amplement. Après, certains problèmes se règlent bien mieux avec du fonctionnel, et il n'est pas interdit de combiner les deux. Moi, quand je code, je fais la partie modélisation des données en objet et la partie traitements algorithmiques en fonctionnel.

Lien vers le commentaire

Ça ou autre chose. Je regarde quand même de très près les perfs du code compilé, je suis old school. En celà SBCL est pas mal du tout, mais bonjour le bordel pour interfacer Ça avec autre chose.

Justement Scala permet d'appeler du code Java.

Lien vers le commentaire

Scala permet d'appler du code dans la JVM, il n'y a pas de java ou de scala au runtime, la convention d'appel n'est pas liée au langage :P (et le sera encore moins avec invokeDynamic).

Lien vers le commentaire

Scala permet d'appler du code dans la JVM, il n'y a pas de java ou de scala au runtime, la convention d'appel n'est pas liée au langage tongue.gif (et le sera encore moins avec invokeDynamic).

T'as bien fait de le préciser oui. Tu l'utilises au boulot ? Quel retour ?

Lien vers le commentaire

Un projet pilote seulement, pas un échec, mais pas un gros succès non plus, difficile de trouver la combinaison du bon use case et d'une équipe qui soit partante.

Si EDF Trading faisait une présentation pour le pricing, ça serait mieux, mais évidemment, ce n'est pas forcément dans leur intérêt de faire de l'évangélisation :D

Lien vers le commentaire

Un projet pilote seulement, pas un échec, mais pas un gros succès non plus, difficile de trouver la combinaison du bon use case et d'une équipe qui soit partante.

Si EDF Trading faisait une présentation pour le pricing, ça serait mieux, mais évidemment, ce n'est pas forcément dans leur intérêt de faire de l'évangélisation biggrin.gif

Non, ça c'est certain. Je demande ça par rapport au buzz auquel on a eu droit lors des dernières conf Jazoon ou Javaone.

Bilan : leurs yeux saignent, et 5 développeurs sont devenus fous, sourds et aveugles en tentant de maintenir le code Scala :P

hehe

Lien vers le commentaire
  • 1 month later...
  • 7 months later...

Ca y est, j'ai commencé à avoir des cours de Java (et lecture obligatoire du livre de Delannoy), avec un projet à rendre pour dans pas longtemps. Je crois comprendre l'utilité de la POO ainsi que la logique d'un programme Java un fois que j'ai le code complet sous mes yeux, mais je galère totalement quand il s'agit de le faire moi-même. Moi qui suis habitué à Perl, Bash et un peu de Python (et donc à lire le code uniquement de haut en bas), je ne retrouve plus mes repères et j'ai l'impression d'être un parfait idiot, c'est la panique totale.

Lien vers le commentaire

Ca y est, j'ai commencé à avoir des cours de Java (et lecture obligatoire du livre de Delannoy), avec un projet à rendre pour dans pas longtemps. Je crois comprendre l'utilité de la POO ainsi que la logique d'un programme Java un fois que j'ai le code complet sous mes yeux, mais je galère totalement quand il s'agit de le faire moi-même. Moi qui suis habitué à Perl, Bash et un peu de Python (et donc à lire le code uniquement de haut en bas), je ne retrouve plus mes repères et j'ai l'impression d'être un parfait idiot, c'est la panique totale.

 

J'ai donné des TP sur le sujet avec plus ou moins de succès, si t'as des questions précises pose les.

C'est quoi ton plus gros problème ? La syntaxe ou la POO en général.

Ceci dit t'en fait pas si l'I/O simple te semble complètement idiot en Java, c'est pour tout le monde pareil.

Lien vers le commentaire

Ca y est, j'ai commencé à avoir des cours de Java (et lecture obligatoire du livre de Delannoy), avec un projet à rendre pour dans pas longtemps. Je crois comprendre l'utilité de la POO ainsi que la logique d'un programme Java un fois que j'ai le code complet sous mes yeux, mais je galère totalement quand il s'agit de le faire moi-même. Moi qui suis habitué à Perl, Bash et un peu de Python (et donc à lire le code uniquement de haut en bas), je ne retrouve plus mes repères et j'ai l'impression d'être un parfait idiot, c'est la panique totale.

Tout spécialement en Java, j'expliquais aux étudiants perdus dans la modélisation objet qu'il faut penser sous la forme de "contrats" (je place les guillemets, parce que la programmation avec contrats, c'est une branche spécifique des langages de programmation. Je n'ai pas de mot plus approprié en français, malheureusement).

Imagine que lorsque tu codes, tu sois obligé de ne faire qu'une partie du programme, et qu'un collègue, embauché dans la même boite ou dans une boite à côté programme l'autre partie. Même sur un tout petit programme que tu réalises intégralement seul, garde ça en tête. Dès lors, afin de faire interagir ton code avec le sien, vous avez défini ce qui allait entrer et sortir des objets (les paramètres), les fonctions de l'objet, et ses propriétés. Après, tout ce qui est à l'intérieur ne regarde que toi (la manière dont tu as tout implémenté). Du moment que ce qui est visible de l'extérieur se conforme à votre "contrat", tout va bien.

Pour que cela fonctionne, un objet a une utilité, une seule tache. Tout comme lorsque tu codes en procédural/fonctionnel, une fonction = une tache, un objet = une tache. En Java (qui est verbeux), tu vas donc avoir des objets qui passent leur temps à s'appeler les fonctions des uns et des autres, en s'échangeant des messages (qui seront souvent eux-mêmes des objets encapsulant l'info).

 

Si vraiment tu veux une heuristique pour modéliser objet, dis-toi que si avant, tu aurais codé une fonction pour faire quelque chose, en POO, cette fonction sera un objet. Avec en plus la possibilité de présenter ses entrailles - les variables internes à la fonction - au reste du monde. Une fonction ne peut avoir qu'un seul retour, alors que l'objet permet "d'émuler" plusieurs retours différents. (C'est un peu crade de l'expliquer comme ça).

Lien vers le commentaire

@Nirvana :
La notion à comprendre en priorité est l'encapsulation. En résumé, l'utilisateur de ton code (un développeur donc, sûrement toi-même d'ailleurs) ne doit pouvoir l'utiliser que dans le cadre que tu lui as fixé. Par exemple, une classe Image qui encapsule un tableau d'entiers (les pixels) : on ne pourrait plus le redimensionner directement, on devrait appeler la fonction membre Resize en fournissant longueur et largeur.
Ensuite, pour l'héritage, il est indispensable de bien comprendre le principe de substitution de Liskov (LSP) et de l'appliquer à la lettre. En simplifiant, si B hérite de A, alors toute instance de B devrait pouvoir être utilisée en tant que A. Ma classe Image n'hérite donc pas d'un tableau d'entiers.

Enfin, une classe ne doit généralement correspondre qu'à une seule fonctionalité et on tachera de réduire au maximum les dépendances entre classes (cf. faible couplage, forte cohésion). L'héritage ne doit être utilisé QUE par logique conceptuelle, jamais pour des raisons pratiques.

Biensûr, il y a bien d'autres choses mais si tous les développeurs appliquaient déjà correctement ceci, le monde serait meilleur.

Lien vers le commentaire

L'héritage ne doit être utilisé QUE par logique conceptuelle, jamais pour des raisons pratiques.

 

Je résume par "si l’héritage d’implémentation est public dans la signature de ton API, tu est viré, si pour utiliser ton API il faut heriter d'une classe, tu est viré et tu sera stérile pendant 7 générations"

 

Et "Je brule les diagrammes de classes, et leurs auteurs, si je vois un diagramme d'héritage, ça DOIT être des interfaces"

Lien vers le commentaire

Je résume par "si l’héritage d’implémentation est public dans la signature de ton API, tu est viré, si pour utiliser ton API il faut heriter d'une classe, tu est viré et tu sera stérile pendant 7 générations"

 

Et "Je brule les diagrammes de classes, et leurs auteurs, si je vois un diagramme d'héritage, ça DOIT être des interfaces"

 

C'est vieux et j'ai la flemme de chercher, mais c'est pas comme ça qu'il fallait utiliser SAX2 ? Un des deux parser xml de Java ?

Pas que je critique ce que tu dis, plutôt un argument contre cette API en fait.

Lien vers le commentaire

Pire, cette pourriture de Swing (java2D est bien, mais swing, arghh) impose l'heritage d'implémentation pour faire un composent graphique, au lieu de fournir une simple interface...

 

Qu'il y ai une classe helper, pourquoi pas, mais l'obligation d'héritage de classe est une abomination qui mérite les feux de l'enfer.

Lien vers le commentaire

Pire, cette pourriture de Swing (java2D est bien, mais swing, arghh) impose l'heritage d'implémentation pour faire un composent graphique, au lieu de fournir une simple interface...

 

Qu'il y ai une classe helper, pourquoi pas, mais l'obligation d'héritage de classe est une abomination qui mérite les feux de l'enfer.

 

Très juste, en fait j'y pensais plus parce que je ne faisais rarement mes propres composantes, du coup c'était suffisant pour faire simplement une classe driver qui construisait une GUI.

Par contre Java3D c'est impossible de s'en sortir sans.

Java2D ? tu veux dire AWT ? Parce que Java2D c'est un peu primitif non ?

Lien vers le commentaire

Tu sais, on peut en faire en Cobol aussi. C'est juste pas complètement fait pour.

A un niveau d'abstraction très bas, on peut faire de l'objet en assembleur. A l'autre bout de l'échelle, on peut en faire aussi en Common Lisp, mais à quoi bon s'abaisser à une forme de programmation inférieure quand on peut toucher le firmament conceptuel des méta-abstractions ?

Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...