EN POO, en Java, comment adopter l'approche "Bottom-up" (vs "Top-down du procédural")?

Bonjour,

J'ai compris que la différence entre la programmation procédurale, comme avec le langage C, et la POO, comme avec Java est le fait que dans le premier cas on part d'une approche "top down" (du haut vers le bas -> on casse le problème général en plus petites parties)?.Mais en POO, comme avec Java, c'est l'inverse-> on part des éléments individuels (les classes je suppose) qui une fois mises les unes avec les autres forment le programme complet. Donc on parle de modules en POO.

Problème ,je suis fortement influencé par le procédural, et j'ai un cerveau plutôt de logique "top-down" (déductif?). En POO, j'arrive à voir comment ça fonctionne, mais pas forcément à bien organiser les différentes classes et méthodes entre elles pour former le programme final.
Plus précisément j'ai l'habitude de mettre mes méthodes principales dans une classe chapeau/classe de gestion ou sont situées les listes d'objets/tableaux pour être plus proche des données, mais est-ce forcément recommandable?
Avez-vous une méthodologie à me conseiller au niveau logique pour bien concevoir mes programmes en langage POO Java?

Merci.

Pfiou, vaste question...

J'ai pas l'impression qu'on fasse du bottom-up en Java... En fait, on continue souvent à réfléchir comme en procédural, tout en ayant une couche d'encapsulation supplémentaire: l'objet, qui permet de rassembler à un même endroit les données et les traitements qui manipulent ces données.

Par contre, là où la réflexion est un peu plus poussée, c'est dans l'identification de ces objets: quand et quoi créer. Comment les objets doivent-il dialoguer entre eux pour que 1) ils fassent ce que l'on veut et 2) ils soient suffisament flexibles pour résister (un peu...) aux changements inévitables qu'il faudra mettre en place lors des évolutions. Pour nous aider, l'OO ajoute quelques concepts très intéressants et puissant:

1) l'encapsultation. Les objets doivent cacher tout ce qui n'est pas légitimement accessible. Ils doivent se protéger contre les "attaques" du monde extérieur (en mode paranoïa, tout le monde me veut du mal donc je prévois l'imprévisible), vérifier la validité des mutations que les consommateurs tentent de lui soumettre, et garantir quelles que soient les conditions les invariants propres à l'abstraction courante (eg. un objet qui stocke une date de début et une date de fin, est responsable de garantir que la date de début soit toujours inférieure à la date de fin, et si quelqu'un tente de violer cette règle, alors l'objet doit générer une exception)
2) l'héritage. La capacité de "réutiliser" une base commune dans un objet fils, tout en permettant la personnalisation de ce qui doit l'être ainsi que l'ajout de fonctionnalités.
3) le polymorphisme. Le fait de permettre des traitements communs sur des objets différents, mais qui partagent une certaine mécanique - classe de base ou interface - (ex. tout traitement applicable à un "Fruit" sera applicable sans problème à une Pomme et à une Orange, même si "manger" une Orange implique de l'éplucher au préalable - même appel + type différent = comportement différent en fonction du type réel et pas du type référencé)

Ces 3 concepts de base sont les seules vraies différences avec le procédural. Après cela, les têtes pensantes (GoF, etc.) nous ont produits tout un tas de "Design Pattern", c'est à dire des manières d'agencer nos objets pour remplir des buts précis: notifier le monde de certains événements, garantir l'usage d'instances uniques, "décorer" les appels à des méthodes avec des comportements supplémentaires, créer des graphes d'objets cohérents facilement, etc.

Les patterns devraient souvent être étudiés dans le cadre de l'apprentissage de la POO. On les retrouve sous une forme ou une autre dans à peu près toutes les API Java qui sont à notre disposition, il est intéressant d'apprendre à les reconnaître.

;)

Merci Pill_S.

J'avais lu cet article très intéressant...Qu'en penses-tu?

http://durofy.com/10-major-differenc...en-c-and-java/

Moui, à part cette histoire de bottom-up vs top-bottom qui ne me plait pas tout à fait, c'est une introduction correcte.

Citation:

---

Envoyé par Pill_S

Moui, à part cette histoire de bottom-up vs top-bottom qui ne me plait pas tout à fait, c'est une introduction correcte.

---

Je suis assez d'accord avec Pill_S. Je ne vois pas ce que Java a de "bottom-up". Je trouve même que cela peut prêter à confusion et donner une mauvaise vision de Java.

Lorsque l'on développe en Java, on pense aux concepts manipulés qui nous servent ainsi à définir les classes, les packages. Puis on réfléchit à comment interagissent ces concepts entre eux ce qui nous sert ainsi à définir les opérations nécessaires et donc les interfaces, les squelettes de méthode. Et seulement enfin on écrit au sein des méthodes la mécanique pour le faire. Avec le résumé que je viens de faire de l'approche d'un développeur Java, je ne vois pas ce qu'il y a de "bottom-up".

en réalité je pense que l'approche pratique est sinusoïdale (ou en spirale).
On essaye de cerner les concepts plus précisément et quand on expérimente on s'aperçoit que la réalisation concrète remet en partie en cause notre modèle ... et c'est reparti dans l'autre sens ... jusqu'à que ces tressaillements soient négligeables.
(bon je trouve la comparaison C/java citée assez pipeau :aie: désolé)

Citation:

---

Envoyé par professeur shadoko

en réalité je pense que l'approche pratique est sinusoïdale (ou en spirale).

---

Quel beau mot. Moi j'appelle ça faire de la soupe et j'en fait tous les jours :D