Discussion :

[hegros]

C'est vrai, si les profs ne sont pas a jour sur la matiere qu'ils enseignent, c'est la faute a la matiere.

J'aimerais bien voir un prof en medecine essayer cette attitude.

Ce n'est pas comparable avec la médecine...Un langage informatique est inventé de toute pièce, ce sont ses concepteurs qui décident de ses contours et qui définissent la matière. Le C++ se traîne le C c'est un fait ce qui augmente la confusion.


La médecine n'est pas une invention comme l'est un langage informatique on peut s'attendre chaque jour à un changement dans le fondamental (voir la découverte sur les cellules de sang et de tissu) chose quasiment impossible pour un langage informatique spécifié au départ.

Oui, le C++ est un langage complexe; personne ne le lie. Prendre pretexte de cette complexite pour excuser ceux qui n'enseignent pas les moyens de la maitriser, ca me semble assez ubuesque.

Il y a en tout cas un problème quelque part avec l'enseignement du C++ ou l'enseignement informatique en général.

[white_tentacle]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IFile *f= new ConcreteFile(); au lieu de ConcreteFile *f= new ConcreteFile(

alors je serais découpler de l'implémentation et je peux changer de librairies pour les files sans se poser de question si je trouve que la première libraire a des problèmes.

Sauf que une interface n'est pas un contrat, et qu'il y a toutes les chances que les conditions limites des différentes méthodes ne soient pas identiques.

Autrement dit, tu vas remplacer ta librairie par une autre sans te poser de questions, et ça va planter alors qu'avant ça marchait parce que le contrat n'est pas le même (typiquement, une fonction qui acceptait une valeur nulle dans l'ancienne lib, ne l'accepte pas dans la nouvelle).

Tu n'as pas arrêté de parler de contrats, les contrats sont pour moi une preuve flagrante de l'absence de bonne conception en java ou csharp :

• les contrats ne sont jamais documentés en java ou csharp (au mieux, on a du defensive programming avec exceptions documentées, c'est différent)
• le système de type lui même n'est pas contract-safe (array[b] dérive de array[a] si b dérive de a, ce qui est contraire au lsp).

Il n'y a pas de contrats en c# (plus tout à fait vrai, il y a des choses issues de spec# qui sont en train d'arriver), ni en java (pas nativement dans le langage).

En revanche, en c++, on a la STL, qui est une des rares lib d'envergure à documenter parfaitement ses contrats, et même ses contraintes de complexité. On a le nvi, qui permet au moins de faire des vérification au run-time des pré et post-conditions.

Non, il n'y a pas photo. Côté contrats, c'est la dèche chez tout le monde, mais chez c++ il y a au moins un peu à manger.

[Issam_Lahlali]

Pour moi, sur un tel aspect technique, cela n'a pas d'intérêt. On va se retrouver à donner le plus petit sous-ensemble commun à cette interface, LSP oblige, et donc perdre l'intérêt (à supposer qu'il y en ait un) d'utiliser un type autre que le standard. Et on devra continuer à jongler avec des bibliothèques qui pour d'obscures raisons continuent à proposer une alternative aux flux standards -- pour pouvoir profiter des services supplémentaire. Pas besoin de complexifier plus la situation.

Les interfaces à la Java sont une fausse bonne idée. Elles sous-exploitent les possibilités du langage, sans parler qu'un point de variabilité dynamique ne présente aucune intérêt sur une fonction qui va attendre une chaine ou un fichier.

Lorsque je parle de AbstractLib j'espère avoir un standard pas une nouvelle lib de plus comme l'OMG l'a fait pour l'aspect métier ou des contrats sont standarisés pour des domaines comme la finance ou autre.

et le fait qu'un developpeur c++ est noyé dans une multitude de librairies techniques c'est un fait, imaginant un developpeur c++ qui a bosser pendant 5 ans on n'utilisant que MFC( je sais c'est pouru) mais c'est encore utilisé et il change de boite et il découvre qu'ils utilisent QT alors il ne va pas exploiter au maximum son expérience puisqu'il doit réapprendre une nouvelle librairie.

Encore une fois on va me dire c'est valable pour les autres langages , mais les autres n'ont pas ce pb avec les librairies techniques.

et pour les interfaces qui soit disant n'ont pas d'interet , a ma connaissance ils ont un grand interet dans tout pattern ou le couplage faible est souhaité, et aussi pour définir un metier donné et c'est ce qui fait entre autre la puissance du SOA.

normalement on développe en général pour implémenter un METIER donné pas des librairies techniques ou peut être les interfaces n'ont pas un grand intérêt actuellement.

et lorsque je commence a concevoir un métier j'essaye de trouver les contrats du métier donc les interfaces et si les interfaces n'ont pas leur intérêt dans les couches technique ils ont une grande place dans la partie métier.

et c'est l'objet de la discussion on prend comme exemple ce qu'on fait dans la couche technique pour l'appliquer a la couche METIER en terme de conception et c'est ce qu'il faut éviter.

mon conseil aux débutants est le suivant:

- Penser METIER et puis METIER et puis METIER c'est la vrai valeur ajouté de votre projet.

- si vous trouver qu'une librairie technique est difficile a utiliser ne vous remettez pas en cause toute suite , mais critiquer la complexité et si vous avez le pouvoir de la changer n'hésiter pas avant qu'il ne soit trop tard, sinon essayer de faire abstraction a la complexité même si vous êtes obligés d'ajouter des wrappers autour de cette librairie.

- lorsque vous passer trop de temps dans la couche technique c'est qu'il y a quelque chose qui cloche , essayer de découvrir lequel et ne pas continuer tête baissé on se disant que c'est normal.

[Invité]

Et pour rectifier le point de vue qui a causer pas mal de critique , il n y a pas absence de bon concepteurs c++ mais la loi du marché et l'environnement ambiant fait qu'on a pas le temps de concevoir en entreprise, c'est vrai pour les autres langages mais ça se voit plus pour c++ pour les raisons évoquées auparavant.

Ma sensation est que ce problème n'est pas spécifique au C++ (même s'il se voit peut être mieux dans des langages techniques). La difficulté est double

1- la conception c'est très difficile, il faut beaucoup d'expérience, et l'expérience, dans des boites ou l'on explique qu'un jeune qui commence à travailler à 25 ans doit être chef de projet (cad non codeur) à 28, ca devient très très rare (l'expérience, c'est 10 ans de métier, pas 3)
2- sur un projet un rien sérieux et pressé par le temps (c'est à dire tous), il vaut mieux pas de conception qu'une conception mal pensée. Un programme sans conception d'ensemble sera toujours plus facile à remettre droit qu'un programme avec une conception erronée.

A mon avis, le problème de fond est lié au niveau, et tient probablement à la démocratisation de la fonction de programmeur. Beaucoup de jeunes informaticiens sont très mal formés (il leur manque beaucoup de bases, notamment en maths, mais parfois aussi en francais et en anglais), et les ingénieurs assez formés ne veulent plus faire d'informatique (parce que, honnêtement, c'est pas super valorisant, socialement)

Du coup, on manque cruellement de concepteurs, car on manque de seniors. Et du coup, on fait l'impasse sur la conception, parce qu'il vaut mieux pas de conception qu'une mauvaise. Et du coup, les jeunes informaticiens, n'ayant jamais eu d'expérience de ce type, savent de moins en moins ce que c'est (concevoir une appli, ce n'est pas faire de jolis dessins UML ou autres), et ainsi de suite...

Le drame, c'est que d'un point de vue un peu cynique, c'est un bon système. Les quelques artisans spécialisés qui développent bien gagnent très très bien leur vie, et les SSII spécialisées dans la vente de petits jeunes corrigeant les bugs d'autres petits jeunes, et réintroduisant les bugs que la génération suivante de petits jeunes viendra corriger, également.

Francois

[Issam_Lahlali]

En revanche, en c++, on a la STL, qui est une des rares lib d'envergure à documenter parfaitement ses contrats, et même ses contraintes de complexité. On a le nvi, qui permet au moins de faire des vérification au run-time des pré et post-conditions.

Raison de plus d'avoir le réflexe de contrats dans la conception du METIER qui pour moi est la priorité pour un développement.

[Aurelien.Regat-Barrel]

Hello,

J'ai pas tout lu mais j'apporte ma petite pierre à l'édifice.

Ce que j'ai compris de tes messages, c'est que tu es très préoccupé par l'abstraction, et souhaites la privilégier au maximum sur les détails techniques.

Si trop se focaliser sur la technique est une erreur, trop se centrer sur l'abstraction en est une autre. C'est simplement un juste équilibre - difficile à trouver. Car les deux notions sont liées (on abstrait de la technique). Bien connaitre les détails techniques permet de renforcer ton abstraction. On ne compte plus les design élégants qui reposent sur des astuces techniques bien trouvées.

pour revenir a l'idée de passer par interface et son intérêt dans un monde ou on a énormément d'implémentations.

imaginant qu'on a une classe abstract pure IFile qui contient les methodes :open,close,write,read,...

En C++, la classe fichier standard dérive d'une classe abstraite "flux" (et non fichier). On pourrait aussi fournir par exemple une implementation qui lirait un fichier via le réseau. Ca semble une bonne idée, mais ça ne l'est pas. L'abstraction a ses limites.
http://www.joelonsoftware.com/articl...tractions.html

Ainsi il y a l'autre extrême du "canon pour tuer la mouche" et qui consiste à sortir des usines à gaz pour résoudre des problème simples, au motif que c'est + objet, abstrait, etc... Ne pas truffer son code de déclarations d'interfaces en tous genres n'est pas forcément quelque chose de mauvais. Il me semble même que le "tout objet" est une erreur de conception assez répandue.

Et tôt ou tard, on en vient à étudier ce qui se passe sous la plomberie. Un débutant .Net ne met pas longtemps à entendre parler et même à devoir étudier le CIL, qui n'est rien d'autre que... du code assembleur ! "CIL", ça sonne abstrait, moderne, évolué, etc... mais en réalité c'est une régression en terme d'abstraction.

Je suis épaté par le nombre incroyables de concepts / outils / etc... des mondes Java et .Net. C'est fou tout ce qu'il faut apprendre et essayer. La complexité inhérente à la programmation de logiciels a juste changé de forme.

Ce débat me rappelle un peu celui là :
http://www.developpez.net/forums/d76...-performances/

[Jean-Marc.Bourguet]

La médecine n'est pas une invention comme l'est un langage informatique on peut s'attendre chaque jour à un changement dans le fondamental (voir la découverte sur les cellules de sang et de tissu) chose quasiment impossible pour un langage informatique spécifié au départ.

Quelque soit le domaine que tu enseignes, tu te tiens au courant de celui-ci. Tu n'as pas besoin d'etre necessairement a la pointe de la recherche, mais tu dois le maitriser assez et etre assez a jour pour ne pas enseigner des choses qui etaient depassees il y a dix ans.

En passant, quel est le point de depart pour toi ou le C++ etait specifie?

Il y a en tout cas un problème quelque part avec l'enseignement du C++ ou l'enseignement informatique en général.

Avec l'enseignement de l'informatique en general et de la programmation en particulier. En caricaturant et en generalisant:

- la recherche ignore l'applicabilite industrielle

- l'industrie ignore ceux des resultats de la recherche qui seraient pourtant applicables

- l'industrie est fragmentee et composee de morceaux qui ignorent les acquis des autres (en prime, a voir certains j'ai l'impression qu'elle ignore qu'elle est fragmentee et que chaque morceau pense ses problemes comme universels)

- l'enseignement ignore et les resultats de la recherche et les acquis et les problemes de l'industrie.

[Issam_Lahlali]

Hello,
Si trop se focaliser sur la technique est une erreur, trop se centrer sur l'abstraction en est une autre. C'est simplement un juste équilibre - difficile à trouver. Car les deux notions sont liées (on abstrait de la technique). Bien connaitre les détails techniques permet de renforcer ton abstraction. On ne compte plus les design élégants qui reposent sur des astuces techniques bien trouvées.

tout a fait d'accord c'est pour cela j'avais dis dans la citation que tu viens de mentionner

l'abstraction a son intérêt dans un monde ou on a énormément d'implémentation

si on avait qu'une ou deux implémentation de librairies techniques le pb ne se pose même pas et on va pas chercher a faire beau pour compliquer, mais le constat qu'il y a énormément de librairie technique que je donne cette idée, et si t'a une autre idée de sortir de cette jungle de librairies techniques je serais preneur

[Jean-Marc.Bourguet]

Lorsque je parle de AbstractLib j'espère avoir un standard

Comment veux-tu faire pour avoir effectivement un standard et pas au mieux une lib de plus, au pire un document completement ignore.

(Exemple, cela fait 15 ans que "%c" est clairement defini comme argument de wprintf, une plateforme majeure -- Windows pour ne pas la citer -- ne se comporte pas de maniere standard).

A nouveau, si tu veux reellement faire evoluer les choses dans un sens qui te sembles desirable, il faut mettre la main a la pate et faire des propositions concretes. AMHA, quoi que tu fasses en dehors du comite ou de boost est quasiment certain de se retrouve sans effet pratique.

[Luc Hermitte]

a- Lorsque je parle de AbstractLib j'espère avoir un standard pas une nouvelle lib de plus comme l'OMG l'a fait pour l'aspect métier ou des contrats sont standarisés pour des domaines comme la finance ou autre.

b- et le fait qu'un developpeur c++ est noyé dans une multitude de librairies techniques c'est un fait, imaginant un developpeur c++ qui a bosser pendant 5 ans on n'utilisant que MFC( je sais c'est pouru) mais c'est encore utilisé et il change de boite et il découvre qu'ils utilisent QT alors il ne va pas exploiter au maximum son expérience puisqu'il doit réapprendre une nouvelle librairie.

c- Encore une fois on va me dire c'est valable pour les autres langages , mais les autres n'ont pas ce pb avec les librairies techniques.

a- Mais il y a un standard. Si les autres bibliothèques ne sont pas fichues d'être compatibles avec les classes standards, ce n'est pas en rajoutant une autre super-classe que cela va changer quoique ce soit. Elles ne feront pas plus d'effort.
Ca, c'est pour les streams.

Pour les chaines, c'est ignorer un détail capital de toutes les classes chaines C++ : elles ont une sémantique de valeur qui serait totalement incompatible avec un héritage. Il faudrait tout revoir.

Et le gars qui a développé avec les MFC il serait tout autant inadapté à Qt car il aurait développé pour MFC et non pour cette AbstractLib. Sans parler que chaque framework graphique a ses propres règles de conception. Autant il n'y a pas grand choc de conception de MFC à wxWidgets, autant c'est bien différent avec Qt, et le jour et la nuit avec la conception de adobe.ASL.

c- Mais, c'est valable pour les autres langages! Je compte swing, awt, swt, et QtJambi pour faire des IHM en Java -- il peut y en avoir d'autres. Et apache qui fournit des services complémentaires et/ou alternatifs à ceux de Sun. Et je ne sais combien de frameworks SOAisants/RPC-XML/...

Raison de plus d'avoir le réflexe de contrats dans la conception du METIER qui pour moi est la priorité pour un développement.

Ben oui, ce n'est pas ce que tu fais toi ? Je pratique la double mise en œuvre par NVI et par balises dédiées doxygen. Certes, c'est trop peu répandu en sortie de formation, mais avec un travail de fond, on y arrive.

[Aurelien.Regat-Barrel]

et le fait qu'un developpeur c++ est noyé dans une multitude de librairies techniques c'est un fait, imaginant un developpeur c++ qui a bosser pendant 5 ans on n'utilisant que MFC( je sais c'est pouru) mais c'est encore utilisé et il change de boite et il découvre qu'ils utilisent QT alors il ne va pas exploiter au maximum son expérience puisqu'il doit réapprendre une nouvelle librairie.

Je ne suis pas d'accord. Tout d'abord, en informatique, 5 ans c'est énorme, et devoir se mettre à la page fait partie du métier. Regarde comment on développait en .Net il y a 5 ans... Aujourd'hui je m'essaye à maitriser Php, et j'en fini plus de télécharger des dizaines d'outils et de frameworks dans tous les sens. C'est incroyable.

C++ est passé par là, mais aujourd'hui tout cela se stabilise (sélection naturelle). Grosso modo, il ne reste plus que Qt, qui est une lib aussi puissante que méconnue et sous-utilisée (scripting, theming d'interface en CSS, navigateur web intégré, IPC, ...).

[hegros]

En passant, quel est le point de depart pour toi ou le C++ etait specifie?

Lorsqu'on a écrit le premier compilateur C++ ?

Les spécifications en informatique changent souvent pour ne pas dire toujours, normal il faut bien évoluer et progresser, alors j'imagine que la spécification au départ du C++ n'a plus rien à voir avec celle d'aujourd'hui.


En même temps est-ce que enseigner la partie C du C++ est une erreur d'enseignement du C++ ? Pour moi non puisque cela en fait partie.

[Issam_Lahlali]

Ben oui, ce n'est pas ce que tu fais toi ? Je pratique la double mise en œuvre par NVI et par balises dédiées doxygen. Certes, c'est trop peu répandu en sortie de formation, mais avec un travail de fond, on y arrive.

sincèrement je te félicite pour ce niveau et comme t'a dit c'est trop peu répandu ,et c'est dans le fond ce qui me gène.

et il y a plusieurs facteurs qui font que c'est pas répandu comme plusieurs intervenants l'ont bien expliqué avant.

et je crains que si ça continue comme ça rare ceux en entreprise qui continueront avec c++ parce que juste une petite évolution peut être couteuse si c'est mal conçu.

et probablement le C++ aura toujours sa place en open source parce que ceux qui font le bénévolat en c++ sont en général motivé et savent ce qu'ils font.

c'est vrai que c'est commun a tout les langages mais c++ a un facteur de plus il est expert friendly.

[koala01]

c'est du à la conception du langage en lui même cela lui est intrinsèque. Quand tu as un fichier .cpp c'est du C++ que tu compiles qui dira le contraire ?

Le fait est que tu peux compiler en C++ du code C...Le C++ traîne avec lui le C...Le fait qu'on puisse autant mélanger montre bien le lien fort qui existe entre ces 2 langages.

Facile de rejeter la faute sur les profs avec autant de contrainte contradictoire sur ce langage.

C++ hérite, certes de C, et je ne le nie pas...

Mais L'approche, souvent observée, qui consiste à se dire que l'on va introduire C++ sous sa forme "C with classes" revient, à peu près à reprocher au descendant d'un criminel de guerre les crimes commis par son ancêtre alors qu'il ne partage absolument pas idéaux, uniquement parce que la génétique a fait qu'il a "le même sang"...

Je ne reproche pas du tout aux professeurs(du moins, de manière générale, car tous ne sont pas bons ) de ne pas bien apprendre le C++ à leurs élèves, je leur reproche de l'aborder par "le mauvais bout".

Plutôt que de l'aborder sous l'angle de son héritage avec C, il faudrait l'aborder sous l'angle des paradigmes objets et / ou générique, S(T)L en tête, histoire de ne pas se trainer les char* et les type* comme des boulets pendant des années alors qu'il est possible de faire autrement.

Evidemment, cela sous entend que le prof doit malgré tout connaitre suffisamment le C++ et ne pas le considérer lui-même comme du "C with classes"...

Et ce n'est que faire preuve d'honnêteté que de reconnaitre que c'est le cas de nombreux profs

Mais peut être que c'est une bonne chose... Sans cet "odieux mélange", le C++ serait il utilisé, autrement que marginalement, en entreprise? (l'aurait on jamais utilisé?) Et s'il n'était pas utilisé, aurions nous ces belles bibliothèques, ces beaux compilateurs, tous ces bons livres de référence ?

Je pense qu'il faut arrêter de ne voir dans le C++ que le langage du futur qu'il promet d'être depuis bientôt 10 ans. A mon avis, c'est tout autant du Not Invented Here que vouloir récrire sa STL maison.

Francois

En apprenant directement les bonnes pratiques qui sont propres au C++, et en l'abordant "par le bon bout", j'ai la conviction que l'on apprendrait "bien mieux" le C++ et qu'il perdrait sa réputation de langage complexe, du moins, la part de cette réputation qui lui vient de l'utilisation de techniques inadaptées héritées du C...

Si l'on décide d'aborder le C++ "par le bon bout", on peut en arriver à quelque chose proche de:

Le C++ est multi paradigme: il permet la programmation OO, la programmation générique (explications) et la programmation procédurale.

On découvre"rapidement" en revue les conteneurs STL, les string, et la progrmmation générique, et on laisse les pointeurs "de coté" jusqu'à ce que les gens sachent créer correctement des classe simples et qu'il faille aborder le problème de l'héritage et du polymorphisme...

[Jean-Marc.Bourguet]

Lorsqu'on a écrit le premier compilateur C++ ?

si tu essaies d'enseigner cela, tu es encore moins a jour que la totalite des profs. Cela fait tres longtemps que je n'ai plus vu quelqu'un utiliser le mot cle overload (qui a disparu en tant que mot cle, ne cherche pas).

Les spécifications en informatique changent souvent pour ne pas dire toujours, normal il faut bien évoluer et progresser, alors j'imagine que la spécification au départ du C++ n'a plus rien à voir avec celle d'aujourd'hui.

Et pourquoi les enseignants pourraient se contenter d'enseigner une version figee au moment ou le prof de leur prof de leur prof a appris la matiere?

En même temps est-ce que enseigner la partie C du C++ est une erreur d'enseignement du C++ ? Pour moi non puisque cela en fait partie.

Ce qui est une erreur, c'est de n'enseigner que cela et de commencer par cela.

[white_tentacle]

Raison de plus d'avoir le réflexe de contrats dans la conception du METIER qui pour moi est la priorité pour un développement.

Je ne sais pas de quels contrats tu parles, mais les miens, ils sont avant tout techniques. Ils sont faits à la conception, qui est une étape technique.

[hegros]

Je ne sais pas de quels contrats tu parles, mais les miens, ils sont avant tout techniques. Ils sont faits à la conception, qui est une étape technique.

La conception fonctionnelle n'a rien de technique informatique c'est de la technique du métiers.

D'ailleurs il y a des modèles de développement qui distinguent conception technique et conception fonctionnelle. La conception n'est pas systématiquement une étape technique contrairement à ce que tu dis.

[Issam_Lahlali]

Je ne reproche pas du tout aux professeurs(du moins, de manière générale, car tous ne sont pas bons ) de ne pas bien apprendre le C++ à leurs élèves, je leur reproche de l'aborder par "le mauvais bout".

tout a fait d'accord et il y a aussi le WEB qui ne l'aborde pas du bon bout aussi
maintenant les élevés s'orientent de plus en plus vers le WEB pour apprendre mais malheureusement l'historique des articles et des exemples qui trainent depuis des années font qu'on trouve encore pas mal de casse tête avec les char* et pointeur et double pointeur

a mon avis il faut faire en sorte de nettoyer le WEB de tout ces articles et exemples qui donne le mauvais exemple et je parle pas bien sur de developpez.com qui reste une bonne référence sur comment bien faire les choses

[white_tentacle]

D'ailleurs il y a des modèles de développement qui distinguent conception technique et conception fonctionnelle. La conception n'est pas systématiquement une étape technique contrairement à ce que tu dis.

Il y a des modèles de développement qui disent tout et n'importe quoi . Tu peux mettre ce que tu veux dans le terme conception, auquel cas, on ne parlera plus de la même chose, donc forcément, on aura du mal à tomber d'accord.

La mode actuelle est à parler de métier partout, c'est bien beau, mais ça brasse du vent. Un métier, ça n'est jamais qu'un ensemble de contraintes. Le rôle du développeur, c'est de concevoir un outil, qui, dans un contexte donné (le métier, effectivement), répond à une problématique. Une fois que tu as établi tes problématiques et tes contraintes (c'est à dire, que tu as fait ton analyse), tu peux passer à la conception de ta solution. C'est une phase technique, même si elle n'implique pas de code (au contraire de la phase précédente, l'analyse, qui elle peut être faite par un non-informaticien).

[Issam_Lahlali]

Il y a des modèles de développement qui disent tout et n'importe quoi . Tu peux mettre ce que tu veux dans le terme conception, auquel cas, on ne parlera plus de la même chose, donc forcément, on aura du mal à tomber d'accord.

La mode actuelle est à parler de métier partout, c'est bien beau, mais ça brasse du vent. Un métier, ça n'est jamais qu'un ensemble de contraintes. Le rôle du développeur, c'est de concevoir un outil, qui, dans un contexte donné (le métier, effectivement), répond à une problématique. Une fois que tu as établi tes problématiques et tes contraintes (c'est à dire, que tu as fait ton analyse), tu peux passer à la conception de ta solution. C'est une phase technique, même si elle n'implique pas de code (au contraire de la phase précédente, l'analyse, qui elle peut être faite par un non-informaticien).

c'est pas forcement parce que la conception est fait par un informaticien que c'est technique, le rôle du concepteur est de modéliser le métier pour le rendre implementable par un langage , et idéalement la conception doit être indépendante de la techno et du langage qui sera utilisé.

et lorsqu'on parle de contrats métier c'est avec un business analyste qu'on travaille le plus souvent, le concepteur n'a pas forcement connaissance du métier qu'il va implémenter.

et on parlant de ça peut être le fait que le cahier de charge vient 6 mois après la fin d'implémentation qui nous font oublier qu'il y a une conception fonctionnelle.