Au sujet de la POO

[Just-Soft]

Salut;
Malgré mais maintes tentatives j'ai pas réussi à trouver un bon tutoriel mettant en exergue la puissance de la programmation orientée objet et l'exploitation d'une base de données.

Si jamais quelqu'un pouvais m'orienter dans ce sens je serais très reconnaissant.

Merci de m'avoir lu.

[MaliciaR]

Envoyé par Kelloucheaeh

Salut;
Malgré mais maintes tentatives j'ai pas réussi à trouver un bon tutoriel mettant en exergue la puissance de la programmation orientée objet et l'exploitation d'une base de données.

Si jamais quelqu'un pouvais m'orienter dans ce sens je serais très reconnaissant.

Merci de m'avoir lu.

Je ne comprends pas quelque chose : un tuto est fait pour t'apprendre à faire quelque chose de précis. Pas pour te donner des bases théoriques générales. Donc, si tu n'as pas trouvé ce que tu cherchais, c'est peut-être parce que tu n'as pas cherché dans les endroits les plus appropriés

Mais sinon, regarde du côté des cours généraux disponibles ici : il y en a plein, très clairement rédigés, où tu as des chances de trouver ton bonheur. En tout cas, ta question est beaucoup trop générale pour moi, donc c'est la seule réponse que je puisse y apporter

[Just-Soft]

Re;
je précise, j'ai besoin d'une étude de cas.

En théorie y a pas à se plaindre je ne dis pas que je suis le meilleur mais je comprends en règle général la POO.

[MaliciaR]

Envoyé par Kelloucheaeh

Re;
je précise, j'ai besoin d'une étude de cas.

Beh... Normalement, on t'en donne plein dans les bouquins J'en avais trouvé un ici, "Les bases de l'informatique et de la programmation", où c'est bourré d'exemples (Delphi et autres) et il y a des exos résolus et commentés. Je ne vois pas mieux que ça Et je pense que tu dois pouvoir un truc équivalent dans le domaine précis qui t'intéresse.

[Jimalexp]

Plus de précisions seraient le bienvenu.

Comme tu le sais la POO est avantageux au niveau de la modélisation et de la maintenance.

Le couplage avec une base de données relationelle se révele intéressant lorsqu'il y a une grande quantités d'informations à gérer. Les serveurs SQL et Oracle permettent d'exploiter éfficacement la mémoire vive mais aussi la mémoire de masse.

C'est d'ailleurs un choix imposé à partir du moment où l'on considère la mémoire vive comme finie et la quantité d'informations à gérer virtuellement infinie ou proportionellement tellement grande qu'on dois se limiter à se focaliser sur une fraction des éléments qui la compose.

Bien sur, il est courant que la base de données existe déjà, un projet étant destiné à tout simplement moderniser le logiciel de gestion.

Exemples:
- La gestion de comptes d'une banque où on peut retrouver des milliers de clients.
- Un jeu de rôle avancé où il y a beaucoup de statistiques et d'interdépendances à gérer.

[Garulfo]

Envoyé par Jimalexp

Comme tu le sais la POO est avantageux au niveau de la modélisation et de la maintenance.[...]
Exemples:
- La gestion de comptes d'une banque où on peut retrouver des milliers de clients.
- Un jeu de rôle avancé où il y a beaucoup de statistiques et d'interdépendances à gérer.

Ça n'a jamais été démontré clairement que la POO était vraiment avantageuse d'une manière claire et précise sur tout type d'application.

D'ailleurs je ne vois pas en quoi les exemples que tu donnes serais « mieux » en POO honnêtement, notamment le deuxième qui fait intervenir de nombreuses formules mathématiques et se modèlisent très simplement par une « grosse fonction mathématique » et, de facto, par un programme procédural. Personnellement, je partirais avec une conception procédurale a priori.

[Jimalexp]

Je reformule.

L'OO est clairement avantageux par rapport au procédural en terme de maintenance pour les applications de gestion. De un, la conceptualisation est plus proche du mode de pensé humain (une pomme est une pomme, et pas un ensemble de séquences et de fonctions collé avec de la superglue). De deux, il est possible pour plusieurs personnes de travailler en parallèle sur les objets de leur choix sans que cela engendre de fortes modifications dans l'ensemble d'un programme.

C'est pour ca que les langages OO ont la côte pour l'instant. Fini les monstreux listing en Cobol ou en Fortran où on pouvais s'y perdre pendant des jours. Chacun peut travailler en se concentrant sur sa partie d'un projet sans déranger les autres.

Maintenant, il est clair que l'OO n'est pas adapté à l'informatique industrielle où la performance est de mise et un écart d'une fraction de seconde peut signifier qu'une personne perds son bras dans une châine de production ou le crash d'un train à haute vitesse.

Sinon les exemples que je cite sont justement des cas de figure ou l'OO fait défaut, imposant le recours à l'outil spécialisé qu'est la bases de données relationelle.

Je m'explique. Comme les langages comme Java font une totale abstraction au niveau de la gestion mémoire il n'est pas possible d'intercaler un petit artifice qui permettrais de gérer un grand nombre d'informations.

En clair, si on tente d'assimiler l'entierté des informations contenues dans une base de données d'une certaine taille on va heurter à un certain moment la limite physique imposée par la quantité de mémoire installée sur un ordinateur.

Même si l'OS fais passer des informations en mémoire paginée, cette manière de gérer les choses est tout à fait inéfficace vu qu'on a pas besoin d'accéder à l'ensemble des informations sauf dans des applications spécifiques.

Et c'est là que les bases de données relationelles brillent par leur efficacité vu que la gestion des informations ne se fais pas au niveau binaire mais au niveau logique. SQL et autre sont optimisés de sorte qu'une requête sur un grand ensemble d'enregistrements prenne un minimum de temps (tables lookup transparentes, caching, algorithmes de prédiction ou d'anticipation ?) alors qu'en OO une recherche entre instances est le plus souvent limité au parcours d'une liste châinée.

[el_slapper]

ayant tendance à faire de l'informatique de gestion, avec un nombre de données monstrueuses, et des contraintes de performances fortes, je me trouve aux confins de toutes ces exigences.....Bon, ma partie c'est Cobol, donc pas d'objets, j'ai pas le choix. Parfois ça manque. Parfois non.

Le SQL, c'est bien, mais ça reste couteux en termes de temps d'accés. Pour l'enorme batch qu'on est en train de mettre en place(qui doit générer des millions de courriers hyper-personalisés en une seule nuit), nous allons utiliser un mix de Cobol, de SQL, de déchargement de base SQL vers des fichiers plats, de tris, et avec en bout de chaine une conversion XML pour traitement en JAVA des courriers obtenus(générés en PDF pour pouvoir être réimprimés à la demande).

Ce que je veux dire par là, c'est qu'il faut s'abstenir de discours idéologiques du genre "l'objet, c'est mieux", ou encore "les nouvelles technos, c'est pas fiable et c'est lent". Chaque manière de procéder possède ses propres points forts, et face à un problème nouveau, la pire des solutions est de se dire "se maitrise le langage K et la méthode W, donc ce sont les solutions les mieux adaptées".

et quand je lis que le COBOL ne permet pas de travailler à plusieurs, eh bien désolé, c'est une question de conception. Nous avons 9 types principaux de courriers, avec 12 pavés possibles standardisés - donc nous avons 21 modules de base pour la composition du courrier. Plus des éléments séparés pour la collecte des données, plus encore d'autres pour divers trucs techniques.....Tout celà permet de bosser à plusieurs, pourvu que l'on standardise les signatures d'appel aux modules. En JAVA aussi on peut faire une énorme bouse illisible..... D'ailleurs, j'ai des collègues javaïstes en train de maudire le concepteur de leur application, là, juste à coté, en ce moment.....

Je ne crache pas sur l'objet, j'en utilise en dehors de mon travail principal(pour lequel je n'ai pas le choix). Simplement, c'est aussi un mode de pensée qui a ses limites.

[ndp]

Envoyé par el_slapper

...Chaque manière de procéder possède ses propres points forts, et face à un problème nouveau, la pire des solutions est de se dire "se maitrise le langage K et la méthode W, donc ce sont les solutions les mieux adaptées"...

+1 entierement d'accord avec toi.

« Si le seul outil que vous avez est un marteau, vous verrez tout problème comme un clou » Maslow

[Jimalexp]

Chouette intervention el_slapper. Il y a manifestement un monde entre la vision théorique des choses et les exigences du terrain (il est monstrueux votre projet ). Tu me pardonneras dans mes affirmations car j'ai repris les études et je nage encore en pleine théorie.

[Garulfo]

Envoyé par Jimalexp

Je reformule.

L'OO est clairement avantageux par rapport au procédural en terme de maintenance pour les applications de gestion. [...]

TU donnes ton avis. Ca ne saurait etre une preuve. Les avis des specialistes sont partages. On ne peut donc pas etre aussi tranché.

Sinon je te prierais de me montrer cette parution qui établit clairement ce lien sans doute possible. Je serais curieux de voir ce graal des tenants de l'OO.

[Luc Hermitte]

Envoyé par Jimalexp

Maintenant, il est clair que l'OO n'est pas adapté à l'informatique industrielle où la performance est de mise et un écart d'une fraction de seconde peut signifier qu'une personne perds son bras dans une châine de production ou le crash d'un train à haute vitesse.

C'est nouveau ça. La perte de perf dû à l'OO, ou encore son inadéquation à l'informatique industrielle.

PS: La majorité des langages mainstreams sont procédurals et parfois même OO. D'autres seront fonctionnels et éventuellement OO, ...

[el_slapper]

Envoyé par Jimalexp

Chouette intervention el_slapper. Il y a manifestement un monde entre la vision théorique des choses et les exigences du terrain (il est monstrueux votre projet ). Tu me pardonneras dans mes affirmations car j'ai repris les études et je nage encore en pleine théorie.

J'ai vu bien pire, comme projet. Après, il peut être parfois malin de prendre une technologie moins adaptée, mais qui permet de garder un certain standard. Mais dans mon cas précis, non, ça n'était pas souhaitable. D'autant que tout ce que j'ai évoqué tourne déjà sur site - donc rien de lourd à ajouter.

Par contre, j'ai vu un projet ou ils ont rajouté 2 technologies : MQseries et RdJ(un moteur de dispatchage des données). Ca donnait :
==>le gestionnaire extérieur des données travaille en Java. Il nous envoie des messages et des fichiers via MSeries. Mais certains fichiers, trop volumineux, étaient traités par Cobol et transfert CFT.
==>Un moteur mixé Cobol/MQseries gère les flux en temps réel, et dispatche l'essentiel des flux vers 72 applications de l'entreprise(je passe les détails, c'était pas ma partie, mais l'archi était horriblement complexe, avec allocation dynamique des fichiers en Cobol, un monstre)
==>Le flux principal est repris dans un programme Cobol de "contrôle et enrichissement"(35000 lignes, 71 referentiels SQL appelés) qui adapte les données au format de l'entreprise.
==>Le flux enrichi passe par RDJ pour être découpé en flux unitaires directement exploitables
==>certains flux unitaires passent par un post-traitement COBOL non réalisable par RDJ
Là, il y avait sans doute moyen de faire mieux. Sans compter qu'il y avait aussi quelques sources en C qui trainaient, sans compétences pour y toucher.....



La vision théorique, c'est bien. C'est même nécéssaire. Mais je vais faire une analogie militaire : "la planification ne sera jamais respectée. Pour autant, elle est totalement nécéssaire", et "aucun plan de bataille ne survit au contact avec l'ennemi". Dans le cas de l'objet, c'est un outil à double tranchant; il est très puissant, mais sa puissance échappe parfois à ses utilisateurs(un peu comme un lance-flammes, arme ultime, mais qui a tendance à exploser à la tronche de son manipulateur).

[Jimalexp]

Envoyé par Luc Hermitte

C'est nouveau ça. La perte de perf dû à l'OO, ou encore son inadéquation à l'informatique industrielle.

Je ne suis pas spécialiste. Je pourrais éventuellement inviter un ami à se prononcer sur la question.

[HanLee]

Dassault Systemes utilise pour ses logiciels de CAO (classiquement, CATIA) de la POO, et c'est bien de l'informatique industrielle...

Les voitures, les avions, les bateaux, le stade olympique de Beijing ont été conçus avec CATIA...