Formation Conception et Programmation objet

Travaux Pratiques d'introduction programmation et conception objet Un TP évolutif, de la conception du modèle objet à la mise en oeuvre (assistée), en passant par la maintenance, permettra de progressivement prendre la mesure de l'intérêt de l'approche objet. Nous nous appuyons sur un système de gestion (simplifiée) des demandes de formation au sein d'un département de ressources humaines. De la programmation structurée vers la programmation objet Bien comprendre les limites de la programmation structurée
Les objectifs du monde Objet
En quoi l'approche objet facilite-t-elle les ateliers de développement logiciels ?
Que reste-t-il de la programmation structurée dans la programmation objet ? Travaux PRATIQUES Sur la base d'un programme simple l'intervenant commente les grandes lignes du logiciel, les structures de données et les traitements utilisés (volontairement limités). Les participants sont amenés à répondre à certaines questions concernant la lisibilité des traitements, des variables, et sur l évolution du logiciel. Les limites de la programmation classique sont volontairement amplifiées afin d'être clairement identifiées. Apprendre à concevoir des classes d'objet Définir un comportement commun au sein d'une classe
Comment « reconnaître » une classe ?
Savoir faire un effort d'abstraction et rester conceptuel
Liens entre classe et objets (instance)
Exemples de « mauvaises » classes
Savoir définir un dictionnaire de données
Et en extraire les attributs d'une classe
Savoir recenser les états d'un objet
L'origine et la fin d'un objet (constructeurs, destructeurs)
Définir les traitements dans des méthodes
Que deviennent les fonctions traditionnelles ?
Les risques de « retomber » dans le modèle données/fonctions Travaux PRATIQUES« Re-conception » objet de l'application précédente.
Elaboration du dictionnaire de données, des traitements, et des flux.
Conception des classes Visibilité entre les objets Qu'entend-on par encapsuler les données ?
Pourquoi utiliser des accesseurs ?
Voir les objets comme « responsables » de leur comportement
Visibilité des attributs entre les objets (publique, protégé, privé)
Visibilité des méthodes Liens entre les classes La puissance de l'héritage
Réflexions sur l'héritage multiple
Ne pas confondre composition et héritage
Intérêt du polymorphisme
La surcharge des opérateurs
Appels de méthode d'une autre classe (message) Travaux PRATIQUES Evolution de la conception vers un modèle de hiérarchie des classes.
Conception de l'encapsulation des traitements. Compléments sur la conception objet Qu'est-ce qu'une méthode virtuelle ?
Et une classe abstraite ?
Intérêts des classes abstraites sans implémentation (interface)
S'appuyer sur une manière de faire éprouvée (design-patterns)
Exemples de design patterns Travaux PRATIQUES Amélioration du modèle précédent avec l'utilisation de classes abstraites Introduction à la modélisation objet avec UML UML (Unified Modeling Language) ne représente pas une démarche mais un formalisme
Les deux types de vue (statiques, dynamiques)
Tour d'horizon des différents diagrammes UML
Modélisation d'une classe
La visibilité des attributs (publique, protégé, privé)
Les diagrammes d'objet (attributs, méthodes, identité)
Synthèse sur les diagrammes liés aux vues dynamiques Travaux PRATIQUES Formalisation avec UML du diagramme de classes de notre application. Premiers pas en Java et en C# Définir une classe et ses méthodes
Manipuler simplement les objets
Messages simples entre objet
Mise en oeuvre de l'héritage (classe prédéfinie et propre classe) Environnement de développement intégré (IDE an anglais) Les fonctions d'un IDE attendues par le développeur
Les spécificités d'un IDE pour un langage objet
L'exemple de Visual Studio (Microsoft)
Les raisons du succès d'Eclipse Travaux PRATIQUES. Implémentations des classes précédentes en Java sous Eclipse et en C# sous Visual Studio.
Le code (simple car il ne s'agit pas d'un cours sur ces deux langages) est fourni aux participants Tests d'utilisation des classes. Utilisation des concepts purement objet au sein des deux environnements (browser de classes, héritage, encapsulation et accesseurs, ...). Frameworks et architectures réparties (.net, JEE) S'appuyer sur un Framework pour construire une application
Mais un Framework ne fait pas tout ...
Complexité des architectures réparties
La réponse des frameworks objets comme .Net ou JEE
Encourager les développeurs à utiliser le modèle MVC
L'exemple du framework Struts pour les applications Java Travaux DIRIGES L'objectif est de comprendre en quoi notre conception précédente (classes personne, formation, prestataire, ....) n'est pas impactée par la présentation des données ni par l'architecture (web ou locale). Pour cela nous mettons en oeuvre notre application dans un contexte WEB en respectant le modèle MVC. Les participants retrouvent leurs classes « telles quelles » mais dans un autre contexte (WEB). On leur présente les principales classes utilisées dans cette mini application et ils deviennent intégrateurs « d'objets » ce qui permet de faire cohabiter les objets « autonomes » qu'ils ont conçus et ceux proposés par le framework profitant pleinement ainsi de leur approche objet.