Discussion :

[Kikos31]

Dot Net a forcement un avenir, tout comme ce que Microsoft a fait jusqu'à présent.

Ok jusqu'ici on est d'accord. C'est enfoncer des portes ouvertes que de souligner qu'ils ont le poids et les moyens d'imposer leur technologie.

Le leader mondial des solutions en bois ne peut que nous promettre des milliers de versions plus ou moins compatible entre elle et avec tous les soucis que çà posera... que cela ne tienne ! il y aura toujours des gens pour acheter ces technos pourraves soient disant révolutionnaires.

Là par contre c'est du dénigrement anti crosoft pur et dur sans l'ombre d'un argument. Oui je sais que ca fait genre que d'enfoncer Microsoft mais au moins donne des exemples.

Je sais bien qu'en tant qu'informaticien on est sensé avoir des raisonnements binaires mais Microsoft c'est une boite comme les autres, y a du bon ( Win2000/XP, l'USB, .NET, Excel ) et des gros loupés ( La techno activeX, IE ... ). Aprés c'est une question de gout, les nostalgiques de vi ne sont pas obligé d'être sous Windows et de programmer avec VS.

Dot Net ne réinvente pas la poudre, mais permet simplement de vulgariser certaines technos aux pauvres informaticiens que nous sommes en échange de quelques Euros pour chaque version de leur compilo. Enfin bon, çà ne change pas, on connait bien les techniques de l'ami Billou. Cà c'est mon avis et il n'engage que moi.

Là aussi c'est de la mal/désinformation. La techno .net c'est le truc le plus ouvert que Microsoft ai fait depuis longtemps. Le Framework est gratuit, les compilos sont gratuits, et maintenant il y a même les version Express de VB/C#/C++ qui sont gratuites.

On est bien d'accords : ils ne font pas ca par altruisme ( il est évident qu'ils souhaites rendre windows encore + incontournable en attirant les développeurs ) mais ce que tu dis dans ce contexte est faux.

D'un point de vue purement informatique, Dot Net est une réponse au besoin d'aujourd'hui : l'application intra distribuée made in CroSoft.

Après on adhére ou pas

Tout a fait, et a chacun de peser les avantages et inconvénients selon la situation.

Pour en revenir au sujet je fais parti des convaicu de la viabilité du DOTNET et ceci pour plusieurs raisons :

- Le poids économique de Microsoft ( c'est évident on va pas y revenir )

- La multiplication des langages ( Le C# a attiré tout un tas de rebelles qui étaient sur des produits borland )

- L'installation du framework par Windows Update

- Une techno non pas révolutionnaire mais totalement actuelle et en progression perpetuelle ( voir le futur LINQ )

- La possibilité de faire de la belle POO de manière plus moderne qu'avec le C++ pour les pros mais aussi de faire des usines a Gaz à coup de Wizard pour les débutants.

Mais pour moi, l'argument numéro 1 c'est que l'utilisateur final statisquement :

- Il est sous Windows XP ( pour les jeux/Multimédia/ADSL ).
- Il a un PC à 1Ghz ou plus
- Il y connait que dalle et veut pas s'y connaitre
- Il en a rien a foutre si son logiciel est fait en DotNet ou autre, il veut des belles icones et que ca fonctionne ( si ca fait meuuh quand on clique c'est un plus ).

Dans ce contexte la technologie qui permet de développer rapidement sur la plateforme cible pour pas trop cher ( et avec des ressources disponibles gratuitement ) ne peut pas se planter.

Et cette définition colle assez bien à .NET.

[Mose]

Un pt de vue technique, de la part d'un puriste :

* C# n'est pas un langage 100% objet. Il y manque une composante indispensable, qui fait facilement 50% de la puissance de l'objet c'est L'Héritage Multiple. Ceux qui répondront "les interfaces ça fait la même chose" ont bien appris leur leçon, mais ils ne savent pas de quoi ils parlent.

* Dans la même veine : le framework .Net a des classes 'sealed' et 'internal', qui sont des notions complètement anti-objet. Pourquoi cacher des choses alors que le principe même de l'objet est la composition par héritage ? Sans doute à cause de vieux réflexes procéduraux, ou pour cacher des API instables.

* Le Framework est tout plat !! 90% des objets dérive de 'Object', ce qui est complètement idiot. Tellement d'objets ont de points communs, il aurait fallu une structuration beaucoup plus hiérarchique et une réflexion globale, et pas une bête traduction des WinAPI sous une couche pseudo-objet.

* On ne peut pas hériter des Value-Type. J'aurait bien aimé pouvoir créer une classe "string-de-10-caractères", mais c'est pas possible. "C'est pour des questions de sécurité" : non. C'est parce que les API derrières sont bancales, ou paske le code de .Net est mal foutu.

Je sais parfaitement que ces limitations ont été mises en places dans le but de simplifier la programmation de projet de grosse envergure pour ceux qui n'ont pas une formation poussée de développeur. C'est dommage, quand on sait ce qu'on pourrait faire...

Voilà tout le mal que je pense de .Net. Ceci dit, je ne suis pas un anti : j'en fais depuis 3 ans, environ 10h par jour, et maintenant en tant qu'indépendant (donc par choix). A mon goût, ça reste le plus efficace des langage pour coder rapidement.

Maintenant si on me demande "que sera l'avenir" ? je répond : pas le C#. Microsoft est une entreprise de business, pas une entreprise de technologie, et j'espère bien qu'une de ces dernières auront la possibilité de faire un vrai langage un de ces jours (aussi puissant et complet que C++, aussi lisible et haut niveau que C# ?).

[vosaray]

Je sais parfaitement que ces limitations ont été mises en places dans le but de simplifier la programmation de projet de grosse envergure pour ceux qui n'ont pas une formation poussée de développeur. C'est dommage, quand on sait ce qu'on pourrait faire...

Au fait y'a t'il vraiement des projets de grosse envergure developpés avec .net ?

Qqn aurait a t'il participé a ce type de projets et et pourrat t'il nous faire partager son experience de developpement ?

Je suis curieux de connaitre les reponses, car je ne suis vraiement pas certain que des "gros" projets .net ( + qq millier de classes, differents connecteurs de services, ... ) existent aujourd'hui.

[jazz matazz]

Je sais parfaitement que ces limitations ont été mises en places dans le but de simplifier la programmation de projet de grosse envergure pour ceux qui n'ont pas une formation poussée de développeur. C'est dommage, quand on sait ce qu'on pourrait faire...

Au fait y'a t'il vraiement des projets de grosse envergure developpés avec .net ?

Qqn aurait a t'il participé a ce type de projets et et pourrat t'il nous faire partager son experience de developpement ?

Je suis curieux de connaitre les reponses, car je ne suis vraiement pas certain que des "gros" projets .net ( + qq millier de classes, differents connecteurs de services, ... ) existent aujourd'hui.

MediaPortal, logiciel Media Center, est un gros projet dévellopé en .net.
Je n'ai pas programmé pour MediaPortal, mais ce logiciel open-source est en constante évolution depuis 1an et demi, et c'est un énorme projet. Je sais qu'ils ont eu souvent des déboires de code, mais je sais pas si ça aurai été pareil ou pas avec une autre technologie. Le résultat aujourd'hui est plutôt beau! Même si ça ne reste toujours qu'une version bêta...

[Keihilin]

* C# n'est pas un langage 100% objet. Il y manque une composante indispensable, qui fait facilement 50% de la puissance de l'objet c'est L'Héritage Multiple. Ceux qui répondront "les interfaces ça fait la même chose" ont bien appris leur leçon, mais ils ne savent pas de quoi ils parlent.

On ne va pas refaire un débat qui a déjà eu lieu 100 fois. Si C# ne supporte pas l'héritage multiple il y a une bonne raison. A chaque fois que le débat a lieu, on ne trouve qu'un ou deux intégristes pour nous dire que c'est une fonctionnalité indispensable, mais je n'ai jamais vu quelqu'un faire une démonstration claire de la suprême utilité de cette fonctionnalité. Par contre, la preuve de sa relative inutilité à déjà été faite maintes fois.

* Dans la même veine : le framework .Net a des classes 'sealed' et 'internal', qui sont des notions complètement anti-objet. Pourquoi cacher des choses alors que le principe même de l'objet est la composition par héritage ? Sans doute à cause de vieux réflexes procéduraux, ou pour cacher des API instables.

N'importe quoi ! Le raisonnement derrière cette affirmation est tellement obscur que j'ai de la peine à trouver quelque chose à répondre.

A la limite, je veux bien admettre que "sealed" bloque un peu le paradigme de l'héritage, mais quand tu connais le coût d'un appel à une classe virtuelle et les gains de perfs possibles en permettant au compilateur d'"inliner", c'est pas plus mal que cela existe.

Mais alors dire que "internal" c'est "anti-objet"...il faut que tu m'expliques là. Tu voudrais pas supprimer "private" aussi non ?

* Le Framework est tout plat !! 90% des objets dérive de 'Object', ce qui est complètement idiot. Tellement d'objets ont de points communs, il aurait fallu une structuration beaucoup plus hiérarchique et une réflexion globale, et pas une bête traduction des WinAPI sous une couche pseudo-objet.

Tout le monde sait qu'une hiérarchie d'objets à 13 niveaux c'est le top du top de l'architecture...Continue comme ça, c'est bien.

Je sais parfaitement que ces limitations ont été mises en places dans le but de simplifier la programmation de projet de grosse envergure pour ceux qui n'ont pas une formation poussée de développeur.

Tu ne serais pas "deux fois certifié Java" par hasard ? Ce genre de remarques me fait furieusement penser à quelqu'un...

[Mose]

... Si C# ne supporte pas l'héritage multiple il y a une bonne raison... mais je n'ai jamais vu quelqu'un faire une démonstration claire de la suprême utilité de cette fonctionnalité. Par contre, la preuve de sa relative inutilité à déjà été faite maintes fois.

Facile.
- Je fais une appli winform qui utilise des controles. Mais les controles de base me suffisent pas, je veux les étendre.
- Dans tous mes controls j'utilise un objet 'context', qui contient un jeu d'icones et de Font, pour modifier l'interface au runtime + une dizaine de méthodes partagées par tous les objets 'WithContext'.
- Avec l'héritage multiple, je fais un objet 'ObjetWithContext', et j'en fais hériter chaque control pour en faire sa version 'WithContext'. Je fais un override si besoin pour adapter les méthodes, et basta.
- Avec les interfaces, je suis obligé de recoder mon champs 'Context' et mes 10 fonctionnalités à chaque control (Copier/coller... beeeeeurk).
Gain de temps : colossal. Et je te parle même pas du jour où les specs change (ex: maintenant on n'utilise plus du tout le context). L'héritage c'est quand même plus propre que le refactoring.

A la limite, je veux bien admettre que "sealed" bloque un peu le paradigme de l'héritage, mais quand tu connais le coût d'un appel à une classe virtuelle et les gains de perfs possibles en permettant au compilateur d'"inliner", c'est pas plus mal que cela existe.

Non, mais je suis curieux. Tu as des chiffres ?
Pour aller dans ton sens : c'est vrai que les outils puissant en développement ont un coût. Maintenant si les perfs sont ta priorité, remet-toi à l'assembleur : y'a pas mieux !

Mais alors dire que "internal" c'est "anti-objet"...il faut que tu m'expliques là. Tu voudrais pas supprimer "private" aussi non ?

Rien à voir. D'ailleurs pourquoi le mot 'internal' a été inventé, alors que 'private' suffit dans la plupart des cas ?
Ce que je reproche à 'internal', c'est d'ajouter une dimension 'physique' (les DLL) dans un univers conceptuel (le code).
Je ne râle pas pour le principe, mais parce que ça m'a déjà cassé les noisettes une paire de fois.

Tout le monde sait qu'une hiérarchie d'objets à 13 niveaux c'est le top du top de l'architecture...Continue comme ça, c'est bien.

C'est vrai ça. D'ailleurs pourquoi on a inventé l'héritage ? C'est cause d'erreur ! Et d'ailleurs pourquoi dans une entreprise tout le monde ne dépend pas directement du patron ?

Tu ne serais pas "deux fois certifié Java" par hasard ? Ce genre de remarques me fait furieusement penser à quelqu'un...

Perdu. Je n'ai jamais fais de Java. J'ai toujours bossé avec .Net, pour et avec Microsoft. Si ne ne défend pas mon beefsteak c'est paske je suis plus un techi qu'un homme d'affaire.

[Keihilin]

- Je fais une appli winform qui utilise des controles. Mais les controles de base me suffisent pas, je veux les étendre.

- Avec les interfaces, je suis obligé de recoder mon champs 'Context' et mes 10 fonctionnalités à chaque control (Copier/coller... beeeeeurk).
Gain de temps : colossal. Et je te parle même pas du jour où les specs change (ex: maintenant on n'utilise plus du tout le context).

Voui voui voui. Et avec la composition c'est pas possible de faire ça ? Bien sûr que si; et sans forcément se taper 1'000 lignes de code supplémentaires.

Non, mais je suis curieux. Tu as des chiffres ?
Pour aller dans ton sens : c'est vrai que les outils puissant en développement ont un coût. Maintenant si les perfs sont ta priorité, remet-toi à l'assembleur : y'a pas mieux !

Ben si tu veux des chiffres, tu les cherches sur Google. 3 ans de Dotnet et ne pas connaître l'incidence de l'inlining, c'est étrange.
Et puis je ne vois pas en quoi le fait de travailler avec un outil "puissant" devrait empêcher de penser aux performances.

D'ailleurs pourquoi le mot 'internal' a été inventé, alors que 'private' suffit dans la plupart des cas ?

Parce que il y a un manque évident entre "private" et "public". Une assembly c'est aussi conceptuel que du code...et des cas ou l'on veut partager quelque chose à l'intérieur d'une assembly (disons d' un composant si cela te parles plus) sans pour autant rompre l'encapsulation, il y en a des tas.

C'est vrai ça. D'ailleurs pourquoi on a inventé l'héritage ? C'est cause d'erreur ! Et d'ailleurs pourquoi dans une entreprise tout le monde ne dépend pas directement du patron ?

Superbe exemple. Navré de te dire ça, mais ne jurer que par l'héritage d'implémentation (multiple si tu pouvais) ça ne démontre qu'une chose : ton côté "techni", tu devrais un peu plus le cultiver...Ca te rendrait un peu plus agnostique...

L'héritage d'implémentation ne définit pas à lui tout seul la POO. D'autre part, il peut facilement conduire à des abhérations sémantiques ou à des couplages forts gênants la maintenance.

[Deadpool]

Tu ne serais pas "deux fois certifié Java" par hasard ? Ce genre de remarques me fait furieusement penser à quelqu'un...

Par contre toi tu m'as l'air d'être carrément anti-java si j'en juge par cette citation et ta signature.

[Keihilin]

Tu ne serais pas "deux fois certifié Java" par hasard ? Ce genre de remarques me fait furieusement penser à quelqu'un...

Par contre toi tu m'as l'air d'être carrément anti-java si j'en juge par cette citation et ta signature.

Non non, pas plus que ça. Faut prendre ma signature au second degré...

[JolyLoic]

On ne va pas refaire un débat qui a déjà eu lieu 100 fois. Si C# ne supporte pas l'héritage multiple il y a une bonne raison. A chaque fois que le débat a lieu, on ne trouve qu'un ou deux intégristes pour nous dire que c'est une fonctionnalité indispensable, mais je n'ai jamais vu quelqu'un faire une démonstration claire de la suprême utilité de cette fonctionnalité.

Je ne sais pas si ma démonstration sera claire ou suprême, mais voici mon avis. Pour supporter la programmation par contrat, il faut, dans une version simplifiée, que les fonctions virtuelles des classes dérivées ne cassent pas le contrat établi par les classes de base.

Si l'on veut vérifier ça dans le code et dans un langage où de telles fonctions ne sont pas codées en dur, le plus classique est de définir en public des fonctions non virtuelles (donc non modifiables) qui vont vérifier les précondition, appeler la fonction virtuelle privée (pour qu'on ne puisse pas l'appeler sans la vérification de contrat), puis vérifier les post-conditions.

Ce type de méthode demande donc la possibilité de mettre du code d'instrumentation au niveau de l'interface, et non seulement au niveau des classes dérivées.

Les raisons que je vois pour ne pas permettre l'héritage multiple sont que c'est compliqué pour la personne écrivant le compilateur, et éventuellement pour l'apprentit développeur (s'il y a en d'autres, merci de me donner une url).

Ce qui est amusant, c'est que pour l'utilisation à laquelle je tiens assez, ce n'est plus compliqué du tout : Quand on ne peut définir que des fonctions non virtuelles dans la classe de base, il n'y a plus de problèmes d'implémentation (héritage en diamant...).

[Maniak]

mais je n'ai jamais vu quelqu'un faire une démonstration claire de la suprême utilité de cette fonctionnalité. Par contre, la preuve de sa relative inutilité à déjà été faite maintes fois.

D'autant qu'avec la composition on se débrouille très bien pour les cas où un héritage multiple aurait pu servir.
J'ai rien contre avoir un langage qui gère ça, pour peu que ce soit bien géré, notamment le cas habituel du conflit qui arrive forcément un jour ou l'autre. Et les langages qui gèrent ce cas-là correctement... à part Eiffel, y a quoi ? :)

A la limite, je veux bien admettre que "sealed" bloque un peu le paradigme de l'héritage, mais quand tu connais le coût d'un appel à une classe virtuelle et les gains de perfs possibles en permettant au compilateur d'"inliner", c'est pas plus mal que cela existe.

Même pas besoin de parler de perfs.
Si une classe n'est pas faite pour être dérivée (et le principe de la POO n'est pas que tout soit dérivable), on l'indique clairement. D'où l'intérêt de sealed. Avec ça, pas de doute possible.

C'est aussi l'intérêt de devoir choisir quelles sont les méthodes virtuelles plutôt que de tout avoir par défaut (oui, c'est le cas en Java, et je suis loin d'être sûr que ce soit un bon point de ce langage :)

Je sais parfaitement que ces limitations ont été mises en places dans le but de simplifier la programmation de projet de grosse envergure pour ceux qui n'ont pas une formation poussée de développeur.

Mmh nan, ça c'est surtout la raison d'être des divers assistants à deux balles qui génèrent/poussent à faire du code particulièrement abominable.

Ce que je reproche à 'internal', c'est d'ajouter une dimension 'physique' (les DLL) dans un univers conceptuel (le code).

D'où l'intérêt d'organiser ses assemblages à un niveau conceptuel aussi. C'est sûr que si tu organises ça n'importe comment, l'intérêt devient tout de suite plus flou.

D'ailleurs pourquoi on a inventé l'héritage ? C'est cause d'erreur !

Ah, j'aurais cru que c'était pour le polymorphisme :)

Et d'ailleurs pourquoi dans une entreprise tout le monde ne dépend pas directement du patron ?

Parce que tout le monde n'est pas un patron.

[Maniak]

Ce qui est amusant, c'est que pour l'utilisation à laquelle je tiens assez, ce n'est plus compliqué du tout : Quand on ne peut définir que des fonctions non virtuelles dans la classe de base, il n'y a plus de problèmes d'implémentation (héritage en diamant...).

Il y a toujours un problème si deux des classes dont on hérite ont des méthodes avec signatures identiques. Même si elles ne sont pas virtuelles, elles sont quand même accessibles, donc conflit pour savoir laquelle prendre :)

Cela dit la discussion est un peu hors sujet. C# ne fait pas de programmation par contrat, si ça finissait par le faire, ce serait de toute évidence via les attributs, et Aspect# n'est pas encore intégré :)

[vosaray]

MediaPortal, logiciel Media Center, est un gros projet dévellopé en .net.
Je n'ai pas programmé pour MediaPortal, mais ce logiciel open-source est en constante évolution depuis 1an et demi, et c'est un énorme projet. Je sais qu'ils ont eu souvent des déboires de code, mais je sais pas si ça aurai été pareil ou pas avec une autre technologie. Le résultat aujourd'hui est plutôt beau! Même si ça ne reste toujours qu'une version bêta...

Merci pour l'info, j'ai tenté de verifier ca, mais curieusement, sur leur site on ne peut pas telecharger le source alors qu'ils se reclament open source et que le soft est sous GPL .

Difficile d'evaluer la taille du source et la complexité de la solution dans ces conditions...

[Maniak]

aaaaaaah j'ai oublié un truc auquel je voulais absolument répondre :)

L'héritage c'est quand même plus propre que le refactoring.

Sur quelle planète, ou plutôt dans quel univers, est-ce que l'héritage et le refactoring ont ne serait-ce qu'un rapport vaguement éloigné qui permettrait de les comparer ? :)

C'est là qu'on se demande si tu sais de quoi tu parles. Dans le cas du refactoring, clairement, non.

[Thomas Lebrun]

aaaaaaah j'ai oublié un truc auquel je voulais absolument répondre

L'héritage c'est quand même plus propre que le refactoring.

Sur quelle planète, ou plutôt dans quel univers, est-ce que l'héritage et le refactoring ont ne serait-ce qu'un rapport vaguement éloigné qui permettrait de les comparer ?

C'est là qu'on se demande si tu sais de quoi tu parles. Dans le cas du refactoring, clairement, non.

Entierement d'accord: l'héritage et le refactoring sont 2 notions complétement différentes qui n'ont rien à voir l'une avec l'autre

[grigann]

Merci pour l'info, j'ai tenté de verifier ca, mais curieusement, sur leur site on ne peut pas telecharger le source alors qu'ils se reclament open source et que le soft est sous GPL :?

Euh, les projets open source fonctionnent quasiment tous à partir d'un repo CVS ou SVN. Un peu comme là quoi : http://cvs.sourceforge.net/viewcvs.py/mediaportal/

[Mose]

* Pour répondre à Keihilin :
- Désolé, le ton de mes mails (après relecture) était un peu sec, je l'avoue (limite fasciste). Ca c'est pour la forme.
- Sur le fond, je maintiens tout ce que j'ai dit et je pourrais discuter longuement avec toi de chacun de ces points. Visiblement, nous ne conceptualisons pas les choses de la même façon. Je ne prétend pas que le mien est "mieux" (ça veut rien dire), mais il s'appuie sans doute plus sur la théorie informatique pure, ce en quoi je lui voit plus d'avenir (c'était le sujet du post). Je te propose qu'on continue à en discuter en privé.
- Une petite note en passant : j'ai vu ton site sur lequel le mec prétend démontrer que l'héritage c'est pourri, et je répondrai que oui, on peut tout démontrer à partir d'un mauvais exemple. (Mais là j'ai vraiment pas envie de me battre pour des conneries)

* Pour répondre à Maniak sur le lien entre l'héritage et le refactoring :
- Le refactoring c'est l'automatisation de la modification de code.
- L'héritage entre autre utilités, permet découper une implémentation en fragments qui permettent une souplesse au code. (notamment quand il faut faire des modif).
Maintenant, tu pourras toujours argumenter que ça n'a rien à voir. Dans la pratique avec un modèle objet souple, t'as quasiment jamais besoin de refactoring. (Ca va encore faire 10 tonnes de blablabla, pask'on n'a pas la même notion de ce qu'est un modèle objet souple... pffff...)

Bref, avant que vous ne vous déchainiez à nouveau sur vos clavier pour critiquer quelqu'un qui pense différemment, je précise qu'il y a plusieurs écoles, que vous ne me convaincrez pas comme je ne vous convaincrez pas, et que ça sert à rien de perdre du temps à se cracher dessus par forums interposés. L'avenir répondra à tout ça.

---- L'absolu c'est ce qu'on crois être absolu ---

[Keihilin]

- Désolé, le ton de mes mails (après relecture) était un peu sec, je l'avoue (limite fasciste).

Content que tu t'en sois rendu compte...Oublions donc ça.

- Une petite note en passant : j'ai vu ton site sur lequel le mec prétend démontrer que l'héritage c'est pourri

Non, le sujet de l'article n'est pas "l'héritage c'est pourri"...
L'héritage d'implémentation est bien entendu une technique qui répond à un certain nombre de problèmes, mais elle comporte également des pièges qui donne lieu à des architectures moyennement bonnes si l'on ne fait pas attention. Je crois que l'auteur de l'article reste très objectif dans ses exemples; le message n'étant pas : "il faut éviter l'héritage", mais plutôt : "connaissez ses faiblesses et les alternatives".

Bref, avant que vous ne vous déchainiez à nouveau sur vos clavier pour critiquer quelqu'un qui pense différemment, je précise qu'il y a plusieurs écoles, que vous ne me convaincrez pas.

Je ne te reproches pas de ne pas penser la même chose que moi. Je te reprochais le ton "intégriste qui ne se prend pas pour une merde" de ton premier message. Ok, je ne pourrais pas te convaincre, mais demande-toi quand même pourquoi Gosling, Box ou Fowler ne partagent pas ton point de vue...

[vosaray]

Merci pour l'info, j'ai tenté de verifier ca, mais curieusement, sur leur site on ne peut pas telecharger le source alors qu'ils se reclament open source et que le soft est sous GPL

Euh, les projets open source fonctionnent quasiment tous à partir d'un repo CVS ou SVN. Un peu comme là quoi : http://cvs.sourceforge.net/viewcvs.py/mediaportal/

Oui sauf que la il n'y a pas un seul fichier source, et que la plupart des fichiers ont une revision de 1.1 ( soit initiale ).

Bon j'avoue que j'ai browsé toute l'arbo ( mais un peu tout de meme ) et mis a part des dll, qq fichiers xml et un tas de sources d'icones ( .psd photoshop ) y'a pas un bout de .net sur le serveur.

Par ailleurs, ce fameux soft ne semble pas fonctionner correctement ( essayé sur 2 PC differents, avec des configs ultra standard ( i.e une nvidia video et une Pinnacle TV ), ca donne que dalle ....

Pour conclure je pense que c'est pas un exemple terrible.

Et comme personne ne releve le défi, j'en conclu que des "gros projets" , "qui marchent" , en .net, faudra attendre longtemps pour voir ...

A mon avis toute discussion sur l'avenir d'une techno, sans analyser un cas pratique en detail, et sans argumenter vis a vis de la solution implementée, reste sterile et inutile. ( un peu comme .net pour moi )

[Maniak]

- Le refactoring c'est l'automatisation de la modification de code.

Hum... non ? :)

Indice : http://www.refactoring.com/
C'est le premier paragraphe.
Ah aussi, achète le bouquin.

Et donc non, ce dont tu parles n'a rien à voir avec le refactoring.

- L'héritage entre autre utilités, permet découper une implémentation en fragments qui permettent une souplesse au code. (notamment quand il faut faire des modif).

Hum... non ? :)

Ça ne découpe rien, ça *regroupe* un traitement commun entre classes qui partagent un même 'concept'.
(et d'ailleurs ça peut rendre le code sacrément rigide si c'est mal pensé :)

Pour découper une implémentation en fragments, c'est la composition. Et là encore, c'est pas vraiment un découpage, mais une meilleure répartition des responsabilités.
Cf http://c2.com/cgi/wiki?search=inheritance pour plein de discussions sur l'héritage, dont l'héritage multiple d'ailleurs.

Maintenant, tu pourras toujours argumenter que ça n'a rien à voir.

À ce niveau-là je n'argumente pas, j'affirme (et pourtant je fais mon possible pour éviter ça en général :). Mais c'est uniquement parce que ta définition du refactoring est complètement à côté de la plaque :)

Dans la pratique avec un modèle objet souple, t'as quasiment jamais besoin de refactoring.

Non vraiment, il faut que tu trouves le bon terme à utiliser pour ce dont tu parles, parce que là ça ne va pas :)
Le refactoring est là pour améliorer le design sans changer son comportement. Justement pour arriver au design le plus souple possible.
Si tu arrives à ça sans refactoring, faut donner la recette hein, tu deviendras rapidement riche et célèbre pour avoir donné tort à un paquet de gens aussi connus qu'ils sont bons (à savoir très :)

(Ca va encore faire 10 tonnes de blablabla, pask'on n'a pas la même notion de ce qu'est un modèle objet souple... pffff...)

Loin de là. Ça tient en un lien :
http://www.domaindrivendesign.org/book/index.html
Colonne de gauche, lien "Download the DDD Pattern Summaries.". Prends ça et va voir "Part III - Supple Design"
Ah aussi, achète le bouquin.

Bref, avant que vous ne vous déchainiez à nouveau sur vos clavier pour critiquer quelqu'un qui pense différemment, je précise qu'il y a plusieurs écoles, que vous ne me convaincrez pas comme je ne vous convaincrez pas, et que ça sert à rien de perdre du temps à se cracher dessus par forums interposés. L'avenir répondra à tout ça.

Fowler, Evans, Cunningham et tous ces gens bien travaillent justement à organiser cet avenir (sachant que leur présent est déjà un lointain avenir pour un paquet de gens).
Ils établissent un vocabulaire pour que les dévs puissent parler la même langue, essayent d'unifier les diverses communautés de dévs autour des mêmes notions, et globalement font de leur mieux pour que le boulot de tout le monde soit à la fois plus simple, plus agréable et plus efficace.

Maintenant à toi de voir si tu veux rester braqué sur ce que tu crois savoir (genre la définition du refactoring :) en refusant d'admettre que d'autres pourraient en savoir davantage, soit tu te rends compte que le développement, c'est plus grand que toi, et tu accordes un peu plus de valeur à ceux qui maîtrisent *vraiment* ce dont ils parlent.

Pas moi hein, Fowler & co :)
Moi je suis justement passé par de nombreuses séances de remise en question de ce que je croyais savoir, après avoir découvert ce qu'il en était réellement. Mais pour se remettre en question, il faut d'abord savoir admettre que beaucoup de choses qu'on croit au départ sont des conneries.

(et c'est particulièrement valable pour ceux qui sortent de fac ou autres écoles :)

À toi de me dire si tu considères que ta définition du refactoring est plus ou moins correcte que celle de Fowler. Pas de la mienne, je n'en ai pas. Fowler l'a popularisé, je m'en remets à la sienne. Il arrive un moment où il faut arrêter de vouloir tout faire à sa sauce, et commencer à travailler avec les autres.