Aller au contenu

Introduction décente à l'orienté objet ?


Yozz

Messages recommandés

Bien que non informaticien, j'ai pour diverses raisons, envie de comprendre un peu mieux comment fonctionnent les langages orienté objet. Si tant qu'à faire, ça me permettait d'écrire l'une ou l'autre appli en java, ce serait un plus appréciable.

Quelqu'un aurait une recommandation de bouquin sympa allant en ce sens?

Je précise, le but n'est pas que je devienne un expert, loin de là, juste comprendre comment ça marche - une intro me convient mieux qu'une bible quoi. Et je n'ai pas un background informatique de folie.

J'ai trouvé ces deux bouquins qui m'ont l'air sympas, mais suis ouvert à d'autres suggestions:

Lien vers le commentaire
Bien que non informaticien, j'ai pour diverses raisons, envie de comprendre un peu mieux comment fonctionnent les langages orienté objet.

J'ai connu un consultant comme ça, une fois. Et ensuite, il a changé de job.

Si tant qu'à faire, ça me permettait d'écrire l'une ou l'autre appli en java, ce serait un plus appréciable.

Franchement, laisse tomber Java. Ca a vaguement été amusant en 98, quelques mois. Depuis, c'est le cobol de toute une génération, version bouffie.

Lien vers le commentaire
J'ai connu un consultant comme ça, une fois. Et ensuite, il a changé de job.

Tiens, je m'attendais à une vanne sur Java, mais non. :icon_up:

Sérieusement, c'est vraiment juste par curiosité, et même en changeant de boîte, je reste PM. Mais bon, ça fait jamais de tort de savoir ce que font ceux qu'on dirige :doigt:.

Lien vers le commentaire
Franchement, laisse tomber Java. Ca a vaguement été amusant en 98, quelques mois. Depuis, c'est le cobol de toute une génération, version bouffie.

Ah, quand même :icon_up:

Tu conseillerais quoi alors en oo, C++? Si je pense à Java, c'est parce que je pense à porter sous Java un petit script bash que j'utilise sous Linux pour mettre à jour ma to-do list. Le but étant de mettre l'appli sur un GSM sous Windows Mobile 6.

Lien vers le commentaire
ça fait jamais de tort de savoir ce que font ceux qu'on dirige :icon_up:.

Hé hé hé. Je vois que tu t'es bien fait enfumer. C'est ce qu'"ils" veulent te faire croire :mrgreen:

:doigt:

Ah, quand même :blushing:

Tu conseillerais quoi alors en oo, C++? Si je pense à Java, c'est parce que je pense à porter sous Java un petit script bash que j'utilise sous Linux pour mettre à jour ma to-do list. Le but étant de mettre l'appli sur un GSM sous Windows Mobile 6.

TU VEUX TRADUIRE UN SCRIPT BASH (qui fonctionne a priori très bien) EN JAVA ? :blushing::mrgreen:

TU AS UN GSM SOUS WM6 ? :blushing::mrgreen:

La grippe cogne tôt, cette année.

Lien vers le commentaire
Sérieusement, c'est vraiment juste par curiosité, et même en changeant de boîte, je reste PM.

Parliament Member ? Phase Modulator ? Pontifex Maximus ? :icon_up:

Lien vers le commentaire
TU VEUX TRADUIRE UN SCRIPT BASH (qui fonctionne a priori très bien) EN JAVA ? :mrgreen: :mrgreen:

Si tu trouves un bon smartphone qui me permettra de faire tourner mon script bash, je suis preneur!

TU AS UN GSM SOUS WM6 ? :mrgreen::doigt:

Non, mais Cata bien, et il est très cool, et je veux le même! HTC Touch au passage.

Parliament Member ? Phase Modulator ? Pontifex Maximus ? :icon_up:

Project Manager, aka Pretentious Monkey.

Lien vers le commentaire
Si tu trouves un bon smartphone qui me permettra de faire tourner mon script bash, je suis preneur!

Je vais en parler à mon frigo qui fait aussi appareil photo.

Non, mais Cata bien, et il est très cool, et je veux le même! HTC Touch au passage.

Tu peux te Touch le DTC comme tu veux, ça ne change rien à cette vérité intangible : Java, c'est bouffi.

Bon, pour en revenir à ton bouquin, je ne sais pas. Mais j'aurai tendance à choisir plutôt le 1er.

Lien vers le commentaire
J'ai eu un cours de Java l'année dernière - avec une prof nullissime - et j'ai utilisé ce bouquin qui est correct :

Sinon, je t'envoie un MP parce que j'ai des secrets à te dire. :icon_up:

Merci!

Et pour répondre à ton MP, la marmotte aime la confiture, je répète, la marmotte aime la confiture. :doigt:

Lien vers le commentaire
Quelqu'un aurait une recommandation de bouquin sympa allant en ce sens?

Informaticien mais pas développeur de profession, je dirais qu'il y a une différence importante entre savoir écrire un code dans la syntax Objet du langage de ton choix et, penser objet.

Pendant longtemps j'ai fait du code procédural en utilisant la syntaxe objet sans comprendre l'apport de l'objet.

Le modèle objet répond à une façon différente d'organiser un programme, beaucoup de ces façons différentes reviennent de manière récurrentes et ont été rassemblés sous le terme de design patern.

Mon conseil est donc, choisi un langage objet quelconque PHP à l'avantage de la simplicité, sinon C# ou Java.

Une foi les aspects clé de la syntaxe objet assimilés, concentre toi simplement sur le design d'appli, les deux s'articulent naturellement.

Peut être feuilleter ce bouquin pourrait te convenir, mais je ne le connais pas.

ou celui-ci qui aborde aussi les design paterne. il ne parle presque pas de code mais permet de survoler des aspect clef de la programation.

Lien vers le commentaire
L'avenir de la programmation est aux langages qui suivent le modèle multi-agents, comme Erlang.

Erlang c'est du fonctionnel distribué en temps réel. Le "multi-agents" c'est un peu du pipeau dans mon labo il y a une équipe multi agents et ils n'ont jamais réussi à m'expliquer en quoi leur truc était un modèle de calcul et non juste une technique d'ingéniérie comme une autre.

Lien vers le commentaire
Sérieusement, c'est vraiment juste par curiosité, et même en changeant de boîte, je reste PM. Mais bon, ça fait jamais de tort de savoir ce que font ceux qu'on dirige :icon_up:.

Chose assez marrante, les plus mauvais programmeurs que j'ai pu voir avaient comme rêve de devenir chefdeprojet.

Probablement en s'imaginant qu'ils en branleraient pas une tout en en donnant du travail aux autres.

Personnellement, je pense que tout project manager qui ne maîtrise pas ce que font ceux qu'il dirige, est inutile voire nuisible. Pire qu'un consultant, quoi !

Enfin, ça ne m'étonne pas de la boîte qui t'emploie :doigt:.

Lien vers le commentaire
Bien que non informaticien, j'ai pour diverses raisons, envie de comprendre un peu mieux comment fonctionnent les langages orienté objet. Si tant qu'à faire, ça me permettait d'écrire l'une ou l'autre appli en java, ce serait un plus appréciable.

Quelqu'un aurait une recommandation de bouquin sympa allant en ce sens?

Je précise, le but n'est pas que je devienne un expert, loin de là, juste comprendre comment ça marche - une intro me convient mieux qu'une bible quoi. Et je n'ai pas un background informatique de folie.

En fait ce qu'il te faut c'est plus un bouquin sur la manière de penser Orienté Objet. Les détails techniques du Java tu t'en fous comme de l'an 40 et de toute manière une fois que tu as saisi les idées générales l'incarnation dans un langage particulier c est au plus une après midi (mais ça c'est si tu veux coder). Malheureusement j'y connais pas grand chose (je fais plutot du fonctionnel en cours).

Sinon l'objet c'est bien pour programmer propre (je pense que j'ai fais mon plus gros programme bug free en eiffel quasi du premier coup) et c'est très adapté pour des choses spécifiques (la spécialisation d'objets pour de vrai on en a rien à carrer dans la vie de tous les jours sauf si on fait des fenêtres).

Pour moi tu as deux livres fait par des gens sérieux (mais ce sera peut etre trop mathématique comme approche pour toi):

mais si tu les comprend bien, le reste c'est du pipeau.

Lien vers le commentaire

L'objet c'est comme du fonctionnel. C'est plus propre, et si le langage introduit l'héritage et autres joyeusetés, aussi beaucoup plus pratique. Mais essentiellement, un programme bien écrit dans un langage fonctionnel sera organisé de manière très proche à un programme écrit en objet.

Lien vers le commentaire
L'objet c'est comme du fonctionnel. C'est plus propre, et si le langage introduit l'héritage et autres joyeusetés, aussi beaucoup plus pratique. Mais essentiellement, un programme bien écrit dans un langage fonctionnel sera organisé de manière très proche qu'un programme écrit en objet.

Sachant qu'on peut mélanger les deux. CLOS a été le premier langage (ou plutôt la seule extension de langage) à respecter intégralement les paradigmes objet et fonctionnel. Jusque dans les moindres détails.

Lien vers le commentaire
Sachant qu'on peut mélanger les deux. CLOS a été le premier langage (ou plutôt la seule extension de langage) à respecter intégralement les paradigmes objet et fonctionnel. Jusque dans les moindres détails.

CAML c'est beau ; ça fait la même chose mais en plus subtil avec un typage fort inféré automatiquement (CLOS est pas typé, c'est mal, on trouvera les bases théorique de la délégation dans le bouquin d'Abadi et Cardelli que je citais). En fait l'héritage la plupart du temps ne sert à rien, les modules (encapsulation, signatures) sont souvent largement suffisants avec des foncteurs.

Sinon la remarque de pankkake est vrai, de toutes manières les langages sont tous turring-équivalents alors d'un point de vue de théorique on peut tout faire dans tous si on s'en donne les moyens :icon_up: en ce qui concerne les paradigmes de programmation on pourrait faire les analogies suivantes

  • Fonctionel (réécriture): pour évaluer des fonctions (calcul le prix de ton billet avec les réducs et tout)
  • Impératif : pour tenir à jour des informations (enregistre le fait que tu as acheté le billet)
  • Distribué : pour gérer les aspects interactifs-communication (communique ton achat à la base de données)
  • Objet : pour gérer les aspects génie logiciel : gros truc, réutilisabilité (à la sncf s'ils connaissent ça se voit pas)
  • Quantique : pour les rêveurs (pour factoriser plus vite que son ombre)
  • Logique : quand on ne sait pas quel algorithme appliquer (pour résoudre sans soucis les problêmes de télé7 jours)
  • Par contraintes : pour l'optimisation numérique (pour engendre l'emploi du temps des infirmières avec les 876 règles légales à respecter)

Dans le tas c'est quand même l'objet qui est le moins "paradigme de programmation", ça se rapproche plus d'une auto-discipline.

Lien vers le commentaire
Chose assez marrante, les plus mauvais programmeurs que j'ai pu voir avaient comme rêve de devenir chefdeprojet.

Probablement en s'imaginant qu'ils en branleraient pas une tout en en donnant du travail aux autres.

Personnellement, je pense que tout project manager qui ne maîtrise pas ce que font ceux qu'il dirige, est inutile voire nuisible. Pire qu'un consultant, quoi !

Enfin, ça ne m'étonne pas de la boîte qui t'emploie :doigt:.

Et moi cette position ne m'étonne pas de ta part; vu que tu démontres à longueur de temps ton incapacité à t'élever au-dessus de la technique pour comprendre les besoins business :mrgreen:.

Un chef de projet a pour but de s'assurer qu'un projet livre ce qui a été convenu dans les temps, dans le budget, et avec la qualité requise. Pour évaluer, comprendre, et maitriser tout ça, aucun besoin de comprendre le détail de la technique - il peut s'appuyer sur l'expertise de son équipe et de tiers pour ce qu'il a besoin là-dessus. Il suffit qu'il comprenne les choses de haut niveau. Les connaissances techniques sont un plus, mais certainement pas un pré-requis.

Au contraire, je soutiens que les plus mauvais chefs de projets sont ceux qui viennent de la technique, parce qu'ils restent trop près de la technique, s'ingénient à résoudre les problèmes techniques en négligeant le reste, et passent à côté de l'essentiel du projet. Ils livrent un truc tout beau, bien torché techniquement, manque de bol, c'est pas ce que le client voulait, trop cher, et pas dans les temps. Mais ils s'en foutent, ils savent mieux que le client, qui n'est pas techos :icon_up:

C'est d'autant plus vrai quand joue le halo effect, et que des techniciens sont promus PM sans en avoir les skills - ce qui est fréquent, ne fût-ce que parce que beaucoup de techos n'ont pas les people skills requis pour la gestion de projet.

Bref, pas confondre PM et chef d'équipe, qui lui doit avoir les skills techniques évidemment.

Lien vers le commentaire
Informaticien mais pas développeur de profession, je dirais qu'il y a une différence importante entre savoir écrire un code dans la syntax Objet du langage de ton choix et, penser objet.

Pendant longtemps j'ai fait du code procédural en utilisant la syntaxe objet sans comprendre l'apport de l'objet.

Le modèle objet répond à une façon différente d'organiser un programme, beaucoup de ces façons différentes reviennent de manière récurrentes et ont été rassemblés sous le terme de design patern.

Mon conseil est donc, choisi un langage objet quelconque PHP à l'avantage de la simplicité, sinon C# ou Java.

Une foi les aspects clé de la syntaxe objet assimilés, concentre toi simplement sur le design d'appli, les deux s'articulent naturellement.

Peut être feuilleter ce bouquin pourrait te convenir, mais je ne le connais pas.

ou celui-ci qui aborde aussi les design paterne. il ne parle presque pas de code mais permet de survoler des aspect clef de la programation.

Oui, je me demandais si en fait les design patterns ne seraient pas intéressants à investiguer, mais un copain m'a dit hier que ce serait peut-être difficile sans avoir assez de connaissances en programmation (moi mon niveau, c'est shell scripting un peu de base, puis c'est tout).

Lien vers le commentaire
Bref, pas confondre PM et chef d'équipe, qui lui doit avoir les skills techniques évidemment.

Ah, OK. Parce que moi j'ai vu la situation "pur project manager sans chef d'équipe", et c'était une catastrophe.

Je pense que l'idéal c'est que la personne soit capable de faire les deux choses.

Lien vers le commentaire
En fait ce qu'il te faut c'est plus un bouquin sur la manière de penser Orienté Objet. Les détails techniques du Java tu t'en fous comme de l'an 40 et de toute manière une fois que tu as saisi les idées générales l'incarnation dans un langage particulier c est au plus une après midi (mais ça c'est si tu veux coder). Malheureusement j'y connais pas grand chose (je fais plutot du fonctionnel en cours).

Sinon l'objet c'est bien pour programmer propre (je pense que j'ai fais mon plus gros programme bug free en eiffel quasi du premier coup) et c'est très adapté pour des choses spécifiques (la spécialisation d'objets pour de vrai on en a rien à carrer dans la vie de tous les jours sauf si on fait des fenêtres).

Pour moi tu as deux livres fait par des gens sérieux (mais ce sera peut etre trop mathématique comme approche pour toi):

mais si tu les comprend bien, le reste c'est du pipeau.

D'accord avec la logique générale, mais si tu me dis que l'approche est très mathématique dans ces bouquins, ca risque d'être dur pour moi…

Lien vers le commentaire
Ah, OK. Parce que moi j'ai vu la situation "pur project manager sans chef d'équipe", et c'était une catastrophe.

Ca dépend, ça peut marcher sur un petit projet (disons, 6-7 personnes grand maximum) où on peut communiquer vite et bien entre PM et membres d'équipe (ce qui ne sera pas le cas par ex si les 6 personnes sont par ex trois groupes de 2 bossant sur des trucs très différents comme, par ex, BDD, Business Logic et GUI) . Mais il faut pour ça

1) que le PM soit suffisamment malin (et humble, talon d'achille de beaucoup de PM) pour demander qu'on lui explique quand il a besoin de comprendre un truc

2) que les techos soient suffisamment patients pour expliquer à un non-techos

3) que les uns et les autres puissent se rencontre à mi-chemin entre langage pur business et langage pur technique

A défaut de ces 3 trucs là, oui, le PM doit être techos.

Sur un projet plus gros, c'est mort, il faut des chefs d'équipe. Au passage, même si le PM est techos lui-même, parce que sinon il risque de passer trop longtemps à discuter avec tout le monde pour voir où tout va sans avoir le temps de faire autre chose.

Je pense que l'idéal c'est que la personne soit capable de faire les deux choses.

C'est clair, le souci, c'est que c'est très rare d'être au top dans les deux domaines. Chef de projet, c'est un métier, développeur (ou autre fonction technique) aussi, et un métier ça demande de se tenir à jour, de se former, et d'avoir de l'expérience. C'est le plus gros argument contre le PM pur techos: quand tu gères des projets pendant des annés, tu n'as matériellement pas le temps de te tenir assez à jour pour rester un super techos. Et pourtant, tout le monde est d'accord, les "vieux" PM (j'entends ceux qui ont de l'expérience) sont les meilleurs.

Maintenant, c'est clair, au plus on peut marier les deux, au mieux. C'est pourquoi j'essaye d'investiguer la technique un minimum hein :icon_up:

Lien vers le commentaire
j'ai java head first; si ca t'intéresse, je peux te le préter :icon_up: (il est bon)

Ben s'il est bon, je me le paierai bien, j'aime bien étoffer ma bibliothèque. Je sais que c'est une bonne collection - j'ai le Head First PMP qui arrive à rendre le PMBOK marrant, ce qui est un tour de force - mais je me demandais s'il ne serait pas trop axé pissage de code sans explication conceptuelle. Ton avis?

sinon cadeau: javabat

Ehhh, mais ça a l'air très cool ça, merci! :doigt:

Sinon .net>java

Pourquoi? Pas uniquement parce que c'est MS quand même, :mrgreen:

Lien vers le commentaire
1) que le PM soit suffisamment malin (et humble, talon d'achille de beaucoup de PM) pour demander qu'on lui explique quand il a besoin de comprendre un truc

2) que les techos soient suffisamment patients pour expliquer à un non-techos

3) que les uns et les autres puissent se rencontre à mi-chemin entre langage pur business et langage pur technique

A défaut de ces 3 trucs là, oui, le PM doit être techos.

Je pense qu'il faut quelqu'un qui lise le code des autres, qu'on aille voir pour les décision importantes et qui soit capable de choisir une solution (histoire d'éviter les trolls improductifs).

Lien vers le commentaire
Je pense qu'il faut quelqu'un qui lise le code des autres, qu'on aille voir pour les décision importantes et qui soit capable de choisir une solution (histoire d'éviter les trolls improductifs).

Lire le code des autres, pour vérifier la qualité, ça peut être le rôle d'un tiers qui fait de la QA, pas de souci. Il rapporte au chef de projet et voilà.

Pour les décisions importantes, soit elles sont de type fonctionnelle, et pas besoin d'être techos, soit elles sont de type architecturale ou d'implémentation, et il "suffit" que le PM se fasse expliquer les différentes implications et décide (éventuellement en prenant un avis extérieur - dont, presque toujours, celui du client). Evidemment, ca suppose les trois conditions que j'ai expliquées au-dessus, ça c'est vrai.

Objectivement, c'est rare qu'un projet foire pour des raisons purement techniques. C'est le plus souvent mal vendu, ou mal géré (et souvent les deux) - surtout au niveau fonctionnel. Parce qu'une des idées trop répandues c'est de croire que gérer un projet c'est facile. Ben non. Et de ce fait, c'est clair, il y a beaucoup de mauvais chefs de projet.

Gérer la productivité par contre, aucun besoin de compétences techniques - le status reporting sert à ça. Et des techniques de PM comme l'EVM par exemple.

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...