Ok immaginons...Envoyé par Morpheus
Résultat, dans le framework on trouve des classes dont on ne peut pas hériter. Et c'est un peu bloquant !
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ok immaginons...
Résultat, dans le framework on trouve des classes dont on ne peut pas hériter. Et c'est un peu bloquant !
Disons que çà oblige à aller fouiller par Reflection dans ces classes protégées pour comprendre leur construction et afin d'implémenter soi- même ce qu'on a besoin de dériver (donc plutôt les interfaces judicieusesOk immaginons...
Résultat, dans le framework on trouve des classes dont on ne peut pas hériter. Et c'est un peu bloquant !) en conséquence du travail supplémentaire n'est-ce pas
Même pas :
Une classe A du framework utilise une classe B du framework. La classe B n'est pas dérivable.... je suis bloqué, il faut que je trouve une autre façon qui n'est pas dans l'esprit OO !
Poste ta question sur ce Forum Général Dotnet, en apportant les précisions necessaires, nous essaierons de débrouilller, avec toi, ton affaire de la façon la plus propre possible
Pourquoi pas, ça peut être interessant de manière générale...
mais comme il s'agit d'un développement professionnel, je suis passé à autre chose depuis et j'ai trouvé une solution moins belle. J'avais pas trois jours à passer sur une c**rie comme ça !
Pour en revenir au choix du langage,
Ne trouvez-vous pas que la donne a sensiblement évolué avec .NET 2.0 et VS 2005 ?
Aprés 2 bonne année de C# je me suis remis récement à faire un petit utilitaire pour oracle en VB.NET. Et coté VB.NET il y a quand même un espace de nom qui est d'une puissance est d'une simplicité d'utilisation déconcertante c'est le fameux my
Fini les dizainnes de lignes de code pour les opération usuelles sur un fichier, récupération des paramètres utilisateurs en un clin d'oeil, etc...
http://webman.developpez.com/articles/vbnet/2005/my/
Difficile de dire comme on l'a dit avec .NET 1.* "VB.NET ou C# c'est juste un histoire de syntaxe". Certes on peut toujours faire les même chose en C# et en VB.NET, certes ce que l'on peut faire avec le "my" on peut le faire en C# (mais avec plus de code).
Mais même l'IDE de microsoft ne se comporte pas de la même manière en vb.net et en C#. Quand on est en VB.NET je regrette par exemple qu'on ai pas toutes les fonctionnalitées de reflexion de l'IDE que l'on a quand on code en C#. Par exemple créer un accesseur sur un membre privé d'une classe :
-C# : 3 clics
-VB.NET : code
Alors que créer un accesseur en VB.NET demande plus de code qu'en C# !
Coté snippets, alors que les snippets VB.NET sont trés nombreux, en C# on a trés peu de snippets (de base avec l'IDE) alors que justement le C# aurrait besoin de plus de snippets pour compenser le my de C#.
Bref on peut toujours faire les même choses en C# et en VB.NET mais suivant le langage et le type d'application on sera plus ou moins productif avec l'un ou l'autre.
Pour tout ce qui est bibliothèques de classe C# me semble plus productif notamment grace aux fontionnalitées avancés de l'IDE en therme de reflexion, mais coté Interface utilisateur VB.NET semble nettement plus productif grace à my et ses multiples snippets.
Franchement sur une application 3 tiers je me demande si le mieux serait pas faire la partie data et métier en c# et la partie UI en VB.NET
Tu veux parler de ce fabuleux point d'accès global à plein d'objets et de ressources qui permet de coupler n'importe quelle partie de l'appli à des données qu'il aurait mieux valu découpler pour ne pas se retrouver avec un gros boxon intenable ?
C'est vraiment pas le truc qui me manque en C# non. Qu'ils laissent ça dans VB.NET, merci :)
Ça c'est le truc que je pige pas. J'ai vu plusieurs exemples des exploits de My qui permet de simplifier à mort des opérations comme copier/renommer/lire un fichier. Que des opérations qui sont des méthodes statiques sur la classe File.
Ce namespace n'est qu'un wrapper qui rend accessible globalement des choses qui devraient normalement être limitées à certaines parties de l'appli. Non seulement je ne vois pas l'intérêt (si, accélérer le dév de petites applis à la con, comme d'hab), mais je vois surtout les inconvénients vis-à-vis du code final...
Après pour ce qui est du comportement de l'IDE en fonction des langages... j'en suis là :
- IDE C# seul -> vivable.
- IDE C# + ReSharper (+VAssistX) -> miam.
- IDE VB.NET -> "mais pourquoi je suis puni ? j'ai rien fait de mal !"
Manaik, personne ne t'oblige à utiliser my.
Si dans ton esprit ça mélange tout ne l'utilise pas
Mais tu m'enlèveras pas de l'idée que le my permet de réaliser une multitude d'opération usuelles pour un développeur de mannière simplifié.
Quand je vois la mannière dont sont géré les settings en C# alors qu'en vb.net il suffit de faire :
pour récupérer la valeur d'un paramètre.
Code : Sélectionner tout - Visualiser dans une fenêtre à part my.setting.masetting
J'ai beau cherché j'ai pas trouvé l'équivalent avec une simple méthode statique en C#.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Je dis pas que my est la solution a tout problème, mais quand on veut faire quelque chose simplement le recours à my peut faire gagner beaucoup de temps.
Par contre coté IDE c'est comme toi VS 2005 m'aime pas quand je fais du VB, je me demande si c'est pas à cause de choix du profil "développeur C#"
T'en fais pas pour ça :)
(mais hey, mon nom :)
Possible, pour certaines, mais c'est comme beaucoup d'autres simplifications. Ça peut être pratique dans certains cas, mais entre les mains de gens pas particulièrement disciplinés, ça fait encore plus de chances de se retrouver avec des abominations.
(cela dit, c'est peut-être mon environnement actuel qui me pousse autant à me méfier des trucs qui donnent encore plus d'armes aux bidouilleurs en herbe, pour qui le seul objectif est de pondre le plus vite possible un truc qui marchotte vaguement)
(cela dit, je ne suis pas sûr que cette méfiance ne soit pas justifiée de manière générale)
Et ça fait quoi au juste ? :)
(pas trop eu l'occasion de faire grand chose côté applis win, je présume que ça les concerne :)
Ah mais là je ne contredirai rien :) Quand on veut faire quelque chose simplement et rapidement, tous les raccourcis sont bons à prendre (bon, dans certaines limites quand même. rien dans cet univers ne peut justifier de ne pas activer option explicit *et* option strict)
Quand on veut/doit faire quelque chose de propre, béton, bien organisé, avec le moins de couplages possible, un truc qui donne accès à tout et n'importe quoi depuis n'importe où, j'ai une petite appréhension. À tort peut-être, mais jusque-là je n'ai rien vu qui puisse me pousser à voter pour My en tant qu'avantage du langage :)
(dans le même genre, je n'ai encore rien vu non plus qui puisse me faire considérer yield comme un avantage du C#)
(par contre les méthodes anonymes, miam. rien que ça, ça vaut 50 My :)
Le profil c'est juste le layout des fenêtres normalement. C'est pas ça qui va ajouter des fonctionnalités inexistantes côté VB :)
Je voudrai juste rebondir ce temoignage. Si je n' me trompe on peut faire la même chose avec Refactor! qui est gratuit :
http://msdn.microsoft.com/vbasic/dow...ools/refactor/
Celà dis moi j'utilise sytématiquement le snippet pour ça : prop + tab ( aussi bien en VB qu'en C# ) c'est super pratique.
De toute façon c'est une question d'habitude avant tout, les deux langages permettent de coder trés rapidement quand on est habitué ( alors que je trouvais l'intellisens du C# un peu faible en VS2003 ).
A ben oui forcément, tout l'interet du my se trouve dans les applications windows
On a beaucoup moins besoin d'avoir accés aux caractèristiques de la machinne cible sur une applis windows que sur une applis ASP.NET
Je comprend mieux ton point de vue Maniak
Concernant le plugin réfractor c'est une bonne nouvelle mais je ne comprend pas pourquoi ce genre de chose n'est pas intégré de base dans VS 2005.
... un peu comme les snippets C# ...
Vu que je me suis tapper les 24 pages de posts, je vais mettre mon avis.
La synthaxe VB, C# ben c'est une histoire de gout
La rapidité à codé avec une synthaxe ou l'autre euh je suis pas sur que la différence soit énorme. Et normalement on passe plus de temps à trouver le code à tapper qu'à le tapper...
J'ai programmé en C# et VB.Net
Je n'aime pas VB.Net pour ses options strict et explisit désactivé par défaut (tout le monde ne pense pas à les activés quand ils savent qu'elles existent)
L'absence des events dans IDE (on ne voit que les propriétés des controles dans l'environement graphiques) entk en 2003
Les vieux restes de VB6 des methodes qui sortes de nulle part (DateDiff,...)
Il y a plusieur défauts qui sont corrigé avec la version 2005 mais au boulot nous somme toujours sur la 2003
L'absence de surcharge d'opérateurs
Les commentaire XML
part contre le retour du acceder à une fenêtre sans l'instancier
ca me fait pas très POO
J'ai pas nous plus aimé l'obligation de mettre Overridable sur mes fonctions quand j'ai voulu hérité ma classe.(C'est parfois avec le temps qu'on se rencontre qu'on hériterais bien d'une classe et donc si le propriétaire n'y a pas penser ca peut etre génant...)
Je conseillerai aussi le C# car la synthaxe y est presque identique au langage c,c++,java, ...
Donc je pense que quand on doit se tapper des progamme en c , c++,jave + c# cela est assez aiser.
bon maintenant si vous avez des applications en VB 6 aussi a maintenir
Je trouve qu'il y a plus d'exemple en C# qu'en VB.Net donc ca me fait aussi pencher pour lui.
Part contre en VB ne pas devoir recompiler à chaque fois est pratique.
(Pour le Case : euh moi je trouve ca logique que se soit pas identique (heuresement que l'ide remet les majuscules ou alors je n'ose imaginer le nombre d'ortographes d'une même variable)
Qu'ouïs-je ???
Bon je veux bien qu'on trouve des défauts à VB, mais bon, si on ne connais pas le langage, on ferait mieux de ne pas dire des bétises monumentales, qui dénigrent VB...
VB .Net ne gère que les évènements des controles ???
Et AddHandler & RemoveHandler : C'est quoi ???
La surcharge d'opérateurs EST prise en charge par VB .Net 2005
Les commentaires XML AUSSI.
C'est quoi cette histoire de Heritables ?
Ce mot clé, n'existe pas !
L'ide ne remet pas les majuscules, bon sang... En effet, une variable peut s'écrire de 1000 facons différentes, et c'est pas moi qui m'en plaindrai : deux têtes valent mieux qu'une...(Pour le Case : euh moi je trouve ca logique que se soit pas identique (heuresement que l'ide remet les majuscules ou alors je n'ose imaginer le nombre d'ortographes d'une même variable)
Désolé si j'ai pu paraitre agressif, mais il me semblait avoir lu dans les règles des forums que les débutants ne devait pas poster sur les sujets qu'ils ne connaissaient pas. Et dans le choix d'un langage, ca me semble d'autant plus vrai.
Je me suis donc permis de remettre à leur juste place les éléments cités...
Selon moi, pour les versions les plus récentes de logiciels permettant de coder avec les langages qui font le sujet de ce débat, les différences en terme de performance sont minimes.
Par contre, les logiques de programmation sont bien distinctes, je m'en suis aperçu en passant de Vb.Net à C#, la transition s'est faite "dans la douleur".
Je pense que chacun devrait pouvoir choisir ses outils de programmation en fonction de sa logique, et non, comme c'est trop souvent le cas, etre obligé de s'adapter à une méthode de codage imposée.
Ah ? Quoi comme ?
Normalement, si le code VB.NET est bien fait, donc Option Strict+Explicit, pas d'utilisation des fonctions VB6 à deux balles etc, il n'y a aucune raison de ne pas utiliser la même 'logique de programmation'.
Maintenant, si VB.NET a été utilisé comme du VB6 avec un framework de plus, ça peut-être plus douloureux. Mais là c'est autant la faute du langage (pour autoriser ça) que du développeur (pour en avoir profité).
Quand je parle de logiques de programmation distinctes, c'est par exemple que la gestion des objets n'est pas la meme : en Vb.Net, le code du Form Designer est dans le meme fichier que le code fonctionnel tandis qu'en C#, ce derniers sont stockés dans 2 fichiers distincts.
De plus, j'ai pas d'exemples précis en tete, mais certaines fonctions concernant la gestion des objets ont le meme nom en C# et en VB.Net, mais les traitements associés sont légèrement différents.
Ce que je voulait dire c'est que chaque langage de programmation a sa propre logique de fonctionnement, il en découle donc une certaine logique de programmation.
J'espère avoir été plus clair dans mes propos que précédemment.
j'ai choisi le C# bien que je ne sois pas du tout contre les autres langages. c'est simplement que j'arrive du C et un peu C++, comme beaucoup de gens en general et que le C# vient tout de suite dans ce cas la, voila tout....
Ça c'est rien. Ce sont les classes partielles et c'est pipeau :)
De toute façon, sortir le code qu'on fait du fichier utilisé par le designer a toujours été une bonne pratique, déjà applicable (peu importe le langage) avant les classes partielles.
Distinction facile à gommer donc.
Marrant, en général c'est plutôt sur l'inverse que je tilte. Les fonctions qui ont le même comportement mais des noms différents (généralement entre VB.NET et le reste du monde :)
Mais dans l'absolu, je ne vois toujours pas en quoi le choix du langage (en tout cas entre ces deux-là) conditionne la façon de développer. Ils fonctionnent globalement pareil, et quand il y a des divergences, une des deux versions est généralement une mauvaise pratique, donc à ignorer de toute façon :)
Parfaitement, d'accord.Ça c'est rien. Ce sont les classes partielles et c'est pipeau
De toute façon, sortir le code qu'on fait du fichier utilisé par le designer a toujours été une bonne pratique, déjà applicable (peu importe le langage) avant les classes partielles.
J'ajouterai de plus que l'ami ShadowMoon doit faire une confusion car dans vb2005 le code du Designer est bien dans un autre fichier exactement comme en C#.
Chose que certaines personnes trés convenables apprécient beaucoup .Marrant, en général c'est plutôt sur l'inverse que je tilte. Les fonctions qui ont le même comportement mais des noms différents (généralement entre VB.NET et le reste du monde
Là encore je suis plutot d'accords, et je ne vois pas en quoi il faudrai appréhender un programme différement en VB.NET et C#.Mais dans l'absolu, je ne vois toujours pas en quoi le choix du langage (en tout cas entre ces deux-là) conditionne la façon de développer. Ils fonctionnent globalement pareil, et quand il y a des divergences, une des deux versions est généralement une mauvaise pratique, donc à ignorer de toute façon
Sinon Maniak tu vieillis ! A peine une petite critique sur VB.NET ...
La seule critique nécessaire sur VB.NET tient dans son nom : VB :)
Enfin je m'attendais surtout à ce que l'approche 'différente' entre VB.NET et C# dont il était question soit l'approche VB6, auquel cas il y aurait eu plein de choses à dire contre VB.NET. Mais non, même pas, snif :)
(penser à cocher cette foutue case pour virer les smileys)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager