Discussion :

[Issam_Lahlali]

Y a quand même un truc où je ne comprends plus rien à la logique de ce que tu racontes.

Tu défends les frameworks "tout faits" façon .NET/Java, qui ne présentent pas de grande difficulté technique.

Mais tu défends le fait qu'il faille wrapper toute librairie utilisée pour masquer sa complexité. Et quand on te répond que s'il faut masquer la complexité de la librairie, c'est probablement parce que la librairie est (au choix) inadaptée ou mal faite, tu t'obstines à défendre le fait qu'il faut la wrapper.

Ça ne te semble pas un peu contradictoire, tout ça ?

effectivement je défends les deux et je m'explique:

je défends les frameworks genre DotNet et java c'est vrai mais l'historique en C++ fait qu'on a pas une telle librairie dans le sens qu'elle est homogène et regroupe la majorité de nos besoins techniques.

et je suis pour simplifier la couche technique quelque soit le langage, C++,C# ou java ou autre, par exemple et pour être concret pour un projet dont j'ai assister qui utilise le WCF de dotnet, des classes très simples ont était proposer aux développeurs pour leur faciliter la vie et ne pas se soucier des détails de WCF et crois moi il y en a énormément.

mais pour les développeurs dotnet ou java ils acceptent facilement cette idée de leur faciliter la vie, par contre en C++ il y a une résistance pour une telle démarche et ça se voit d'ailleurs dans ce topic .

[_skip]

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme

Code :

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

1
2
3
 
WSADATA WSAData;
WSAStartup(MAKEWORD(2,0), &WSAData);

ou genre

Code :

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

1
2
3
4
5
6
7
8
 
SOCKET sock;
SOCKADDR_IN sin;
sin.sin_addr.s_addr	= inet_addr("127.0.0.1");
sin.sin_family		= AF_INET;
sin.sin_port		= htons(4148);
sock = socket(AF_INET,SOCK_STREAM,0);
bind(sock, (SOCKADDR *)&sin, sizeof(sin));

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

Sans être un expert, je pense que c'est l'utilisation des sockets prévue dans l'API windows en C. Si on ne veut pas descendre si bas (ce qui me semble tout à fait raisonnable et compréhensible), il existe sans doute une floppée de classes C++ permettant de faire du socket de façon plus confortable avec un joli objet gérant l'asynchrone etc...

C'est je suppose la voie qui sera préconisée dans un grand nombre de projet. Autre exemple de ce genre, créerais-tu une boîte de dialogue avec la méthode Winapi et sa boucle d'évènement, ou utiliserais-tu une surcouche tels que les MFC?

Dans un développement, je pense que nous sommes tous d'accord ici pour dire qu'il ne faut pas aller plus bas que nécessaire et se reposer, lorsque cela est possible, sur des libs de plus haut niveau éprouvées, afin de ne pas réinventer la roue.

Ce qui m'intéresserait par rapport à ce débat, même si j'ai du mal à en saisir la matière exacte, est de savoir si cette action de *wrapper* ou plutôt cacher les détails de l'implémentation se fait

1) par volonté de simplification : Tu utilises une librairie comme ce qui est proposé par boost ou QT afin de ne pas avoir les mains dans certaines API quasiment de niveau OS.
2) pour camoufler l'usage d'une librairie : Tu ne veux pas que ton code utilise directement des librairies telles que boost ou QT pour avoir la liberté de les remplacer.

Alors ? La motivation première c'est quoi?

[Invité]

C'est vrai ça, la réputation des 10 ans de retard ?

Probablement pas. Sur un marché ouvert, international et évolutif comme l'informatique, si les entreprises françaises avaient 10 ans de retard, elles auraient disparu il y a longtemps.

Quant à l'état de l'art, comme toujours, ça dépend des secteurs, l'informatique n'est pas un domaine homogène. Les USA investissent beaucoup plus que la France (ou l'Europe) en recherche appliquée (ici, pas mal de gens semblent considérer que la recherche *doit* être inutile), et la création d'entreprise y est favorisée (par le système économique et la taille du marché). Alors, dans les domaines de type "start up", ils sont bien plus dynamiques.

Sur des sujets plus scientifiques, d'ingéniérie, ou dans des créneaux ou l'industrie française est traditionnellement bien positionnée (télécoms), c'est l'inverse. Dans mon secteur, l'amérique et l'asie sont affreusement en retard, et l'europe occidentale domine.

Ca dépend, quoi...

Francois

[Issam_Lahlali]

Ce qui m'intéresserait par rapport à ce débat, même si j'ai du mal à en saisir la matière exacte, est de savoir si cette action de *wrapper* ou plutôt cacher les détails de l'implémentation se fait

1) par volonté de simplification : Tu utilises une librairie comme ce qui est proposé par boost ou QT afin de ne pas avoir les mains dans certaines API quasiment de niveau OS.

2) pour camoufler l'usage d'une librairie : Tu ne veux pas que ton code utilise directement des librairies telles que boost ou QT pour avoir la liberté de les remplacer.

Alors en gros?

les deux et pour le premier point même si t'utilise boost ou Qt ou n'importe quelle librairie haut niveau , il faut penser a faire abstraction a chaque fois si c'est nécessaire, si tu vois l'exemple dont j'ai parler plus haut de boost.asio ou même dans les exemples des créateurs de boost on fait des wrappers pour simplifier l'utilisation.

et le message est simple et claire :

la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier.

et je ne comprends pas toute cette résistance pour une idée aussi simple que simplifier soit tout est simple ,soit tout le monde est expert,et je crains que ni l'une ni l'autre n'est vrai.

et comme info pendant toute mon experience en C++ il y avait toujours existante d'une équipe framework technique qui fournit des classes pour simplifier la vie aux développeurs, et le soft de ces boites marche trés trés bien et en plus c'est des éditeurs de logiciels internationals pas des SSII qui font tout et n'importe quoi.

peut être tout ce monde n'ont rien compris et ils perdent leur temps avec ce framework mais en pratique ça marche très très bien.


et sincèrement je suis quelqu'un terre a terre , je ne comprends pas trop la philosophie mais je me fie a ce que j'apprends au niveau pratique et cette démarche je l'est appris en pratique et j'ai vu ces avantages surtout pour les moyens et grands projets.

[gl]

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur

Les sockets BSD sont effectivement un élément qui s'encapsule très bien dans une couche de plus haut niveau, ils ont en effet une granularité très fine qui n'est pas nécessaire pour la plupart des applications.

Juste quelques remarques sur ta proposition :

• Une API aussi simple que celle que tu proposes à :
  
  • Soit de forte chance d'être propre à une application voire à certaines connexions au sein de cette application (sauf si toutes les applications en question ne sont qu'une variation sur le même thème), ce qui est contradictoire avec ton souhait initial d'une API simple et commune.
  • Soit l'API est commune à différente implémentations qui sont intrinsèquement différentes (et je ne parle pas des différences purement techniques dont on cherche à s'abstraire comme le type de connexion, mais bien de différence plus fonctionnelles comme la définition de la fin d'une trame).
  • Soit l'API dispose de peu de fonctions mais de très nombreux paramètres, ce qui ne fait que déplacer la "difficulté".
• Si tu cherches à simplifier la vie des utilisateurs de ton API, tu devrais t'intéresser au RAII qui te permettrait de ne pas avoir à appeler Open() et Close().
• Dans un projet un minimum complexe (mis à part les applications réseau ou d'autres cas où les sockets sont au cœur de l'application), l'utilisation des sockets est restreinte à certains modules qui gèrent le protocole applicatif et la problématique connexion et présentent une API axée "protocole applicatif" au reste de l'application. Au final, peu de personnes dans le projet vont avoir à utiliser les sockets.

En outre, concernant la méthode : plutôt que de re-développer une classe réseau, il faudrait regarder ce qui existe par ailleurs.
D'autant que les sockets BSD sont très répandus et devenus un standard de fait et qu'il existe de nombreuses bibliothèques de socket haut niveau très répandues et utilisées, il est donc assez facile de trouver des personnes sachant utilisées correctement ces APIs contrairement à ta classe personnelle dont les tenants et aboutissants ne sont au final connus que des quelques personnes ayant implémentées cette classe. C'est également un paramètre à prendre en compte et il faut voir si le gain apporté par l'apparente simplicité de ta classe compense cet avantage.

et je ne comprends pas toute cette résistance pour une idée aussi simple que simplifier soit tout est simple ,soit tout le monde est expert,et je crains que ni l'une ni l'autre n'est vrai.

Mais encore une fois, personne n'a prétendu ici que le C++ est trivial ou que tout le monde est expert.
Ce qu'on cherche à te dire c'est, entre autre, que :

• Les autres langages ne sont pas non plus triviaux.
• La principale difficulté n'est pas forcément dans le fait d'avoir de nombreuses fonctions dans une API ou différentes APIs pour adresser le même segment technique.
• Que tu n'es pas obligé d'utiliser systématiquement tous les mécanismes/paradigmes/subtilités du langage.
• Que cette relative difficulté est le pendant de ce qui fait la puissance et un des principaux intérêts du C++.

et comme info pendant toute mon experience en C++ il y avait toujours existante d'une équipe framework technique qui fournit des classes pour simplifier la vie aux développeurs, et le soft de ces boites marche trés trés bien et en plus c'est des éditeurs de logiciels internationals pas des SSII qui font tout et n'importe quoi.

peut être tout ce monde n'ont rien compris et ils perdent leur temps avec ce framework mais en pratique ça marche très très bien.

Mais là encore, personne n'a dit qu'il ne fallait pas faire de bibliothèque/framework haut niveau et générique. Par contre :

• Il est quasi-impossible de faire un framework haut niveau, simple d'utilisation et adressant tous les cas d'utilisation.
• Il faut étudier les conséquences, peser les avantages et inconvénients et éventuellement faire des tests/bench/maquettes avant de se précipiter sur un framework.
• Parfois ils sont inutiles voire néfastes ou inutilisables.
• Pourquoi ne pas utiliser des bibliothèques déjà répandues et donc éprouvées et debuggées (Boost, POCO, ICE, ACE, etc.) plutôt que de refaire un framework maison, peut être plus simple d'apparence mais probablement moins souple et moins robuste.

Comme l'a signalé, entre autres, Matthieu Brucher, il n'y a pas qu'un axe, qu'un paramètre à prendre en compte mais plusieurs.
Au final, le niveau d'abstraction, les bibliothèques et framework à utiliser, les critères importants, etc. sont à voir au cas par cas.

[gl]

Dans le GoF, ils sont séparés en 3 grandes catégories, selon ce qu'ils font. Adapteur et façade sont proches, mais l'un travaille sur une classe, l'autre travaille sur plusieurs classes.

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.

[Mac LAK]

et sincerement lorsqu'on lit une doc ou on fait de la theorie c'est pas la meme chose que pratiquer, par exemple pour ICE ou toute solution pour le distribué il y a plusieurs services a prendre en compte :

Je pratique aussi ICE, et au "maximum" ou presque : utilisation de IceGrid / IceBox pour la gestion centralisée des endpoints, génération automatique multi-langage par Slice à partir de modules ICE les plus simples possibles (à peu près ce que tu demandes comme fonctions exposées), utilisation des divers modules comme IceStorm pour les publications asynchrones, IcePatch pour la mise à jour / déploiement, etc. En gros, à part les facettes (on verra à la prochaine version de notre produit, si l'on a besoin de faire évoluer les interfaces ou pas) et les communications SSL (réseau privé, on s'en fiche donc), j'utilise TOUTE la librairie ICE...

Cela fait exactement ce que tu demandes (en lieu et place des sockets), avec un niveau d'abstraction librement décidable (c'est toi qui décide de l'interface des classes ICE), sans se fader la "technique" comme tu dis dès que tu te mets à utiliser un réseau ICE. De plus, y compris en se limitant à la boucle locale, cela permet un transfert de données entre différents langages d'une façon extrêmement simple tout en restant efficace : il n'y a guère qu'avec un wrapper comme SWIG que l'on peut avoir de meilleures performances, mais sans la notion de système déporté inhérente à ICE.

On peut légitimement se demander si tu as vraiment compris comment utiliser une telle librairie, ou si tu l'as réellement testée / évaluée... Car c'est exactement ce que tu demandes, axé réseau. Côté système, tu as POCO qui est du même ordre de généricité / abstraction, pour info.

Avec une telle librairie "réseau" et une telle librairie "système", toutes deux franchement très bien faites et très bien documentées (surtout par rapport à ACE...), génériques et découplées de la "technique", tu peux nous dire ce qu'il te manque réellement, au final ?

[metagoto]

Probablement pas. Sur un marché ouvert, international et évolutif comme l'informatique, si les entreprises françaises avaient 10 ans de retard, elles auraient disparu il y a longtemps.

Quant à l'état de l'art, comme toujours, ça dépend des secteurs, l'informatique n'est pas un domaine homogène. Les USA investissent beaucoup plus que la France (ou l'Europe) en recherche appliquée (ici, pas mal de gens semblent considérer que la recherche *doit* être inutile), et la création d'entreprise y est favorisée (par le système économique et la taille du marché). Alors, dans les domaines de type "start up", ils sont bien plus dynamiques.

Sur des sujets plus scientifiques, d'ingéniérie, ou dans des créneaux ou l'industrie française est traditionnellement bien positionnée (télécoms), c'est l'inverse. Dans mon secteur, l'amérique et l'asie sont affreusement en retard, et l'europe occidentale domine.

Ca dépend, quoi...

Effectivement pour les telecoms à propos du retard des US.

Et sinon pour ce qui est du génie logiciel, il me semble que c'est l'Inde qui s'accapare une majorité de contrats de nos jours. Les boîtes sont internationales mais les ingés et les devs sont indiens. Business as usual

Pour ce qui est des langages de programmation, sans trop y réfléchir, j'ai l'impression que pratiquement tous les plus populaires à l'heure actuelle ont été inventés sur le territoire US... dans les années 70-90. Il faudrait que je fasse une recherche (et des beaux graphiques avec des drapeaux et tout )

[gl]

Côté système, tu as POCO qui est du même ordre de généricité / abstraction, pour info.

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é.

[Issam_Lahlali]

[*]Pourquoi ne pas utiliser des bibliothèques déjà répandues et donc éprouvées et debuggées (Boost, POCO, ICE, ACE, etc.) plutôt que de refaire un framework maison, peut être plus simple d'apparence mais probablement moins souple et moins robuste.

mais encore une fois le but est de ne pas tout refaire, pourquoi on me fait dire ce que je n'est jamais dit

le but est de simplifier ce qu'on juge compliqué et forcement il y en a plusieurs cas ou on répètent les mêmes lignes pour un besoin technique et la il faut penser a faire abstraction et éviter les copier/coller.

[Issam_Lahlali]

Je pratique aussi ICE, et au "maximum" ou presque : utilisation de IceGrid / IceBox pour la gestion centralisée des endpoints, génération automatique multi-langage par Slice à partir de modules ICE les plus simples possibles (à peu près ce que tu demandes comme fonctions exposées), utilisation des divers modules comme IceStorm pour les publications asynchrones, IcePatch pour la mise à jour / déploiement, etc. En gros, à part les facettes (on verra à la prochaine version de notre produit, si l'on a besoin de faire évoluer les interfaces ou pas) et les communications SSL (réseau privé, on s'en fiche donc), j'utilise TOUTE la librairie ICE...

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.

le piège c'est qu'on fait trainer ce type de librairie dans tout le projet et si demain on veut le faire marcher dans un contexte autre que distribué on passe notre temps a isoler le métier et c'est la qu'on se rend compte que c'était mal conçu au départ.

je préfère l'autre choix ou on simplifie au maximum au developpeur métier on lui cachant toute subtilité de ce type de librairie, et c'est un choix prouvé en sur tout les projets lesquels j'avais bosser qui ont très bien marcher a l'international et on sait bien qu'en france il nya pas enormement d'editeur de logiciels qui s'impose en international en tout cas pas autant que l'angletaire, l'alemagne ou USA.

donc si je pratique une approche qui a très bien marcher , est ce que tu crois que je vais dire non c'est du n'importe quoi et il faut que je fasse autrement

[gl]

le but est de simplifier ce qu'on juge compliqué et forcement il y en a plusieurs cas ou on répètent les mêmes lignes pour un besoin technique et la il faut penser a faire abstraction et éviter les copier/coller.

Et je vais donc répéter la question qui t'a déjà été posé plusieurs fois (et non, ce n'est pas pour être désagréable, mais pour comprendre). Qu'est ce qui est compliqué ou trop technique dans les lib citées ? Qu'est ce que tu veux encapsuler concernant les sockets de plus que ce qui existe dans ces bibliothèques.
Pour information, une connexion suivi d'un envoi/réception avec POCO s'est 4 lignes :

Code :

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

1
2
3
4
SocketAddress sa(IPAddress, IPPort);
StreamSocket sock(sa);
sock.sendBytes(SndFrame, SndLen);
RcvLen = sock.receiveBytes(RcvFrame, WaitLen);

Que veux-tu simplifier ici ? Qu'y a-t-il d'aussi compliqué ?

Plutôt que de chercher à simplifier ou à encapsuler à l'infini les sockets simples, il est bien souvent plus rentable de développer un module en charge du protocole applicatif et de concentrer l'utilisation de socket à l'intérieur de celui-ci.

[Issam_Lahlali]

Et je vais donc répéter la question qui t'a déjà été posé plusieurs fois (et non, ce n'est pas pour être désagréable, mais pour comprendre). Qu'est ce qui est compliqué ou trop technique dans les lib citées ? Qu'est ce que tu veux encapsuler concernant les sockets de plus que ce qui existe dans ces bibliothèques.
Pour information, une connexion suivi d'un envoi/réception avec POCO s'est 4 lignes :

Code :

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

1
2
3
4
SocketAddress sa(IPAddress, IPPort);
StreamSocket sock(sa);
sock.sendBytes(SndFrame, SndLen);
RcvLen = sock.receiveBytes(RcvFrame, WaitLen);

Que veux-tu simplifier ici ? Qu'y a-t-il d'aussi compliqué ?

Plutôt que de chercher à simplifier ou à encapsuler à l'infini les sockets simples, il est bien souvent plus rentable de développer un module en charge du protocole applicatif et de concentrer l'utilisation de socket à l'intérieur de celui-ci.

c'est la le grand desastre de C++ juste en parlant des sockets, on m'a sorti boost.asio,ICE et POCO ca veut deja tout dire.

et encore une fois on va pas faire cette démarche tout le temps, mais la ou on juge utile et c'est que je ne cesse de répéter, si POCO est facile pour les socket, ICE facile pour le distribué et Boost sur autre chose, est ce que tu crois que je vais utiliser 36 000 librairies ça sera une pure complication.

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.

et encore une fois le but est de faire abstraction la ou on juge utile dans un framework technique de l'entreprise et il faut éviter de me sortir a chaque fois une librairie qui soit disant facilite une partie de la couche technique, juste en quelques réponses j'ai eu droit a trois librairies et si on continue on aurai autant de posts que de librairies

alors pour les librairies que vous utilisez tôt ou tard il y aura des choses a simplifier et c'est pas un mal puisque les librairies sont en général générique et dans ce cas penser a les simplifier et ne pas entrer dans le piège de laisser la complexité trainer pour tous les développeurs tout au long du durée du projet c'est aussi simple que ca

[gl]

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.

le piège c'est qu'on fait trainer ce type de librairie dans tout le projet et si demain on veut le faire marcher dans un contexte autre que distribué on passe notre temps a isoler le métier et c'est la qu'on se rend compte que c'était mal conçu au départ.

Si ce n'est que dans certains cas, le fait que ce soit distribué n'est pas qu'un simple détail technique dont on se moque.
Pour certains, c'est même une composante essentielle de l'architecture voire du métier.

Comme quelques uns te l'ont déjà signalé, tu devrais essayer d'élargir un peu ta vision et comprendre que l'informatique ne se réduit pas uniquement à ce que toi tu fais.
Il y a une multitudes de contextes différents, de projets différents,de contraintes différentes. Ce que l'on pratique (toi ou n'importe qui dans ce métier) n'est qu'une toute petite proportion (certes plus ou moins grande suivant le vécu des personnes, mais petite dans tous les cas) de ce qui existe.

[Issam_Lahlali]

Il y a une multitudes de contextes différents, de projets différents,de contraintes différentes. Ce que l'on pratique (toi ou n'importe qui dans ce métier) n'est qu'une toute petite proportion (certes plus ou moins grande suivant le vécu des personnes, mais petite dans tous les cas) de ce qui existe.

je pense que t'a zapper un post avant , on a ecrit le message au meme moment

tu remarque que j'ai mis en gras "on juge utile" et ca depend du contexte du projet, mais la vous etes contre un framework technique meme si on juge utile de faire abstraction qui dépend du contexe bien sur.

mais on est pas arriver a ce point vu que vous êtes contre avoir un framework technique et une équipe qui s'en occupe.

[gl]

c'est la le grand desastre de C++ juste en parlant des sockets, on m'a sorti boost.asio,ICE et POCO ca veut deja tout dire.

Tu peux enlever C++ de ta phrase. L'existence de différente bibliothèque plus ou moins concurrente existe dans de nombreux langages.

et encore une fois le but est de faire abstraction la ou on juge utile

Enfin.

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

[gl]

tu remarque que j'ai mis en gras "on juge utile" et ca depend du contexte du projet, mais la vous etes contre un framework technique meme si on juge utile de faire abstraction qui dépend du contexe bien sur.

mais on est pas arriver a ce point vu que vous êtes contre avoir un framework technique et une équipe qui s'en occupe.

Non, je ne suis pas contre un framework technique. Je me cite :

Les sockets BSD sont effectivement un élément qui s'encapsule très bien dans une couche de plus haut niveau, ils ont en effet une granularité très fine qui n'est pas nécessaire pour la plupart des applications.

Mais là encore, personne n'a dit qu'il ne fallait pas faire de bibliothèque/framework haut niveau et générique.

C'est juste à voir au cas par cas. Ce que tu sembles enfin avoir compris.

[Issam_Lahlali]

Tu peux enlever C++ de ta phrase. L'existence de différente bibliothèque plus ou moins concurrente existe dans de nombreux langages.



Enfin.

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

maintenant je comprends cette résistance, ca m'a fait trop peur
et la je comprends qu'on lit pas tout le message et on veut répondre avant même de terminer la lecture de message.

a plusieurs reprises ou je dis il y a des cas ou le mieux est de faire abstraction pour éviter les copier/coller, pour être sur essaye de relire attentivement mes posts des 3 dernières pages.

mais ce qui me parait bizarre c'est le rejet catégorique d'un framework technique en entreprise avant même qu'on parle ce qu'il faut mettre dans ce framework et dans quel contexte et ce que je ne comprenais pas c'est a chaque fois on me demandais qu'il ne faut pas refaire la roue et c'est la que je comprends qu'on lit la moitié des messages

C'est juste à voir au cas par cas. Ce que tu sembles enfin avoir compris.

juste pour te montrer qu'on lit la moitié des message voici une citation récente

"la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier."

qui montre bien qu'il faut adapter une librairie technique a notre besoin spécifique pour simplifier la vie aux développeurs, je ne sais pas comment je peux être plus clair que ça

[gl]

et la je comprends qu'on lit pas tout le message et on veut répondre avant même de terminer la lecture de message.

Pour ton information, sache qu'avant de répondre à un message, je le lis entièrement. Pour être plus précis avant de répondre, je lis tous les messages non lus de l'enfilade.

a plusieurs reprises ou je dis il y a des cas ou le mieux est de faire abstraction pour éviter les copier/coller, pour être sur essaye de relire attentivement mes posts des 3 dernières pages.

Non, tu ne le dis pas, ou alors ce n'était vraiment pas clair pour moi dans tes propos.
La notion du traitement au cas par cas, je l'ai effectivement vu dans les dernières pages, mais pas dans tes messages.

Ce que je lis de toi ressemble plutôt à

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

Et je ne vois pas la moindre notion de choix en fonction du contexte.

Si depuis le début tu prônais du cas par cas, je suis désolé pour cette incompréhension, mais je ne l'ai pas compris en lisant tes messages.

[Issam_Lahlali]

Si depuis le début tu prônais du cas par cas, je suis désolé pour cette incompréhension, mais je ne l'ai pas compris en lisant tes messages.

et tu fais attention a ça dans ma citation que t'a mentionné :

"et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois"

est ce que tu veux laisser les répétitions de lignes autre que dans un framework technique.

et bien sur ces répétitions dépendent de ton contexte qui impose d'appeler une sequence d'une maniere repetitif dans le code.

et voici plusieurs de mes citations depuis le commencement de ce sujet cad depuis la page 39 jusqu'a 42 cad très loin de la dernière page :

Mais pour les moyens et grands projets ça devient primordial, au lieu que 100 développeurs perdent leur temps sur la même chose répétitif, on la donne a une équipe de 3 personnes et c'est réglé, et chacun se concentre comme il faut sur ces taches spécifiques.

Librairie trop générique et se caracterise par un niveau trés bas de granularité au niveau methodes, cad qu'au lieu d'appeller une methode pour faire le travail on est obligé d'appeller une sequence de methodes a chaque fois, et dans ce cas le mieux est de faire l'abstraction pour eviter les copier/coller.

c'est pour cela qu'il faut se protéger par le couplage faible si on juge utile,pour s'adapter aux changements d'une manière souple et flexible.

prenons par exemple le cas StartWith avec std::string, on remarque qu'on l'a pas mais c'est pas ça le probléme, et on l'utilise beaucoup et dans ce cas il faut faire une abstraction a cette méthode et la coder une fois pour toute, au lieu que chacun fait sa propre version et on aura que du copier/coller qui traine.

la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier.

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