Quand faut-il utiliser la programmation objet ?

falke · Le 02/07/2011, à 19:00

bonjour,

dans quel cas de figure convient-il mieux d'utiliser la programmation objet plutôt que la programmation procédurale ? Quel est le critère retenu, le type de "situation" qui l'exige.

Je suis sur python depuis quelque temps et il semblerait que ce langage permet d'utiliser l'une ou l'autre méthode dans un même programme donc j'aimerais mettre un peu de Poo dans mes programmes si c'est possible.

merci pour vos explications

falke

omc · Le 03/07/2011, à 17:58

Quand tu as besoin de stocker des données (attributs) et de les manipuler (méthode),
la POO peut alors être utile.
Je ne peux plus m'en passer !

Bousky · Le 03/07/2011, à 18:49

D'un autre côté j'ai rarement vu de programme qui ne manipule pas de données

Si tu as plusieurs « choses » qui partages certaines « caractéristiques » communes, le mécanisme d'héritage de la POO est très utile.

Rafbor · Le 03/07/2011, à 20:41

falke a écrit :

dans quel cas de figure convient-il mieux d'utiliser la programmation objet

A partir du moment ou le langage que tu utilises le permet: toujours.
Cela doit devenir un réflexe, il faut raisonner 'objet', et répartir les traitements dans des classes dédiées.
Par exemple, il faut toujours séparer la classe qui traite les actions utilisateurs dans l'IHM, de celle qui traite les impacts sur les données. Par exemple:
une classe 'Voiture' avec une méthode publique 'OuvrirPorte()'

public class Voiture
{
    public void OuvrirPorte()
    {}
}

dans l'IHM, un bouton 'm_btnOuvrirPorte', un objet 'm_Voiture' et une méthode 'OnBtnOuvrirPorte_Clicked()' pour gérer l'évènement clic sur le bouton

public class MainWindow
{
    protected Voiture m_Voiture;
    protected Button m_btnOuvrirPorte;

    // constructeur
    public MainWindow()
    {
        // instanciation des 2 objets
        m_Voiture = new Voiture();
        m_btnOuvrirPorte = new Button();
    }

    // action du bouton 'Ouvrir Porte' dans l'IHM
    protected virtual void OnBtnOuvrirPorte_Clicked()
    {
        // appel de la méthode 'OuvrirPorte' de la classe Voiture
        m_Voiture.OuvrirPorte();
    }
}

Ainsi, si tu as besoin de refaire ton IHM, pour passer en appli Web par exemple, ou simplement simuler l'ouverture des portes à partir d'un autre objet, ta classe 'Voiture' est toujours utilisable sans adaptations. Et la réutilisation des classes pour d'autres projets en sera facilité.

Ce n'est qu'un exemple des avantages de la POO, il y a plein d'autres: surcharge de fonctions et d'opérateurs, encapsulation, droits d'accès aux membres et méthodes de la classe, héritage, polymorphisme,...

grim7reaper · Le 03/07/2011, à 22:54

Rafbor a écrit :

falke a écrit :
dans quel cas de figure convient-il mieux d'utiliser la programmation objet
A partir du moment ou le langage que tu utilises le permet: toujours.

Ouais ou pas…
Oui, la POO c'est bien et c'est puissant mais faire de la bonne POO c'est pas à la portée du premier venu : le principe de responsabilité unique, le principe Ouvert/Fermé, le principe de substitution de Liskov, le principe de ségrégation des interfaces, le principe d'inversion de dépendance, la loi de Déméter, les Design Pattern, … j'espère que ça vous parle (au moins les 5 premiers qui sont les principes fondateurs de l'OO) sinon c'est pas de la POO que vous faites mais de la bidouille orienté objet.
Et puis bon, la POO c'est pas l'alpha et l'oméga de la programmation donc faut pas non plus en foutre partout et pour tout.

Rafbor a écrit :

Ce n'est qu'un exemple des avantages de la POO, il y a plein d'autres: surcharge de fonctions et d'opérateurs, encapsulation, droits d'accès aux membres et méthodes de la classe, héritage, polymorphisme,...

La surcharges de fonctions et d'opérateurs n'a rien à voir avec la POO (suffit de voir Java d'ailleurs : langage objet mais pas de surcharge des opérateurs).
Le polymorphisme n'est pas spécifique à l'OO, par exemple on retrouve du polymorphisme paramétré dans des langages fonctionnels pur comme Haskell.
Idem en ce qui concerne le polymorphisme de coercition, on le retrouve dans pas mal de langage non OO.
En revanche, ouais le polymorphisme par sous-typage est, il me semble, spécifique à l'OO.

Sinon pour répondre au sujet, bah apprends la POO (on doit sûrement trouver des cours/tuto sur Internet, le plus difficile étant d'en trouver des bons) et une fois que t'auras compris le truc je pense que ça te viendras naturellement d'en mettre quand ça peut être utile.
Y'a pas de règles toutes faites, ça serait trop simple

Dernière modification par grim7reaper (Le 03/07/2011, à 23:02)

omc · Le 04/07/2011, à 10:00

Coucou,

grim7reaper a écrit :

Oui, la POO c'est bien et c'est puissant mais faire de la bonne POO c'est pas à la portée du premier venu : le principe de responsabilité unique, le principe Ouvert/Fermé, le principe de substitution de Liskov, le principe de ségrégation des interfaces, le principe d'inversion de dépendance, la loi de Déméter, les Design Pattern, … j'espère que ça vous parle (au moins les 5 premiers qui sont les principes fondateurs de l'OO) sinon c'est pas de la POO que vous faites mais de la bidouille orienté objet.

Bigre, tu y vas fort !! Là tu es sûr que notre ami va fuir la poo !
Bhoo, faut pas exagérer, il y a quand même beaucoup de cas ou la conception de classes est quasi-intuitive...
Pas besoins de sortir tout le background théorique.

grim7reaper · Le 04/07/2011, à 11:28

omc a écrit :

Bigre, tu y vas fort !! Là tu es sûr que notre ami va fuir la poo !

Oui y a des trucs qui ne sont pas indispensable pour faire de 'lOO, comme les design pattern (ça évite juste de réinventer la roue). Mais les 5 premiers principes que je cite sont les fondements de l'OO donc c'est quand même, de mon point de vue, un prérequis.
Tu deviens pas mathématicien sans connaître quelques théorèmes, tu deviens pas écrivain sans connaîtres quelques figures de style, etc.
Alors pourquoi on pourrait faire de la POO sans connaître les principes de base ?
Je demande quand même pas un truc compliqué, si ?
C'est pas comme si je lui demandai de savoir implémenter une vtbl, comment fonctionne le name mangling ou ce qu'est le SFINAE (désolé je parle C++ car le Python c'est pas mon dada, m'enfin c'est juste pour l'exemple).

Nan parce l'idée que je vois souvent c'est : fout de la POO partout, c'est super simple (et à la mode !) et ça va rendre automatiquement ton code propre et fonctionnel sans que t'es besoin de trop te casser ma tête (ha, c'est magique la POO :]). Bah non, je suis désolé mais ça marche pas comme ça.
C'est comme tout, si tu veux bien te servir d'un outil il te faut un minimum de bagage théorique (et encore, là c'est rien : 5 pauvres principes).
Je veux pas le faire fuir, je veux juste éviter qu'il parte dans le mur et se mette à pisser des objets à tire-larigot avec une logique bancale derrière (comme j'en vois beaucoup faire).

omc a écrit :

Bhoo, faut pas exagérer, il y a quand même beaucoup de cas ou la conception de classes est quasi-intuitive...
Pas besoins de sortir tout le background théorique.

C'est pas "tout" le background théorique, c'est la base théorique nécessaire. Nuance.
Sinon on a vite fait de se retrouver avec du code à chier : inmaintenable, blindé de dépendances qui n'ont pas lieu d'être et rendent le code rigide et peu évolutif.
Parce que refaire ta hiérarchie de classes à chaque modif un tant soit peu importante ou faire des dérivations monstrueuses pour faire évoluer ton soft c'est pas de la POO mais de la bidouille.

Dernière modification par grim7reaper (Le 04/07/2011, à 11:29)

omc · Le 04/07/2011, à 14:05

grim7reaper a écrit :

C'est pas "tout" le background théorique, c'est la base théorique nécessaire. Nuance.
Sinon on a vite fait de se retrouver avec du code à chier : inmaintenable, blindé de dépendances qui n'ont pas lieu d'être et rendent le code rigide et peu évolutif.
Parce que refaire ta hiérarchie de classes à chaque modif un tant soit peu importante ou faire des dérivations monstrueuses pour faire évoluer ton soft c'est pas de la POO mais de la bidouille.

Ce que je veux dire c'est que beaucoup de gens ici ne sont pas professionnel, ils font de la programmation ludique.
Un petit prog par-ci par-là pour automatiser des tâches, des petits projets qui ne servent pas à grand chose
sinon de découvrir un language et de se perfectionner, etc.
On est loin des projets sérieux avec un besoin fort de maintenance, et d'évolutivité.

Aussi, je ne vois pas l'utilité de sortir les gros dossiers quand ils s'agit de découverte.
Bref, Enjoy !

grim7reaper · Le 04/07/2011, à 14:37

Oui je sais, mais c'est pas parce que t'es amateur que t'aime faire les choses à l'arrache.
Pour prendre un exemple sur ce forum, Pylade fait de l'info en temps qu'amateur (ce n'est absolument pas son domaine) et bah ça ne l'empêche pas de vouloir bien faire les choses.
C'est la même pour moi, mais dans d'autres domaines que l'info.

Et puis l'argument du "petits projets qui ne servent pas à grand chose", ça commence souvent comme ça mais il arrive que ça en intéresse d'autres et qu'ils veuillent le reprendre pour l'utiliser/l'adapter/l'améliorer et là c'est toujours plus sympa d'avoir un truc propre dès le départ.

M'enfin ce n'est que mon avis.

Bon on fait un peu du HS là ^^"

JoelS · Le 04/07/2011, à 15:09

omc a écrit :

...
Un petit prog par-ci par-là pour automatiser des tâches,

Ben dans ce cas, probablement que la POO n'amène pas grand chose. Probable aussi qu'elle rende la compréhension future plus complexe.

omc a écrit :

...
des petits projets qui ne servent pas à grand chose
sinon de découvrir un language et de se perfectionner, etc.

dans ce cas oui, on fait de la POO, puisque le but, c'est de faire de la POO.

omc a écrit :

...
On est loin des projets sérieux avec un besoin fort de maintenance, et d'évolutivité.
Aussi, je ne vois pas l'utilité de sortir les gros dossiers quand ils s'agit de découverte.

Sortir non, mais il faut être juste au départ un peu conscient que c'est pas simplement parce qu'on écrit class ou extend quelque part dans son source qu'on fait de la POO.

falke · Le 04/07/2011, à 19:54

grim7reaper a écrit :

Oui je sais, mais c'est pas parce que t'es amateur que t'aime faire les choses à l'arrache.
Pour prendre un exemple sur ce forum, Pylade fait de l'info en temps qu'amateur (ce n'est absolument pas son domaine) et bah ça ne l'empêche pas de vouloir bien faire les choses.
C'est la même pour moi, mais dans d'autres domaines que l'info.
Et puis l'argument du "petits projets qui ne servent pas à grand chose", ça commence souvent comme ça mais il arrive que ça en intéresse d'autres et qu'ils veuillent le reprendre pour l'utiliser/l'adapter/l'améliorer et là c'est toujours plus sympa d'avoir un truc propre dès le départ.
M'enfin ce n'est que mon avis.
Bon on fait un peu du HS là ^^"

à grim7reaper

je comprends ton point de vue: ce n'est pas parce qu'on est amateur qui faut faire des choses pas propres. Ceci dit mm les 5 points de bases que tu cites sont impressionnants de mon point du vue.
Pour l'instant j'ai fait des programmes pour des traitements batch. avec de belles boucles :-) J'ai seulement une représentation intuitive de ce à quoi pourrait servir la POO.
n'est elle pas utile dès qu'il faut prévoir de programmer des interactions entre des entités concrètes ou abstraites . Oh là je raconte peut-etre une grosse connerie. et aussi n'est elle pas très pratique pour créer ces entités facilement et en "masse".

bon tu vois mon niveau. En gros ma question si je n'ai pas d'interactions entre de quelconque entités dans mon prog est-il de concevoir mon projet en objet ?

merci

Rafbor · Le 04/07/2011, à 20:26

grim7reaper a écrit :

le principe de responsabilité unique, le principe Ouvert/Fermé, le principe de substitution de Liskov, le principe de ségrégation des interfaces, le principe d'inversion de dépendance, la loi de Déméter, les Design Pattern, … j'espère que ça vous parle

purée non, ça me parle pas du tout. Je viens de jeter un coup d'œil à mes cours d'info (niveau bac+2 de 2001) et aucun de ces thèmes n'est abordé. Aie aie aie, il va falloir que je me réabonne à Programmez! je suis largué... Est ce que la commande suivante peut me sauver ?

sudo apt-get my_brain_POO-upgrade

Sérieusement, mon job consiste essentiellement à maintenir et faire évoluer une grosse appli codée fin des années 90 en Cpp par plusieurs SSII. Concernant l'architecture objet de la chose, pas de soucis, c'est bien pensé, et mes collègues et moi (3 au total) nous appuyons dessus. Et peut être appliquons nous sans le savoir, les principes cités.

Pour les projets plus récents que j'ai développé seul, je fais de mon mieux pour coder proprement, en C#, et en appliquant ce que j'ai appris. S'ils avaient été pensés par un codeur de plus haut niveau que le mien, leur architecture aurait surement été différente... ou pas, car avec un douzaine de classes chacun, ces petits projets sont faciles à implémenter.

omc · Le 04/07/2011, à 21:02

En fait, je pense qu'il y a deux points de vue et deux pratiques.
La première est académique et c'est ce que propose grim7reaper, apprendre la théorie, les fondements etc...
La deuxième est une approche par expérience ou l'on préviligie tout de suite le ludique.

Je suis plutôt adepte de la deuxième, elle permet de comprendre par la pratique, et surtout de faire des erreurs !
codage → problème → théorie → codage
C'est de l'apprentissage agile

grim7reaper · Le 04/07/2011, à 21:25

falke a écrit :

Ceci dit mm les 5 points de bases que tu cites sont impressionnants de mon point du vue.

Ils sont plus impressionnants qu'ils en ont l'air , et puis ça rentre pas trop mal avec un peu de pratique (vouloir apprendre la prog sans pratique c'est vain de toutes manières)

falke a écrit :

Pour l'instant j'ai fait des programmes pour des traitements batch. avec de belles boucles :-)

Si c'est juste des petits programmes, la POO va t'apporter plus de complexité que de confort.

falke a écrit :

n'est elle pas utile dès qu'il faut prévoir de programmer des interactions entre des entités concrètes ou abstraites . Oh là je raconte peut-etre une grosse connerie. et aussi n'est elle pas très pratique pour créer ces entités facilement et en "masse".
bon tu vois mon niveau. En gros ma question si je n'ai pas d'interactions entre de quelconque entités dans mon prog est-il de concevoir mon projet en objet ?

Malheureusment, je n'ai pas une recette miracle ou une définition formelle (même si certains me trouvent très académique ).
Mais une chose est sûr, en deçà d'une certaines taille/complexité la POO fait perdre plus de temps qu'elle n'en fait gagner.
Je risque encore de parler d'un truc que tu ne connais pas, mais c'est comme le MVC : c'est très bien, puissant et propre mais c'est contre‑productif de le sortir pour de petites interfaces.

Rafbor a écrit :

grim7reaper a écrit :
le principe de responsabilité unique, le principe Ouvert/Fermé, le principe de substitution de Liskov, le principe de ségrégation des interfaces, le principe d'inversion de dépendance, la loi de Déméter, les Design Pattern, … j'espère que ça vous parle
purée non, ça me parle pas du tout. Je viens de jeter un coup d'œil à mes cours d'info (niveau bac+2 de 2001) et aucun de ces thèmes n'est abordé.

Oui, les cours ont parfois tendance à passer à côtés de choses essentiels, la qualité de l'enseignement est très variable.
Si ça peut te rassurer, il y a beaucoup de notions que j'ai apprises seul (et non pas en cours).
C'est pour ça qu'il faut toujours garder un œil critique sur ce que l'on nous enseigne et ne pas hésiter à aller voir ailleurs par soi‑même.

Rafbor a écrit :

Aie aie aie, il va falloir que je me réabonne à Programmez! je suis largué...

C'est sûr que tu aurais tout à y gagner, c'est un excellent site.

Rafbor a écrit :

Et peut être appliquons nous sans le savoir, les principes cités.

C'est tout à fait possible, loin d'être improbable même.
C'est comme les Design Pattern : au moment où c'est sortie beaucoup de gens les utilisaient déjà, mais ils n'avaient pas encore mis de nom dessus.

Rafbor a écrit :

ou pas, car avec un douzaine de classes chacun, ces petits projets sont faciles à implémenter.

Oui, une douzaine de classe c'est vraiment peu.
À ce niveau là, le risque de faire de mauvais choix (et les conséquences de ces mauvais choix s'ils surviennent) seront, je pense, minimes.

omc a écrit :

La première est académique et c'est ce que propose grim7reaper, apprendre la théorie, les fondements etc...

Oulà, pas du tout.
Apprendre la prog sans pratique c'est rébarbatif et très peu efficace, du moins je pense.
Moi je propose juste d'acquérir un minimum de théorie avant de se lancer dans la pratique.
Comme quand, dans l'idéal, on apprend l'algorithmie avant de mettre en œuvre un langage.
Je ne renie absolument pas le côté pratique, ce serait totalement stupide car on apprend beaucoup en faisant des essais (et surtout des erreurs).

omc a écrit :

La deuxième est une approche par expérience ou l'on préviligie tout de suite le ludique.

Le risque étant de prendre de mauvaises habitudes, or il est très difficile de les perdre par la suite (je parle en connaissance de cause :-/).

omc a écrit :

Je suis plutôt adepte de la deuxième, elle permet de comprendre par la pratique, et surtout de faire des erreurs !
codage → problème → théorie → codage
C'est de l'apprentissage agile

Et bien moi c'est plutôt :
théorie (le minimum requis) -> problème concret -> codage -> prise en compte des erreurs -> retour à l'étape 1

Bousky · Le 04/07/2011, à 21:32

Chez moi c'est plutôt :
problème tout simple → « Et si je le résolvais avec un truc bien compliqué codé dans un langage que j'ai jamais utilisé ? » → tuto → codage → plantage → google → théorie → refactoring réécriture depuis zéro → plantage → …

Dernière modification par Bousky (Le 04/07/2011, à 21:35)

omc · Le 04/07/2011, à 22:33

Bousky a écrit :

Chez moi c'est plutôt :
problème tout simple → « Et si je le résolvais avec un truc bien compliqué codé dans un langage que j'ai jamais utilisé ? » → tuto → codage → plantage → google → théorie → refactoring réécriture depuis zéro → plantage → …

:-]
Formidable, on est tous d'accord alors !
Big-up à grim7, avec qui ont peut causer et même charrier un peu sans que ça pourrisse l'ambience.

Si je peux me permettre une modeste conclusion (de normand) le choix du paradigme de programmation
c'est quand même une affaire de goût, de style et d'habitude.

Ben... ça fait pas avancer le schmilblick...

Bousky · Le 05/07/2011, à 19:27

omc a écrit :

Si je peux me permettre une modeste conclusion (de normand) le choix du paradigme de programmation
c'est quand même une affaire de goût, de style et d'habitude.

J'ai envie d'ajouter : si tu fais ça pour t'amuser / apprendre, choisis soit quelque-chose que tu veux approfondir, soit quelque-chose à l'opposé de ce que tu fais habituellement.

Haleth · Le 13/07/2011, à 21:34

public class Voiture
{
    public void OuvrirPorte()
    {}
}

L'interêt de cette classe ? Aucun.

Fait plutôt une fonction.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/07/2011, à 19:00

Quand faut-il utiliser la programmation objet ?

#2 Le 03/07/2011, à 17:58

Re : Quand faut-il utiliser la programmation objet ?

#3 Le 03/07/2011, à 18:49

Re : Quand faut-il utiliser la programmation objet ?

#4 Le 03/07/2011, à 20:41

Re : Quand faut-il utiliser la programmation objet ?

#5 Le 03/07/2011, à 22:54

Re : Quand faut-il utiliser la programmation objet ?

#6 Le 04/07/2011, à 10:00

Re : Quand faut-il utiliser la programmation objet ?

#7 Le 04/07/2011, à 11:28

Re : Quand faut-il utiliser la programmation objet ?

#8 Le 04/07/2011, à 14:05

Re : Quand faut-il utiliser la programmation objet ?

#9 Le 04/07/2011, à 14:37

Re : Quand faut-il utiliser la programmation objet ?

#10 Le 04/07/2011, à 15:09

Re : Quand faut-il utiliser la programmation objet ?

#11 Le 04/07/2011, à 19:54

Re : Quand faut-il utiliser la programmation objet ?

#12 Le 04/07/2011, à 20:26

Re : Quand faut-il utiliser la programmation objet ?

#13 Le 04/07/2011, à 21:02

Re : Quand faut-il utiliser la programmation objet ?

#14 Le 04/07/2011, à 21:25

Re : Quand faut-il utiliser la programmation objet ?

#15 Le 04/07/2011, à 21:32

Re : Quand faut-il utiliser la programmation objet ?

#16 Le 04/07/2011, à 22:33

Re : Quand faut-il utiliser la programmation objet ?

#17 Le 05/07/2011, à 19:27

Re : Quand faut-il utiliser la programmation objet ?

#18 Le 13/07/2011, à 21:34

Re : Quand faut-il utiliser la programmation objet ?

Pied de page des forums