Et doxygen ? Ça compile bien la documentation à partir de code, non ?Citation:
Envoyé par Bruno PICART
Version imprimable
Et doxygen ? Ça compile bien la documentation à partir de code, non ?Citation:
Envoyé par Bruno PICART
c'est là tout le problème de l'identité d'un "moule" ( ou entité) qu'est une classe ou une structure dans un langage de programmationCitation:
Envoyé par raphchar
Il faut que les noms des membres de la classe ou de l'entité soit suffisamment explicites sinon la personne qui reprend le code source risque de se perdre dans le dit code source
Ou alors il faut des conventions de nommage et des spécifications pour avoir une bonne lecture du code source
C'est exactement la même chose que pour construire une maison : il faut faire les plans de la maison selon des normes tout de même c'est le boulot des architectes
Sinon l'ouvrier sur le chantier ne saura pas lire les plans et va faire n'importe quoi :mouarf:
en principe la logique voudrait que dans un code source on ne déclare pas de méthode d'une classe setAgeCapitaine car un capitaine c'est un type/une propriété bien particulierCitation:
Envoyé par Pyramidev
Il faut déclarer une entité/classe humain/client/administré qui est bien plus "générique" que capitaine.
A moins que le capitaine ou haut-gradé présente un mode de gestion plus complexe qu'un autre genre..
donc si vous voulez déclarer une classe capitaine eh bien il faut le faire..mais ça complexifie le code et vous allez monter une usine-à-gaz
c'est comme si je crée une classe mouche puis une classe moustique alors qu'une classe insecte peut suffire pour définir les propriétés et les méthodes ( bref les comportements ) d'un genre.Faut voir...
L'intérêt de l'informatique c'est de pousser le niveau d'abstraction le plus haut possible et créer le plus de "généricité" possible.
Ensuite avec les mécanismes de la POO on peut descendre de niveau et créer des types particuliers notamment grâce à l'héritage.
Cependant faire générique c'est certainement un voeu pieu et je suis sans doute à côté de la plaque car dans un projet de logiciel informatique il faut faire de plus en plus spécifique
pour ce qui est de déclarer une fonction "afficher()" , déclarée "dans le vide" effectivement ça ne veut rien direCitation:
Envoyé par koyosama
Mais si c'est une méthode membre d'une classe ça sufit.
Si la classe s'appelle entite pas besoin de déclarer entite.afficher_entite() parce que là on a une redondance donc il faut déclarer entite.afficher()
Sinon pour la déclaration que tu donnes d'"afficher()" plus compléte l'intérêt de la POO ( je ne sais pas dans quelle techno tu est spécialisé) c'est notamment la surcharge...
Ah, je l'avais raté celui-là…
J'ai beau le relire, et je pense qu'on a réellement un problème de vocabulaire ('on' étant les développeurs). On n'arrive pas à se comprendre entre les "commentaires" et la "documentation" sachant que l'ensemble fait…*la "documentation". Le dernier paragraphe de la première partie me laisse entendre que par "commentaires", il parle de tout ce qui est "documentation générée" des fonctions, méthodes, modules, classes… Dans ce même paragraphe, il parle bien d'inclure ces commentaires dans la documentation à l'aide des outils comme Shinx, Javadoc et on peut déduire Doxygen. Et donc oui, les tutos sont dans la doc (sinon où ? ) et les docs des composants est inclue dans cette doc…Citation:
Envoyé par Matthieu Vergne
Finalement, il ne parle pas des "commentaires" et le message principal est bon.
Et bim, évidemment, qu'est ce que j'avais dit plus haut… :?Citation:
Sur la seule base de ce que tu donnes, un design fiable est une classe abstraite qui utilise une API spécifique à son traitement.
En fait, le plus "logique", c'est d'avoir des composants qui correspondent sinon au "métier", au moins aux notions manipulées. Et comme l'éternel problème est de connaitre l'âge du Capitaine, je ne vois pas l'utilité de définir un terme plus générique. On se fiche de l'âge d'un humain…Citation:
Envoyé par Mat.M
Justement non…*Si on a besoin de manipuler un Capitaine, c'est définir une classe générique qu'il faudra spécialiser qui complique tout.Citation:
donc si vous voulez déclarer une classe capitaine eh bien il faut le faire..mais ça complexifie le code et vous allez monter une usine-à-gaz
Heu…*Non… Enfin…*L'intérêt de créer le plus de généricité possible, c'est de produire une usine à gaz qu'à la fin on est le seul à comprendre et donc espérer ainsi conserver son poste en se rendant indispensable. Généraliser une notion qui n'en n'a pas besoin, c'est ce qui conduit à l'usine à gaz…Citation:
L'intérêt de l'informatique c'est de pousser le niveau d'abstraction le plus haut possible et créer le plus de "généricité" possible.
Heu je suis pas sûr là :roll: Il cite quand même 5 utilisations communes des commentaires et on sent bien qu'il s'agit de commentaires custom rédigés à la main, pas juste d'une hiérarchie de classes et méthodes auto générée.Citation:
Envoyé par martopioche
Après, que ces commentaires aillent dans une Javadoc, dans un wiki ou soient envoyés par la poste à ta grand-mère, ça n'a pas grand-chose à voir avec la choucroute malgré le deuxième paragraphe où l'auteur s'efforce de détourner le débat principal vers ce sujet.
Il ne faut pas forcément. Tout dépend du besoin. Ontologiquement parlant, ce que tu dis se justifie, mais ce n'est pas systématiquement nécessaire en pratique. Tout dépend de l'usage qui en est fait. Le générique permet la réutilisation, plus c'est générique et plus on pourra l'utiliser dans des contextes différents, mais ça impose un design qui ne permettra pas certaines optimisations. Après il y a deux approches : tu démarres générique et swap sur un design plus optimisé plus tard quand nécessaire, où tu design selon tes besoins actuels et fait plus générique plus tard si tu prévois une réutilisation ailleurs.Citation:
Envoyé par Mat.M
Pas du tout d'accord. On peut le faire mais ce n'est pas le but, ça a un impact de faire du générique. J'ai personnellement une vision orientée très générique, mais je participe à un projet de métaheuristiques où l'optimisation est importantes, et j'admets tout à fait que cette vision générqiue ne se justifie pas tout le temps. On touche justement aux ontologies, qui en informatique ne visent pas à identifier LE meilleur modèle conceptuel. On parle toujours d'un consensus entre les acteurs concernés, donc en fonction du métier et des besoins. S'il est vrai qu'il y a des ontologies fondamentales, style Dolce et la suite UFO, Dolce s'appuie sur une vision cognitive pour le Web sémantique, et si UFO vise l'universalité, je te met au défi de commencer à parler de substance individuals, trope individuals et events dans ton code. Ce sera peut-être très robuste, mais pas super compréhensible pour le codeur moyen. Faire du générique, ce n'est pas un vœu pieu, mais une question de besoin. Il s'agit de ne pas faire du tout générique ni du tout optimisé, ce serait là l'erreur.Citation:
Envoyé par Mat.M
peut-être ai-je été mal compris..Citation:
Envoyé par martopioche
si on a une classe Capitaine,matelot et sous-officier au lieu d'une classe militaire avec la propriété grade ça fait 3 classes au lieu d'une donc ça fait plus de code , non ?
A moins que cela soit pertinent d'avoir ces 3 classes
Quelque part je voulais parler de subsomption
je suis parfaitement d'accord et merci pour les liens donnés sur WikipediaCitation:
Envoyé par Matthieu Vergne
Je me vois mal parler d'ontologie dans un projet en entreprise on va me regarder bizarrement; à moins de faire de la recherche en traitement de l'information dans un établissement genre INRIA :mouarf:
oui mais qu'est-ce qui relève du générique et qu'est ce qui relève du spécifique ? :aie: Zatize ze questionneuCitation:
Envoyé par Matthieu Vergne
sinon si on me permet une petite critique et un léger hors-sujet je ne vois pas trop comment on peut parler de "substance" dans du code informatique, Aristote peut-être en désignant ce qui fait l'âme humaine mais dans un code informatique ça me laisse très sceptique...si on peut m'expliquer
C'est ça le problème des Américains et du monde dans lequel on évolue c'est que tout "concept" philosophique finit par être une marque déposé, un trademark
bon c'était juste une parenthèse...
Ça fait effectivement plus de code, mais je me demanderai avant tout pourquoi diable avoir créé une classe matelot et sous-officier pour manipuler un Capitaine et son âge…Citation:
Envoyé par Mat.M
Du générique, c'est du commun. C'est du code factorisé pour réutilisation. Si tu fais une bibliothèque, a priori tu cherches à couvrir un maximum de cas, et donc tu essayes de faire au plus générique pour éviter d'oublier des cas pertinents. C'est là que tu prend une approche top-down : tu pars de concepts généraux que tu essayes d'implémenter, en fournissant les outils nécessaires pour faciliter l'application à des cas spécifiques. Si tu ne cherches à développer que du code interne, là c'est avant tout du bottom-up : tu factorises du code existant. L'approche générique est utile aussi, car tu peux investir un peu plus de temps au départ pour en gagner par la suite, mais si tu ne maîtrises pas le domaine mieux vaut ne pas tenter le générique d'emblée, c'est prendre le risque de faire une oeuvre d'art théorique sans intérêt pratique (un paquet de mes projets persos sont comme ça, c'est sympa pour réfléchir et se faire la main, mais à part ça...).Citation:
Envoyé par Mat.M
J'ai une série de posts en préparation sur la programmation générique, mais je sais pas trop quand ça sortira (c'est plus de l'ordre du bouquin que du 2-3 posts). M'envoyer un MP pour accéder aux brouillons.
salut Matthieu ok donc ce qui est générique c'est ce qui est commun..
mais pour jouer les casse-pieds et couper les cheveux en 4 , selon la définition de l'ontologie informatique sur Wiktionnaire ( par distinction avec l'ontologie philosophique, mon domaine de prédilection :mouarf:)
qui dit graphe dit hiérarchie de concepts à minima , donc qui dit hiérarchie dit se fixer des absolus ( comme en philo ça peut-être l'âme , la conscience la raison),moi j'aimerais bien savoir comment déclarer des "absolus" dans un programme informatique.Citation:
(Informatique) Ensemble structuré de concepts, eux-mêmes organisés dans un graphe dont les relations peuvent être des relations sémantiques ou des relations de composition et d’héritage (au sens objet).
C'est là la problématique puisque un programme informatique composé essentiellement de code a pour finalité de traiter des données.
Or ces données provenant d'une abstraction décrivent un monde infini.....si je suis trop casse-pied qu'on me le dise :aie:
Dans un programme de compta par exemple est-ce que en haut de la hiérarchie c'est le client,l'entreprise ?
Perdu. Qui dit arbre, dit hiérarchie, et encore ça peut se discuter. Un arbre est un type de graphe, mais tous les graphes ne sont pas des hiérarchies. Prend des relation d'extension (is a) et oui tu fera une hiérarchie, en l'occurrence un arbre. Maintenant prend des relations de composition (has a) et tu pourras tout à fait avoir des relations circulaires (déconseillées, mais formellement autorisées). Prend des relations d'égalité (equals) ou toute autre relation symétrique, et là y a plus de hiérarchie, tout au plus des clusters. Tout dépend du type de relation que tu prends. Et en général, une ontologie qui se respecte n'a pas qu'un seul type de relation.Citation:
Envoyé par Mat.M
Maintenant, si tu prends des relations hiérarchiques, style is a, ça ne veut pas dire pour autant que tu traites d'absolus. Il s'agit d'établir un modèle conceptuel qui correspond au contexte, et que les gens pourront utiliser de manière pratique. S'ils se sentent bien avec des considérations philosophiques, tu peux inclure des concepts philosophiques si tu veux, mais je doute que ce soit la norme. En entreprise, on fait rarement de l'ontologie fondamentale, celle-ci ayant justement vocation à être générique et donc à traiter plus que ce qu'un contexte particulier nécessite. Si tu en fais une dans un contexte d'entreprise, tu y mettras avant tout des concepts qui correspondent au métier et aux habitudes de l'entreprise. Tu pourras les raffiner au fur et à mesure des besoins et des incohérences que tu pourras identifier, mais ça restera dans un objectif pratique, car à la fin les concepts doivent être utilisés, sinon ça rajoute juste à la charge de travail et à la complexité du modèle. En l'occurrence, si tu introduis un concept X, et que tu te dis que ce concept est un type particulier d'un concept plus général Y, tu as donc "X is a Y". Pour autant, Y ne sera utile que si tu as déjà ou si tu estimes avoir besoin d'autres concepts Y différents de X. Sinon tu ne fais qu'introduire de la complexité supplémentaire.
Après, si tu veux discuter de ça plus en détails, je t'invite à créer un autre sujet, parce qu'on part un peu hors sujet.
salut oui je suis parfaitement d'accord.Citation:
Envoyé par Matthieu Vergne
Un système structuré comme un graphe genre Djikstra n'a pas vraiment de hiérarchie car on part d'un noeud vers un autre.
Mais mon message n'a pas vocation d'entrainer un débat il a plutôt but de se poser des questions sur l'ontologie dans un code source..est-ce que cela a du sens ?
oui c'est ce que j'ai pensé faire...:D tu as raison on ne va pas continuer sur le sujetCitation:
Envoyé par Matthieu Vergne
Bien sûr. L'ontologie représente ton domaine, et donc des concepts pertinents à utiliser pour traiter des informations de ce domaine. Ce n'est pas l'ontologie elle-même que tu vas retrouver dans le code, mais tu peux l'utiliser pour identifier les classes pertinentes à implémenter. Ce n'est pas nécessaire, et ce n'est pas parce que tu as une ontologie que tu dois t'y restreindre, mais c'est une ressource de conception tout à fait utilisable.Citation:
Envoyé par Mat.M