Jump to content
Yozz

Introduction décente à l'orienté objet ?

Recommended Posts

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

Je vais essayer de te faire appréhender en 2 ligne la façon don je vois les choses, je ne pense pas être à coté de la plaque.

Dans un programme procédural tout est en vrac, tu vas définir les unes après les autres les variables qui caractérisent tes clients, tes stock, tes fournisseurs.

Les opérations se succèdent avec des tests divers, ta variable stock va diminuer de un quand le "panier" du troisième sous tableau des clients (client3) vas croitre d'autant et inversement pour la variable "crédit".

Les routines les plus souvent utilisées seront mises sous formes de fonctions.

Dans un programme objet, c'est tout autre.

tu t'inspires de la réalité. ton stock, tes fournisseurs tes clients prennent vie et deviennent logiquement autonome.

Chaque nouveau client correspond à une instance de l'objet client.

Chaque instance contient tout ce qui est nécessaire au client, une variable "panier", une méthode "achat", une variable "temps passé", une méthode "reste à chercher", la méthode pour accéder aux achats passés etc….

L'objet stock contient la liste de toute les références (ou ce qu'il faut pour les récupérer dans la BdD), les routines de commandes au près des fournisseurs, les variables seuil pour les déclanchér, qui sont elle même positionnées par les objets "vendeurs.chefderayon" qui hérite de l'objet "vendeur" mais dispose d'une variable "code-commande" qui permet de s'authentifier.

tout le code d'un objet est rassemblé au même endroit.

Bref chaque objet contient tout ce dont il a besoin, tu en cré autant d'instances que nécessaire et le cœur du programme ne sert qu'a les faire communiquer entre eux. C'est très naturel une fois qu'on y a réfléchit et très lisible, facilement évolutif voir même réutilisable.

Voilou

Share this post


Link to post
Share on other sites
Merci!

je plussoires le delanoye

Et utilise Eclipse, ou IntelliJIDEA si tu es riche. Sans refactoring, la POO c'est du masochisme.

Share this post


Link to post
Share on other sites
Je vais essayer de te faire appréhender en 2 ligne la façon don je vois les choses, je ne pense pas être à coté de la plaque.

Dans un programme procédural tout est en vrac, tu vas définir les unes après les autres les variables qui caractérisent tes clients, tes stock, tes fournisseurs.

Les opérations se succèdent avec des tests divers, ta variable stock va diminuer de un quand le "panier" du troisième sous tableau des clients (client3) vas croitre d'autant et inversement pour la variable "crédit".

Les routines les plus souvent utilisées seront mises sous formes de fonctions.

Dans un programme objet, c'est tout autre.

tu t'inspires de la réalité. ton stock, tes fournisseurs tes clients prennent vie et deviennent logiquement autonome.

Chaque nouveau client correspond à une instance de l'objet client.

Chaque instance contient tout ce qui est nécessaire au client, une variable "panier", une méthode "achat", une variable "temps passé", une méthode "reste à chercher", la méthode pour accéder aux achats passés etc….

L'objet stock contient la liste de toute les références (ou ce qu'il faut pour les récupérer dans la BdD), les routines de commandes au près des fournisseurs, les variables seuil pour les déclanchér, qui sont elle même positionnées par les objets "vendeurs.chefderayon" qui hérite de l'objet "vendeur" mais dispose d'une variable "code-commande" qui permet de s'authentifier.

tout le code d'un objet est rassemblé au même endroit.

Bref chaque objet contient tout ce dont il a besoin, tu en cré autant d'instances que nécessaire et le cœur du programme ne sert qu'a les faire communiquer entre eux. C'est très naturel une fois qu'on y a réfléchit et très lisible, facilement évolutif voir même réutilisable.

Voilou

Ben la logique, ça je la vois, je pense que j'ai compris, mais bizarrement, quand je passe en mode code, ben j'ai du mal à me défaire d'une lecture très "itérative" du code, j'ai du mal à me mettre à écrire en OO. Mais bon, 2h d'essais sans maîtriser la syntaxe, faut pas demander des miracles non plus :icon_up:

je plussoires le delanoye

Cool, c'est un des moins chers en plus :doigt:

Et utilise Eclipse, ou IntelliJIDEA si tu es riche. Sans refactoring, la POO c'est du masochisme.

Ah ben évidemment, eh, j'ai pas passé 2 ans chez IBM pour rien :mrgreen: Mieux encore en fait, j'utilise Rational Team Concert (ce qui dans le cas de moi tout seul dans mon coin pour bidouiller des conneries ne m'apporte rien de plus, mais bon, j'ai un copain qui le vend alors voilà :mrgreen: )

Share this post


Link to post
Share on other sites
Ben la logique, ça je la vois, je pense que j'ai compris, mais bizarrement, quand je passe en mode code, ben j'ai du mal à me défaire d'une lecture très "itérative" du code, j'ai du mal à me mettre à écrire en OO. Mais bon, 2h d'essais sans maîtriser la syntaxe, faut pas demander des miracles non plus :doigt:

C'est normal, la même chose pour moi, c'est comme de passer de socialiste à libéral faut tout réorganiser dans le cerveau. :icon_up:

Ca vient peu à peu en essayant de résoudre les problèmes pour finir ton projet, pour chaque fonction ou variable demande toi si ça peut être inclu dans un objet et lequel (parfois ce n'est pas évident) et si tu ne trouve rien qui fasse sens met le dans le corps du programme.

Share this post


Link to post
Share on other sites
C'est normal, la même chose pour moi, c'est comme de passer de socialiste à libéral faut tout réorganiser dans le cerveau. :icon_up:

Je ne sais pas, je n'ai jamais eu ce problème :doigt:

Ca vient peu à peu en essayant de résoudre les problèmes pour finir ton projet, pour chaque fonction ou variable demande toi si ça peut être inclu dans un objet et lequel (parfois ce n'est pas évident) et si tu ne trouve rien qui fasse sens met le dans le corps du programme.

Oui, je pense que c'est ça. J'en arrive à la conclusion que quand on débute à partir de rien comme moi, il faut passer un peu de temps avec un papier et un crayon à modéliser un peu ce qu'on veut faire plutôt que de commencer à écrire n'importe quoi et à essayer de le réparer après (comme on peut très bien le faire dans un langage comme bash).

Share this post


Link to post
Share on other sites

Les trucs les plus horribles que j'ai pu écrire sont en bash… c'est un langage rigolo, plus ou moins métaprogrammable, et ultra sale (en plus d'être ultra lent vu le nombre de fork() qu'on fait) :doigt:… et je continue à l'utiliser. :icon_up:

Pour la différence procédural/objet citée plus haut, c'est la comparaison avec du mauvais procédural. L'objet à deux balles (i.e. qui sert juste à dire "j'ai fait de l'objet") est tout aussi catastrophique.

Sinon, je conseille de regarder les "design patterns" ou des projets déjà faits pour voir quelles peuvent être les bonnes façons de faire de l'objet.

Share this post


Link to post
Share on other sites
Oui, je pense que c'est ça. J'en arrive à la conclusion que quand on débute à partir de rien comme moi, il faut passer un peu de temps avec un papier et un crayon à modéliser un peu ce qu'on veut faire plutôt que de commencer à écrire n'importe quoi et à essayer de le réparer après (comme on peut très bien le faire dans un langage comme bash).

Rassure toi : plus on d'expérience plus on passe de temps à réfléchir avant de taper la première ligne de code. Pour être polémique je dirais que l'informatique n'est pas une science expérimentale comme l'est la physique. Un programme qui s'éxécute, ce sont des maths "qui marchent" en direct devant toi. C'est ce que l'homme a fait de plus près de la magie depuis qu'il existe : la transformation quasi directe d'idées en une réalité palpable, visible (le pixel qui s'allume).

Share this post


Link to post
Share on other sites

Avec le temps m'est venue la sagesse :icon_up: et la sagesse, la voici : en pratique la bonne solution est de coder le moins possible. À moins de faire un truc ultra-innovant, 90% du code qui tournera est composé de choses qui existent déjà. Alors, chercher des outils (bibliothèques, etc) avant de chercher le langage, et s'adapter en fonction. À moins que ce soit vraiment du cobol ou qu'il y ait un gros souci de performance à la clé, c'est ce qui paie le mieux.

PS : oui, java c'est verbeux comme du cobol mais avec un bon ide, contrairement au cobol on a rien à taper du verbiage inutile. Alors du coup ça se compare pas vraiment. Et le refactoring semi-automatisé c'est top génial.

Share this post


Link to post
Share on other sites
Et le refactoring semi-automatisé c'est top génial.

Quand et si ça marche.

Share this post


Link to post
Share on other sites
Quand et si ça marche.

Dans mon expérience, ça marche suffisamment bien pour faire gagner tout un tas de temps.

Share this post


Link to post
Share on other sites

Tant mieux. Ce n'est pas toujours le cas.

Share this post


Link to post
Share on other sites
Et le refactoring semi-automatisé c'est top génial.

Sans doute. Mais de quoi s'agit-il ?

Share this post


Link to post
Share on other sites
Sans doute. Mais de quoi s'agit-il ?

Faire du "refactoring", c'est modifier la façon dont est écrit un programme sans changer son fonctionnement (pour le rendre plus simple à comprendre, plus évolutif, etc.) Par exemple, si l'on se rend compte qu'à l'intérieur d'une fonction, il y a quelques lignes de code qui jouent un rôle bien précis, on peut "extraire" ces quelques lignes dans une fonction correctement nommée.

On peut faire du refactoring à la main, mais c'est rébarbatif. Aussi, certains environnements proposent des outils pour aider le développeur. Ces outils vont au-delà de la fonction "Rechercher / Remplacer", puisqu'ils "comprennent" le langage utilisé.

Share this post


Link to post
Share on other sites
Par exemple, si l'on se rend compte qu'à l'intérieur d'une fonction, il y a quelques lignes de code qui jouent un rôle bien précis,

A plusieurs endroits. Sinon, l'intérêt est modéré.

Share this post


Link to post
Share on other sites
A plusieurs endroits. Sinon, l'intérêt est modéré.

Tout ce que je peux placer dans une fonction, je le place dans une fonction.

Mais c'est vrai que ça dépend du langage. En Lisp ou en Forth, par exemple, il n'y a aucune raison de ne pas le faire, puisqu'il n'y a pas de "coût syntaxique". En C ou en C++, puisqu'il faut déclarer les fonctions et déclarer le type des paramètres, et comme on ne peut pas imbriquer les fonctions, on a tendance à éviter d'avoir plein de petites fonctions, tout simplement parce que ça "surcharge" le code source.

Share this post


Link to post
Share on other sites
Rassure toi : plus on d'expérience plus on passe de temps à réfléchir avant de taper la première ligne de code. Pour être polémique je dirais que l'informatique n'est pas une science expérimentale comme l'est la physique. Un programme qui s'éxécute, ce sont des maths "qui marchent" en direct devant toi. C'est ce que l'homme a fait de plus près de la magie depuis qu'il existe : la transformation quasi directe d'idées en une réalité palpable, visible (le pixel qui s'allume).

Tchu, je suis déjà vachement expérimenté alors :doigt:

Avec le temps m'est venue la sagesse :icon_up: et la sagesse, la voici : en pratique la bonne solution est de coder le moins possible. À moins de faire un truc ultra-innovant, 90% du code qui tournera est composé de choses qui existent déjà. Alors, chercher des outils (bibliothèques, etc) avant de chercher le langage, et s'adapter en fonction. À moins que ce soit vraiment du cobol ou qu'il y ait un gros souci de performance à la clé, c'est ce qui paie le mieux.

PS : oui, java c'est verbeux comme du cobol mais avec un bon ide, contrairement au cobol on a rien à taper du verbiage inutile. Alors du coup ça se compare pas vraiment. Et le refactoring semi-automatisé c'est top génial.

Et en plus je suis déjà un sage :mrgreen:

C'est clair que vu les trucs de base que je fais, je pompe essentiellement des classes existantes, et les applique juste à mon cas en les agençant comme il faut. Code vraiment écrit par moi dans ce que j'ai déjà fait en java, 3 lignes (et des lignes à la con évidemment).

Mais c'est pas grave, mon but c'est surtout de comprendre la logique du truc, donc j'apprend quand même ce qui m'intéresse. Et puis je vais commander le bouquin qu'Etienne et AB conseillent.

Share this post


Link to post
Share on other sites
Avec le Java, langage simpliste et limité, ça marche.

Le Java est loin d'être aussi limité qu'il a été. Donne moi un exemple de ce que tu appelles simpliste et limité ?

Share this post


Link to post
Share on other sites
Le Java est loin d'être aussi limité qu'il a été. Donne moi un exemple de ce que tu appelles simpliste et limité ?

C : un macro assembleur portable.

Share this post


Link to post
Share on other sites

:icon_up:

Il n'est pas impossible que je me mette un jour à l'orienté objet, mais j'aime comprendre de quoi il retourne avant de pondre du code. Je veux dire, j'ai fait quelques heures de Delphi plus jeune, mais en gardant une façon de pensée "programmation procédurale". Actuellement, je fais du COBOL (et on me considère comme plutôt bon), et beaucoup de SQL (et l'on me considère comme très au dessus du lot).

Les deux bouquins conseillés par Kassad me semblaient intéressants, mais ils sont aujourd'hui tout à fait hors de prix (et je refuse de croire qu'ils puissent exister en version pir4te, allons) ; de plus, je préfère aborder un continent inconnu en français (quitte à approfondir dans des bouquins en anglais dans un second temps).

J'avais trouvé un gros livre de Hugues Bersini, et un très gros livre de Bertrand Meyer, mais j'ignore ce qu'ils valent. Des retours de la part de gens qui les ont lus ? Des conseils pour d'autres livres d'une portée aussi générale ?

Share this post


Link to post
Share on other sites

L'orienté objet, mmh.

Au hasard,

Existe en version Kindle. Tu télécharges le logiciel Kindle et tu lis le livre sur l'ordi. Mieux que le papier selon moi.

Share this post


Link to post
Share on other sites

Une fois les rudiments, il y a ces livres en anglais qui sont plutôt bons pour ce qui concerne les design patterns. Le deuxième est dispo pour moitié moins cher lorsque tu utilises une version kindle.

Sinon ce qui me parait très utile vu que tu touches à du SQL donc à des applications en entreprises, c'est de parler des trucs nouveaux, en l'occurrence on peut faire d'une pierre deux coups en parlant de Spring.

Dispo pour Java essentiellement et permet de se familiariser avec les meilleures techniques actuelles de développement.

Share this post


Link to post
Share on other sites

icon_up.gif

Des conseils pour d'autres livres d'une portée aussi générale ?

Je crois que tu devrais commencer par un langage fortement orienté objet (java/c#t/powershell) ça sera plus facile pour aborder des sujets avancés comme les design paternes.

Je trouve que passer de la programmation "procédurale" à la programmation "évènementielle" est déjà en soit assez difficile quand on a pris des habitudes.

Share this post


Link to post
Share on other sites

Les Head First sont bien, en général, avec une touche d'humour, par contre je ne me souviens pas qu'ils étaient aussi cher… Mon frère a eu Meyer comme prof, il peut être un peu "aride".

Je ne sais pas si tout le monde utilise l'astuce, mais pour avoir une idée du contenu d'un bouquin : Google Books. C'est bien pratique (parfois quand on a besoin que de 2 ou 3 pages, elles sont justement dans les pages en ligne !) http://books.google.fr/books?id=5VTBuvfZDyoC&printsec=frontcover&dq=head+first&hl=fr&sa=X&ei=ij5wT-uoEeGX1AXwydCNAg&ved=0CDIQ6AEwAA#v=onepage&q=head%20first&f=false

Share this post


Link to post
Share on other sites

Quelle que soit la source, garder une vue pragmatique, il n’y a pas de méthodologie de conception qui souffre plus de la tentation de l’universalité que la POO, au point de nier les avantages du modèle relationnel en le cachant derrière un pseudo modèle réseau ou au point d’ignorer sciemment les avantages en terme de fiabilité et de scalabilité de la programmation fonctionnelle.

Je ne crache pas sur l’objet, je préviens juste que ça grouille d’intégristes…

Ah oui, et méfiance sur les design patterns, un grand nombre de patterns ne sont pas là parce qu’ils pallient a des manques de l’objet en général mais bien parce qu’ils pallient a des manques du C++…

Share this post


Link to post
Share on other sites

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

"Pontifex maximus" , toi tu as du jouer à Romejpem !

Share this post


Link to post
Share on other sites

Les propos tenus sur ce fil me suprennent. Déjà, je m'étonne qu'on puisse chercher à aborder la POO par l'étude d'un "gros bouquin". Pour moi mieux vaut étudier un langage en particulier qui implémente la POO plutôt que de vouloir étudier la POO en soi.

Mon point de vue d'amateur:

La POO c'est tout de même pas si compliqué. Ca ne l'est que si on rentre dans les détails, héritage multiple, rôles, interfaces, que sais-je encore. Le plus souvent on a pas besoin de ces détails. On peut les apprendre au fur et à mesure qu'on les rencontre.

Et puis il y a pleins d'approches différentes. Comme disent les programmeur Perl, "There is more than one way to do it". C'est très vrai en POO. Donc aborder la POO par l'étude de la POO, c'est une volonté excessive de synthèse amha.

Pour moi le mieux c'est d'étudier chacun des languages séparément.

C++ est une référence incontournable amha. Quand (et si) on comprend celui là on comprend déjà plus ou moins tous les dérivés, en commencant par java.

Ensuite il y les langages dynamiques qui sont très faciles à comprendre et qui sont une initiation simple à l'objet: python, ruby et sûrement pleins d'autres que j'ignore.

Share this post


Link to post
Share on other sites

Certains vont encore dire que je radote mais je trouve que le couple Cocoa-Objective-C avec son Modèle-Vue-Controleur est une parfaite initiation à la POO.

Share this post


Link to post
Share on other sites

J'avais trouvé un gros livre de Hugues Bersini, et un très gros livre de Bertrand Meyer, mais j'ignore ce qu'ils valent. Des retours de la part de gens qui les ont lus ? Des conseils pour d'autres livres d'une portée aussi générale ?

J'ai le Meyer dans ma bibliothèque, mais je suis loin d'avoir tout lu en entier, c'est un livre que je conseillerais comme référence et dans un but de progresser en POO, mais pas pour accompagner un apprentissage. Comme le livre sur les Design Patterns de Gamma : c'est le genre de livre sur lequel il faut revenir plusieurs fois avant de bien en saisir toutes les subtilités, et pour en saisir les subtilités il faut déjà avoir mis les mains dans le code. Et ça ne se lit pas d'une traite en 1 mois… sauf si tu as des problèmes d'insomnies :)

Mais en termes de livres a portée générale, c'est effectivement une référence, très touffu, très complexe, et très aride. J'ai quand même appris beaucoup de choses sur l'OO rien qu'en lisant les premiers chapitres. En particulier j'ai trouvé les justifications de certains concepts, là où d'autres livres ne proposent que des méthodes particulières d'utiliser une certaine implémentation de ces concepts. Ceci dit, dans une approche pragmatique, on n'a pas forcément besoin de tout comprendre du premier coup pour être opérationnel.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...