Discussion :

[gl]

a chaque fois je parle de mettre dans le framework technique ce qui est répétitif et ce qu'on juge utile mais il y avait dés le départ une résistance contre le framework technique , et si t'a t'est pas contre je crois que d'autres ils sont toujours contre

OK, je crois comprendre d'où vient cette incompréhension.

Le "ce que l'on juge utile", n'apparaît que dans un de tes derniers messages.

Les autres remarques portent sur le fait d'encapsuler ce qui est répété ou les
bibliothèques qui ne correspondent à 100% au niveau de granularité dont tu as besoin dans la partie "métier" du code, ce n'est pas de ça que je parlais en disant qu'il faut prendre la décision au cas par cas. Tu te focalises uniquement sur deux axes, qui bien qu'importants (et je ne remet pas en cause leur utilité, en particulier concernant la duplication de code) ne sont pas uniques, il existe de nombreux paramètres à prendre en compte. Même dans ces deux cas là, la décision d'encapsuler ou non n'est forcément systématique, même dans ces cas là il faut le faire si on le juge utile au regard des différents paramètres (sachant que la décision ne va pas satisfaire tous ses paramètres mais représenter un compromis acceptable).

Bref c'est réellement à voir au cas par cas et non en fonction de simplement deux critères.
Si tu travailles toujours dans un contexte équivalent et que dans ce contexte, ces deux axes représentent les deux seuls critères de choix, alors oui la décision doit toujours être prise en fonction de ces deux seuls critères. Mais il ne faut pas généraliser ton expérience, tout le monde ne travaille pas dans le même contexte et tout le monde n'a pas les mêmes contraintes.

[Mac LAK]

Juste une petite précision, POCO ne se limite pas au côté système, elle propose également des choses intéressante côté database et XML (respectivement module Data et XML) et également réseau (module NET), même si dans ce domaine elle semble moins riche que ICE (je ne connais pas vraiment ICE, donc je ne saurais être totalement affirmatif).
En outre Applied informatics propose également différents modules (commerciaux ceux-ci) axés réseau par dessus POCO qui, d'après les échos que j'ai eu, sont de bonne qualité.

Tout à fait. J'ai juste mis cette "étiquette" système dessus (sous-entendu, non-réseau) parce que ses fonctions réseau, toutes méritantes qu'elles soient, sont inférieures à celles de ICE. Réciproquement, les fonctions d'abstraction système de ICE (gestion des threads notamment) sont très lights par rapport à celles de POCO...
Pour le reste (et les visiteurs du topic), se reporter aux docs de ces librairies, c'est un peu trop vaste pour être résumé en trois lignes...

juste une question est ce que tout les développeurs qui ont besoin d'utiliser le distribué dans ta boite sont censé connaitre ICE et ces subtilités?

Bon, donc, tu n'as effectivement JAMAIS utilisé cette librairie, ni vu ce qu'elle faisait.
Pour un utilisateur d'un système ICE, ça se résume à (pseudo-code) :

Code :

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

1
2
3
4
endpoint=ICE::createObjectAdapter("NomSymboliqueDuServeur","AdresseIceGrid");
endpoint.DoAction1(...);
endpoint.DoAction2(...);
endpoint.DoComplexAction(...........);

Si besoin, tu peux aussi faire un helper sur la création de l'endpoint, mais bon, ça devient pire que de l'assistanat à ce niveau.
La tripaille, c'est les développeurs des API en question qui s'en occupent (et même eux ne touchent pas une seule fois une socket), le code client n'a jamais besoin d'être écrit explicitement (uniquement le code serveur, c'est à dire le remplissage des méthodes générées automatiquement par Slice), et l'administration IceGrid est plus que simplissime : il suffit de donner l'adresse du serveur IceGrid et c'est tout.

ICE fonctionne certes en distribué, mais aussi en flux (=sockets) plus ou moins typés, et en boucle locale en communication inter ou intra processus !

Donc, re-question : tu parles de devoir faire des frameworks, mais quand il en existe des bons déjà tout prêts, et répondant à tes besoins, tu sembles réchigner à les utiliser... Ne serait-ce pas incohérent ??

[Matthieu Brucher]

C'est réellement la seule différence ?

J'avais compris que la différence était plus dans l'intention :

• Le premier était à utiliser lorsque le client attendait une interface et que la classe en fournissait une autre.
• Le second permettait de masquer une ou plusieurs classes derrière une interface unifiée.

Ce qui laisse certains "cas limites" (normalisation d'interface à priori par exemple) dans une zone de flou.
Avec la différence que tu cites, il est effectivement plus de simple de cataloguer les constructions dans une catégorie ou dans l'autre, mais ça me semble assez artificielle comme différenciation.

En fait, tu viens de redire ce que j'ai dit sous une autre forme
Les catégories, ce sont :
- creational patterns (abstract factory, builder, factory method, prototype, singleton)
- structural patterns (adapter, bridge, composite, decorator, facade, flyweight, proxy)
- behavorial patterns (chain of responsibility, command, interpret, iterator, mediator, memento, observer, state, strategy, template method, visitor)
Certain sont effectivement très proches, comme state et strategy où la seule différence est réellement l'intention : est-ce qu'on change d'état/stratégie en cours d'exécution ?

juste une question est ce que tout les développeurs qui ont besoin d'utiliser le distribué dans ta boite sont censé connaitre ICE et ces subtilités?

si oui c'est un choix a respecter mais sérieusement pourquoi ajouter une complexité en plus pour tout les développeurs,tu me dira c'est trop facile mais peut être c'est facile pour toi , en général on a du mal a bien maitriser la technologie distribué et en plus pour moi tout ce qui touche au distribué n'est qu'un adaptateur , un développeur doit s'en foutre que ça soit distribué ou pas il doit y avoir une parfaite abstraction par rapport a ça et surtout un couplage très faible par rapport a cette couche.

C'est là aussi où tu n'as pas l'habitude de ces outils. Si tu avais un peu regardé l'opinion des gourous du multithreading/multiprocessing, tu te serais rendu compte que le découplage est quasiment impossible. Il y a un couplage fort et il y a une nécessité de réfléchir complètement différemment de ce que tu ferais en séquentiel.

si je reviens a l'exemple de boost.asio ou on dans les exemples de Boost eux même on fait des wrappers pour simplifier.

wrappers qui servent juste pour exemple, et encore, je ne vois pas vraiment où il y a deswrappers dans l'histoire Ce n'est pas parce qu'il y a un wrap* que c'est un wrapper. J'ai utilisé ASIO pour faire un moteur TCP/HTTP SOAP RPC, et il n'y a pas besoind 'autre chose que les outils ASIO de base. Je regarde ce que les gens ont aussi fait du même style à côté, et c'est la même chose, pas de wrappers.

Enfin.

C'est ce que tout le monde essaie de te dire depuis je ne sais combien de page.

Il le dit depuis longtemps mais n'a pas encore compris ce que cela impliquait, par exemple au niveau du choix des bibliothèques, des méthodologies, ...

[Issam_Lahlali]

Bon, donc, tu n'as effectivement JAMAIS utilisé cette librairie, ni vu ce qu'elle faisait.
Pour un utilisateur d'un système ICE, ça se résume à (pseudo-code) :

Code :

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

1
2
3
4
endpoint=ICE::createObjectAdapter("NomSymboliqueDuServeur","AdresseIceGrid");
endpoint.DoAction1(...);
endpoint.DoAction2(...);
endpoint.DoComplexAction(...........);

Si besoin, tu peux aussi faire un helper sur la création de l'endpoint, mais bon, ça devient pire que de l'assistanat à ce niveau.

de notre coté on laisse jamais trainer un code comme ca dans tout le projet, on propose une facade qui cache le fait qu'on travaille avec ICE , c'est pas un choix d'implementation c'est un choix de conception et c'est la diference entre nos 2 points de vue.

c'est pas le fait qu'elle est trés trés simple a utiliser qu'on va la laisser trainer dans tout le projet, et d'ailleurs c'etait bénéfique puisqu'on avait essayer plusieurs brockers et imagine si a chaque fois la librairie traine dans tout le projet.

c'est le principe de couplage faible qui te protège aussi des changements futurs insoupçonnés que j'ai répéter plusieurs fois.

mais ca reste je répète un choix de conception, c'est pas trop couteux et finalement si on pense bien c'est comme le principe de l'assurance ou on paye un montant par mois ( pas trop couteux) et lorsqu'il y a un probléme on trouve notre assurance

[_skip]

Vous ne pourrez jamais vous mettre d'accord tant que vous parlerez de choses différentes qui ne sont pas généralisables...

Si on prend un cas de figure un peu plus précis, celui de l'utilisation d'une balance électronique depuis l'application pour peser des objets.

Cela nécessite :
1) Ouverture si nécessaire du port série et application des paramètres spécifiques (baudrate, parité etc..)
2) Envoi d'une requête sous forme de chaine ASCII par le port série.
3) Attendre la stabilisation de la masse pendant X millis
4) Récupérer la masse de l'objet dans le port série
5) Parser tout ça pour obtenir la masse en double

Si quelqu'un dit que ce processus doit faire l'objet d'une fonction de haut niveau qui serait du genre

Code :

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

double peserObjet(int timeoutInMs)

Je suis entièrement d'accord pour la plupart des cas, on ne va pas commencer à copier coller toute cette séquence à travers l'application, refaire la gestion d'erreur entre les différents phases etc...

Par contre dans le corps de cette méthode peserObject, si on utilise Boost pour la gestion du port série et qu'on me dit qu'il faut wrapper boost afin de pouvoir mettre autre chose à la place. Là je suis nettement moins d'accord.

Alors?

[Issam_Lahlali]

Il le dit depuis longtemps mais n'a pas encore compris ce que cela impliquait, par exemple au niveau du choix des bibliothèques, des méthodologies, ...

pour être clair au sujet de ces bibliothèques on va parler d'un cas concret d'une entreprise qui commence un projet en C++:

imaginant qu'une Boite SB a une équipe de 50 développeurs C++ et utilise N librairies et on suppose que le choix est très judicieux fait par des experts comme toi qui maitrise très très bien le choix de librairie.

on commence l'implémentation et on se rend compte qu'on a besoin de fonctions techniques qu'on fait souvent non existantes dans nos librairies, et pour être concret disant le StartWith pour std::string , soit on laisse les 50 développeurs faire le StartWith a leur sauce soit avoir un framework technique au niveau de l'entreprise qui le fait.

moi je préfère avoir dés le départ du projet un framework technique ou je mettrais tout ce qui simplifiera la vie aux développeurs quelque soit les librairies techniques utilisés.

et crois moi tu fais l'expérience tu verra ce framework grandir rapidement parce que tu decouvrera que dans le code il y a pas mal de choses répétitifs avec les Copier/Coller.

d'autre part si t'est adepte du couplage faible comme assurance et protection au changement futur tu ne laissera jamais trainer les librairies pour le distribué par exemple trainer dans ton code, tu proposera a partir de ton framework une facade trés simple d'utilisation, et le but n'étant pas que simplifier mais avoir une assurance au cas d'un changement d'une techno.

et le réflexe de résistance contre le couplage faible et a mon avis comme le réflexe d'un conducteur qui dit je ne vais jamais faire d'accident je suis trés fort et j'ai pas besoin de payer l'assurance mais encore une fois ca ne dépend pas que toi, il y a plusieurs facteurs autour et tout peut changer a un moment donc autant se protéger depuis le départ.

[Mac LAK]

de notre coté on laisse jamais trainer un code comme ca dans tout le projet, on propose une facade qui cache le fait qu'on travaille avec ICE , c'est pas un choix d'implementation c'est un choix de conception et c'est la diference entre nos 2 points de vue.

Dans ce cas, tu fais un helper pour l'ouverture et tu rends le type de "endpoint" défini par macro (laid), ou héritage (bof...), ou template (admettons).
Ce qui revient toujours au même point : tu ne peux pas te passer des appels de fonction eux-mêmes, étant donné que ce sont, justement, les fonctions de haut niveau que tu souhaitais avoir.
Le fait que l'objet "endpoint" soit de type "ICE::Endpoint" ou "FrameworkMaison.Module2" a-t'il une importance quelconque, tant que les méthodes restent les mêmes ??

c'est pas le fait qu'elle est trés trés simple a utiliser qu'on va la laisser trainer dans tout le projet, et d'ailleurs c'etait bénéfique puisqu'on avait essayer plusieurs brockers et imagine si a chaque fois la librairie traine dans tout le projet.

Ça, c'est plutôt un problème d'étude de faisabilité mal faite que de conception et/ou d'adéquation des librairies... Et de conception aussi : si tu démarres bille en tête dans le code à essayer des librairies de façon empirique (plutôt que d'en mesurer objectivement les performances), c'est également la méthodologie qui est en cause et non pas, finalement, le code lui-même...

c'est le principe de couplage faible qui te protège aussi des changements futurs insoupçonnés que j'ai répéter plusieurs fois.

Sauf qu'à un moment, il faut aussi s'arrêter : si tu colles une couche abstraite et générique à chaque fois que tu fais le moindre truc, tu vas passer deux fois plus de temps à faire ces interfaces qu'à casser le code en cas de changement !!
Il faut savoir réfléchir en termes de coût horaire d'une modification, mais surtout en terme de probabilité de modification...

mais ca reste je répète un choix de conception, c'est pas trop couteux et finalement si on pense bien c'est comme le principe de l'assurance ou on paye un montant par mois ( pas trop couteux) et lorsqu'il y a un probléme on trouve notre assurance

Pas trop coûteux ??? Tu plaisantes, là... Si ce n'est pas fait de façon générale et universelle, c'est AUSSI qu'il y a une bonne raison, et pas l'incompétence des concepteurs contrairement à ce que tu sembles penser. A partir d'un certain stade, tout wrapper / encapsuler coûte bien trop cher (perfs et/ou temps de dév), tout simplement !

Comme dans beaucoup de domaines, et l'informatique n'échappe pas à la règle, jouer les "intégristes" est bien plus nuisible que profitable. Il faut savoir s'arrêter à un moment donné, mais tu ne veux pas écouter cet argument.

[Issam_Lahlali]

Par contre dans le corps de cette méthode peserObject, si on utilise Boost pour la gestion du port série et qu'on me dit qu'il faut wrapper boost afin de pouvoir mettre autre chose à la place. Là je suis nettement moins d'accord.

Alors?

certainement pas le but n'est pas wrapper Boost c'est aberrant, par contre on peut simplifier des fonctionalités de Boost si c'est necessaire.

par exemple j'ai donner l'exemple de StartWith qui n'existe pas pour std::string, on va pas laisser chaque developpeur faire sa version, mais on proposera une méthode qui le fait pour tout le monde.

ce que je dis c'est que dés le départ il faut avoir le réflexe d'avoir un framework technique ou on mettra tout ce qui facilitera le dev a tout le monde qui servira d'une part :

- simplifier et mettre en commun tout ce qu'on juge utile
- faire un couplage faible par rapport aux technos utilisés ,par exemple pour le distribué je ne laisse jamais trainer la librairie réel dans le code, je fais une façade et le developpeur ne sais même pas quelle techno distribué il utilise.

[Matthieu Brucher]

pour être clair au sujet de ces bibliothèques on va parler d'un cas concret d'une entreprise qui commence un projet en C++:

imaginant qu'une Boite SB a une équipe de 50 développeurs C++

J'arrête de lire là, car déjà à ce niveau, tu as imaginé un cas concret qui est clairement faux. On ne commence JAMAIS avec une équipe de 50 développeurs, dans n'importe quel projet.

Tu démontres, à mon sens, ta méconnaissance de la gestion de projets SI par cet exemple irréel, et c'est pour cette raison qu'on te dit qu'il te manque de l'expérience, car clairement dans ces dernières réponses, c'est le cas. On ne part jamais bille en tête et on ne fait jamais d'over-engineering comme tu veux en faire en encapsulant tout au cas où (et ça, ça vient du monde Java C# où ce sont des règles de base chez eux).

[Issam_Lahlali]

Dans ce cas, tu fais un helper pour l'ouverture et tu rends le type de "endpoint" défini par macro (laid), ou héritage (bof...), ou template (admettons).

je répète c'est un choix de conception pas d'implémentation, et pour l'implémentation c'est pas ca le probléme il y a plusieurs façons de donner une façade simple a utiliser.

et pour le cout de faire ce couplage faible, ce n'est pas des mois mais quelques jours, le but est de ne pas faire abstraction a tout ce que propose ICE , mais de faire abstraction de ce qu'on utilise de ICE et c'est pas du tout la même chose, chaque librairie est générique dans le sens ou elle propose énormément de fonctionnalités pour s'adapter a tout les besoins , ca veut pas dire que lorsque j'utilise ICE j'utilise tout ce qui est fourni.

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

et c'est ca le monde réel on peut avoir une surprise n'importe quand et fort heureusement on avait notre assurance qui était le couplage fable

finalement dire qu'on peut maitriser tout dés le départ c'est faux , on ne sait jamais ce qui peux se passer, et cette technique de conception de couplage faible on va pas la faire bien sur a tord et a travers , mais pour le distribué je suis pour le faire.

[Matthieu Brucher]

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

Et ? C'est un risque qui a un coût, une probabilité d'apparition et un coût de couverture.

Bon, là, on voit bien que tu essaies de te sortir de la situation dans laquelle tu t'es mis tout seul, on est à 100 lieues de ce que tu défends puisque maintenant tu ne veux plus de couplage faible partout, mais dans le distribué oui, alors que tu n'as, à nouveau, aucune connaissance dans ce domaine.

[Issam_Lahlali]

J'arrête de lire là, car déjà à ce niveau, tu as imaginé un cas concret qui est clairement faux. On ne commence JAMAIS avec une équipe de 50 développeurs, dans n'importe quel projet.

.

tu me montre que tu ne veux rien comprendre , ou t'a bien compris le message lorsque tu l'a lu jusqu'à la fin et tu me poste une réponse ridicule genre on commence jamais par une équipe de 50 développeurs et c'est pas ca qui va influencer sur le reste du message.

essaye de relire le poste et vire on commence et met a la place "pour un projet ou on a 50 developpeurs"

et essaye de me répondre sur le reste du message .

[Issam_Lahlali]

Et ? C'est un risque qui a un coût, une probabilité d'apparition et un coût de couverture.

Bon, là, on voit bien que tu essaies de te sortir de la situation dans laquelle tu t'es mis tout seul, on est à 100 lieues de ce que tu défends puisque maintenant tu ne veux plus de couplage faible partout, mais dans le distribué oui, alors que tu n'as, à nouveau, aucune connaissance dans ce domaine.

encore une fois ça montre l'utilité de la discussion " on ignore complètement la conception", si un expert comme toi ignore le principe de couplage faible, alors j'ai eu la réponse a ma question de départ

[Matthieu Brucher]

tu me montre que tu ne veux rien comprendre , ou t'a bien compris le message lorsque tu l'a lu jusqu'à la fin et tu me poste une réponse ridicule genre on commence jamais par une équipe de 50 développeurs et c'est pas ca qui va influencer sur le reste du message.

Eh si, ça influence, car tu pars sur un cas qui n'existe pas ! Tu veux nous faire des démonstrations alors que tu es complètement à côté de la plaque !
Toute ta méthodologie, tout ce que tu racontes par du principe qu'on prend 50 développeurs et qu'on y va, on code. Je comprends maintenant pourquoi tu posais ta question au départ sur la conception ! C'est que tu n'utilises aucune méthodologie de développement, c'est de l'arrache pure ! C'est claire que dans ces conditions, la technique est primordiale, mais quand on fait les choses correctement, avec une méthodologie éprouvée de développement, bizarrement, la technique (et c'est ce que TOUT LE MONDE ici t'a dit), c'est accessoire.

[Matthieu Brucher]

encore une fois ça montre l'utilité de la discussion " on ignore complètement la conception", si un expert comme toi ignore le principe de couplage faible, alors j'ai eu la réponse a ma question de départ

Où est-ce que j'ai dit que j'ignorai ce principe ? Où est-ce que j'ai dit que j'étais un expert ? C'est toi qui ne sais pas à quoi il sert et qui change d'avis tout le temps, pas moi.

[Issam_Lahlali]

Eh si, ça influence, car tu pars sur un cas qui n'existe pas ! Tu veux nous faire des démonstrations alors que tu es complètement à côté de la plaque !
Toute ta méthodologie, tout ce que tu racontes par du principe qu'on prend 50 développeurs et qu'on y va, on code. Je comprends maintenant pourquoi tu posais ta question au départ sur la conception ! C'est que tu n'utilises aucune méthodologie de développement, c'est de l'arrache pure ! C'est claire que dans ces conditions, la technique est primordiale, mais quand on fait les choses correctement, avec une méthodologie éprouvée de développement, bizarrement, la technique (et c'est ce que TOUT LE MONDE ici t'a dit), c'est accessoire.

une question simple et je veux une réponse simple mais pas philosophique comme dab:

est ce que t'est pour ou contre un framework technique au niveau de l'entreprise?

[Matthieu Brucher]

Mais pour faire quoi ton framework ? Chez moi, je suis désolé, mais c'est impossible d'avoir un seul framework technique pour la chimie, la sismique, la paie, ... Ce sont des technologies complètement différentes, aucun point commun, ...
C'est pour ça que je n'arrête pas de te dire que tu ne connais qu'une infime partie de ce que regroupe l'informatique !

[Issam_Lahlali]

Mais pour faire quoi ton framework ? Chez moi, je suis désolé, mais c'est impossible d'avoir un seul framework technique pour la chimie, la sismique, la paie, ... Ce sont des technologies complètement différentes, aucun point commun, ...
C'est pour ça que je n'arrête pas de te dire que tu ne connais qu'une infime partie de ce que regroupe l'informatique !

restant dans le concret , pour une fonction comme StartWith qu'on veut ajouter pour std::string , tu la mettra ou?

[Mac LAK]

et pour le cout de faire ce couplage faible, ce n'est pas des mois mais quelques jours, le but est de ne pas faire abstraction a tout ce que propose ICE , mais de faire abstraction de ce qu'on utilise de ICE et c'est pas du tout la même chose, chaque librairie est générique dans le sens ou elle propose énormément de fonctionnalités pour s'adapter a tout les besoins , ca veut pas dire que lorsque j'utilise ICE j'utilise tout ce qui est fourni.

C'est ce que je me tue (enfin, "nous nous tuons") à t'expliquer : ne confonds pas "couplage fort" et "mésutilisation d'une librairie"... Cf. mon post précédent, où je te montre pourtant que c'est bien ce que permet ICE, ou toute librairie correctement construite d'ailleurs...

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

Tu sais, Issam, en dix ans d'expérience, et dans le bas niveau (où le code "en dur" est plus la règle que l'exception), des changements radicaux de librairies, j'en ai fait plus d'un... Y compris des changements de plate-forme matérielle, de compilateur, de gamme de code (16 bits à 32 bits, 64 bits bientôt), alors je connais bien le sujet du "ça ne changera jamais" qui n'est jamais vrai.

Je sais très bien que ça n'existe pas, par contre, je sais évaluer si une techno/librairie quelconque pourra perdurer au moins le temps de vie du module en question, avant que sa refonte intégrale ne devienne nécessaire de par les simples évolutions requises par le client (entre 5 et 10 ans dans mon domaine)... Et c'est au moment de la refonte que l'on change la "base", technologique ou logicielle, qui sous-tend le module devenu obsolète.

Mais ça, c'est l'expérience qui te l'apprends, ainsi que la connaissance du métier. C'est aussi savoir faire une étude de faisabilité, savoir "sentir" si une techno est pérenne ou juste un gadget à la mode, savoir poser les BONNES abstractions aux BONS endroits, savoir raisonner non plus en framework mais en flux de données, etc.
Comme te l'a dit aussi Matthieu, c'est une analyse de risque, avec probabilité d'occurrence et coût en cas de problème.

et c'est ca le monde réel on peut avoir une surprise n'importe quand et fort heureusement on avait notre assurance qui était le couplage fable

Toi, t'es du genre à prendre une assurance auto tout-risques (couvrant aussi le risque de chute de station spatiale, la guerre nucléaire et les attaques d'aliens), alors que tu conduis un tas de boue de 20 ans qui roule à peine ?
Moi, non... J'assure en fonction de la valeur des choses, et du coût de remplacement. On ne mets pas dans une assurance le prix de l'objet neuf, c'est tout simplement un non-sens ! Dans le cas d'une voiture, si en trois ans tu mets dedans le prix d'une voiture neuve (36 mois, soit 280€ / mois pour une voiture à 10.000€), c'est idiot, il vaut bien mieux la prendre en leasing avec assurance incluse !! Et cela reste valable même en arrivant à "seulement" la moitié du prix de la voiture, d'ailleurs !

C'est pareil en logiciel : tu dis "ça ne prends que quelques jours"... OK, mais combien ? Et surtout, combien coûterait le fait de modifier les sources et tous les appels, SI la librairie de support venait à changer ??
La modification des sources, avec un bon éditeur de texte et une bonne expression régulière, ça peut aller extrêmement vite... Quelques HEURES à peine !! Dans un tel cas, ton couplage faible est tout simplement une perte sèche, il faudrait que tu t'en rendes compte...

Mais tu ne veux pas entendre ces arguments, ni même y répondre, à se demander à quoi cela sert-il de tenter de t'expliquer...

finalement dire qu'on peut maitriser tout dés le départ c'est faux , on ne sait jamais ce qui peux se passer, et cette technique de conception de couplage faible on va pas la faire bien sur a tord et a travers , mais pour le distribué je suis pour le faire.

On peut maîtriser 90% dès le départ, en évitant de commencer à coder AVANT d'avoir fini la conception générale ET les études de faisabilité... C'est ça aussi, le métier et l'expérience.

[white_tentacle]

starts_with, ça ne serait pas compare(0, str2.size(), str2) == 0 ?

Il y a vraiment besoin de wrapper ça ?