Vers la modélisation

PYTHONIC

Ce cours utilise le langage Python comme langage pour introduire les concepts de la programmation orientée objet. Nous avons proposé du code qui respecte les préconisations le la PEP8. Il faut cependant garder en tête que python est un langage multi-paradigme, et qu’il existe de nombreuse façon de coder avec python en mettant plus ou moins en oeuvre tel ou tel concepts de la programmation orientée objet. Si vous voulez progresser en python, soyez curieux de ce que l’on trouve dans les PEPs (Python Enhancement Proposals) (https://www.python.org/dev/peps/)

Python est souvent critiqué pour son manque de performance dû au fait qu’il soit un langage interprété. Si vous vous reportez au cours de PRC de Fabrice Harrouet, vous trouverez comment faire appel à du code compilé C++ depuis python. Ainsi, en faisant appel à du code compilé pour les calculs critiques, on peut rendre du code python assez performant. C’est notamment ce qu’il se passe quand vous utilisez un bibliothèque de calcul scentifique comme numpy .

Python est aussi pour l’extrême souplesse de son duck-typing que python est apprécié (on branche n’importe quoi à n’importe quoi d’autre et ça fonctionne!). Même si dans les faits toutes les vérifications ont lieu dynamiquement, ce duck-typing revient strictement à la même démarche que le polymorphisme statique : il faut que le type qu’on utilise effectivement pour le traitement ait les bonnes propriétés, peu importe d’où il vient, pas besoin d’hériter d’une classe particulière qui devait être connu à l’avance.

CRITIQUE

Nous l’avons au travers des exemples de ce cours, les accesseurs sont souvent amenés à recopier les informations auxquelles ils permettent d’accéder pour ne pas ruiner l’encapsulation. Cette recopie est coûteuse s’il y a beaucoup de donnée et parfois, s’il s’agit d’association en classe, cela peux conduire à des mécanisme de recopie en profondeur (deepcopy) assez lourds à mettre en oeuvre. Finallement, par facilité ou besoin de performance beaucoup de programmes objets contiennent des failles d’encapsulation énormes. La première critique est donc la suivante : “la programamtion orienté objet prétends faciliter l’encpsulation mais l’observation des codes réalisés montre que c’est faux”

interface Ensuite, polymorphisme dynamique: - graphes heritage , topologie -

L’héritage qui est nécessaire au fonctionnement du polymorphisme dynamique introduit un très fort couplage structurel entre les composants, ce qui impose de très fortes limitations sur la possibilité de réutiliser le code dans un autre contexte (sans embarquer énormément de dépendances) ainsi que sur celle de le faire évoluer (sans tout casser ce qui en dépend). D’ailleurs, même Gosling (c’est dire !) dit qu’il ne faudrait pas d’héritage mais juste des interfaces pour limiter quelque peu (mais pas complètement) ce problème (ce qui ne règle pas non plus la question de performance, mais c’est un autre sujet). [ https://www.javaworld.com/article/2073649/why-extends-is-evil.html ]

Le ducktyping de python revient au polymorphisme statique

SOLID

Si la programamtion orienté objet n’est la solution utilme pour produire du code éfficace, elle demeure un paradigme intéressant pour le développement en équipe. La réutilisabilité du code Elle permet

UML et design pattern

Pour la suite du semestre, nous nous interesserons à la modélisation des programmes orientés objet. Nous utiliserons UML (Unified Modeling Langage). UML permet notamment une représentation graphique des classes et de leur relations dans un programme. Il devient alors plus facile de vérifier que les concepts de l’approche SOLID sont appliqué. On peut aussi détecter des incohérences, redondance, etc...

Excercices de synthèse

à faire