Aller au contenu

Introduction décente à l'orienté objet ?


Yozz

Messages recommandés

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

Lien vers le commentaire
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: )

Lien vers le commentaire
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.

Lien vers le commentaire
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).

Lien vers le commentaire

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.

Lien vers le commentaire
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).

Lien vers le commentaire

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.

Lien vers le commentaire
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é.

Lien vers le commentaire
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é.

Lien vers le commentaire
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.

Lien vers le commentaire
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.

Lien vers le commentaire
  • 3 years later...

: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 ?

Lien vers le commentaire

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.

Lien vers le commentaire

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.

Lien vers le commentaire

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

Lien vers le commentaire

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++…

Lien vers le commentaire

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.

Lien vers le commentaire

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.

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