Bonjour,
Question simple, dont je trouve pas la réponse :aie:
Comment faire :
C'est à dire utiliser tous les sous-espaces de noms de Espace2 ?Code:using Espace1.Espace2.*;
Merci.
Version imprimable
Bonjour,
Question simple, dont je trouve pas la réponse :aie:
Comment faire :
C'est à dire utiliser tous les sous-espaces de noms de Espace2 ?Code:using Espace1.Espace2.*;
Merci.
salut
Raccourcis impossible...
Tout doit être explicite :)
The Monz, Toulouse
Merci,
Ok, c'est ce que je craignais. C'est possible de crée un alias qui pointe vers plusieurs espaces de nom?
genre :Code:using test = Espace1.Espace2.t, Espace1.Espace2.e;
La réponse est non.
ça, c'est très chiant...:evilred:
Le using existe uniquement pour éviter d'avoir a taper namespace1.namespace2.nomdelaclasse...
Et les namespace existent pour pouvoir créer 2 classes de meme noms (si 2 dev ne se connaissent pas et utilisent le meme nom)
(et pour organiser proprement tout ca aussi.. Parce que l'on reste des humains)
Je vois plus l'intéret du namespace si c'est pour que tout le monde puisse faire using *.* :aie:
[edit] au passage il est possible de faire :
using Diagn = System.Diagnostics;
Ensuite il faudra taper : Diagn.Debug...
Bah je suis un peu d'accord avec toi, mais en java il est vrais qu'il est pratique de faire : package.*
Mais bon en même temps on a accés à plein de classe que l'ont utiliseras pas.
La en .Net on te force par la contrainte à apprendre que par exemple File appartient à System.IO
C'est dans le cas où tu utilises tes propres espaces de noms.Citation:
Envoyé par Chubyone
Par exemple, j'ai un package Materiel avec des sous packages Serveurs, Clients, ... Dans une classe gérant l'ensemble de ces matériels, je veux pouvoir les instancier.
Il est donc très pratique d'avoir accès à quelque chose de la formedans un contexte où l'espace de noms est crée par le développeur. Celà évite de les importer tous un part un.Code:using Materiel.*;
C'est surtout une source intarissable d'ambiguïtées.Citation:
Envoyé par dahtah
Pourquoi?Citation:
Envoyé par Bluedeep
Je trouve pas, c'est juste un moyen d'organiser son code, et de faciliter les imports. Tu as parfois besoin de l'ensemble des sous-packages.
Ha non c'est certain que c'est une source d'ambiguités.
En java qui te permet de faire ce genre de chose, on en abuse, et le compilo te dit :
"Ambiguité, qu'est ce que je fait, je prends cette classe ou cette classe comme référence"
Et puis comme dans les librairies en java tu as plein de classe ayant le même nom dans des package différents cela devient vite le bordel.
Au moins en .Net ce n'est pas le cas :D
Ce problème ne se pose normallement pas quand dans ton appli, tu as ton propre espace de nommage. C'est si tu fais plein d'imports de libraire que tu as ce genre de problème.Citation:
Envoyé par ced600
Je suis d'accord pour dire que dans l'ensemble des cas c'est pas top, mais pour une librairie perso, c'est pratique.
Enfin bref...
Si tu le dis je te crois, je n'ai pas assez d'expérience pour contredire tes propos en java. :aie:
En ce qui concerne ton problème, bah ce n'est pas possible en .Net désolé :(
Ben non, je ne suis pas d'accord.Citation:
Envoyé par dahtah
Les contraintes de namespace sont un moyen puissant d'organiser le code.
La capacité à passer outre cette contrainte, c'est plutôt un moyen de désorganiser le code :mouarf: IMNSHO
Euh, là, si je devais avoir besoin dans une assembly de la totalité de mes assembly, je me poserais de grosses questions sur l'architecture globale de mon projet et l'arbitrerais sans doute différemment. (je reconnais bien volontiers que je ne suis pas un expert en java, mais, autant que je le sache, je ne pense pas que les contraintes de ce point de vue soient sensiblement différentes).Citation:
et de faciliter les imports. Tu as parfois besoin de l'ensemble des sous-packages.
Par exemple, tu as un packet avec des sous packets où tu as les classes permettant de crée tes objets.Citation:
Envoyé par Bluedeep
ex :Plus loin tu as une classe chargé de les instancier (abstract factory par exemple...)Code:
2
3
4
Et bien dans ta classe déportée tu fais justeEn fait mon exemple est pourri, il fait penser à de l'héritage...:oops:Code:using Animal.*;
Imaginons qu'il y ait beaucoup beaucoup de chien chat et renard... et que la lisibilité des packets soit plus aisées ainsi. J'abandonne, je suis pas clair...
Tu voulais dire un truc comme cela.Code:
2
3
4
Et comme dans ton code tu fais une liste de chien, Chien étant la classe mère de tous les chiens tu veux faire un truc du genre :
maintenant dis moi, qu'est ce que ta classe mère ferait dans un namespace différent de ses enfants ?Code:using Animal.Chien.*;
Normalement tu devrais avoir :
et puis un truc comme :Code:using Animal.Chien;
Code:List.add(chien.roux);
Ce n'est pas exatement ca pour moi un namespace : vous cherchez a le définir EXACTEMENT par rapport à ce qu'il contient....
Un namespace ca doit permettre ca :
la Classe Chien est définit dans MyAnimal, héritant de l'interface IChien du namespace Animal.
Tu as fais un Chien toi aussi? qui Hérite de IChien de Animal?
Ok on change le using MyAnimal par YourAnimal.
Hop, on as besoin de rien faire d'autre pour utiliser la nouvelle classe.
Ok, c'est tout bete, mais avec des controlleur IOC comme Spring, il suffit de changer un nom de namespace dans un fichier XML pour changer toute l'appli de façon transparente.
C'est juste pour simplifier lea visibilité quand il y a beaucoup de classes chiens. Pour présenter la couche modèle de manière arborescente.Citation:
Envoyé par ced600
Je suis d'accord, mais quand il ya beaucoup de classes?Citation:
Envoyé par Chubyone
J'ai pas tout saisi, mais ça à l'air interressant. Peux-tu développer un peu plus.Citation:
Un namespace ca doit permettre ca :
la Classe Chien est définit dans MyAnimal, héritant de l'interface IChien du namespace Animal.
Tu as fais un Chien toi aussi? qui Hérite de IChien de Animal?
Ok on change le using MyAnimal par YourAnimal.
Hop, on as besoin de rien faire d'autre pour utiliser la nouvelle classe.
Ok, c'est tout bete, mais avec des controlleur IOC comme Spring, il suffit de changer un nom de namespace dans un fichier XML pour changer toute l'appli de façon transparente.
Non !!!! Je pensais me planter quand j'ai dit cela. C'est pas beau cela.Citation:
C'est juste pour simplifier lea visibilité quand il y a beaucoup de classes chiens. Pour présenter la couche modèle de manière arborescente.Citation:
Envoyé par ced600
maintenant dis moi, qu'est ce que ta classe mère ferait dans un namespace différent de ses enfants ?
Je ne dit pas des classes qui héritent d'une classe qui est dans une librairie. Tu ne peux pas faire autrement.
Mais lorsque c'est des classes de ta librairie qui héritent d'1 classe de ta librairie, tu mets tout cela dans le même namespace.
Enfin moi je vois que l'on crée un namespace par projet. Pour un même projet difficille de justifier plusieurs namespace.
En utilisant la reflexion tu peux choisir de quel namespace tu choisis d'instancier Chien...Citation:
Envoyé par dahtah
Mais bon, ca reste plus simple dans ce cas de choisir par rapport à l'assembly... (par que à la mano si on doit changer tous les using du projet -_- )
En fait le namespace est un niveau d'abstraction et de découpage au dessus de l'assembly : 2 projet peuvent travailler dans un seul meme namespace...
Par exemple : tu peux créer un projet avec le namespace System.Windows.Form qui contient des controls Winforms : ensuite en utilisant ce using tu les retrouveras...
Un namespace est un regroupement "logique" d'élément, mais inutile d'allez trop loin : c'est juste un découpement abstrait. Par exemple chacune de tes couches peuvent appartenir à un namespace View BLL DAL, etc.
Dans le meme projet tu as tous tes tests unitaires, t'as pas envie de les voir se mélanger à tes classes, alors tu les enfermes dans un namespace Tests...
Mais si tu pars dans l'optique : chacune de mes classes dans un namespace différents, t'es pas sortis :aie:
Je pense pas. Par exemple, dans une architecture MVC, il est conseillé d'avoir une couche par package (en Java).Citation:
Envoyé par ced600
Merci Chubyone pour tes éclaircissement.
Je crois que un projet en C# correspond à un package Java.C'est là où je me gourre.Si quelsu'un pouvait me dire si ce que j'ai fait est correct au sen .Net :Citation:
2 projet peuvent travailler dans un seul meme namespace...
J'ai un projet, trois espaces de noms (model, vue, controller). Ensuite ma couche model est divisée en plusieurs sous packages. Avec à la racine de model une abstract factory in stanciant les objets de mes sous couches.
En .Net, faut-il faire trois projet (Model, Vue, Controleur) dans un même gros projet (Application).
Promis, après ça je me tais... ;)
Nop un namespace n'est pas un package java.
Pour un modèle MVC pas besoins de plusieurs projets non plus. Mais ce serait plus juste de découpé chaque couche en projet plutot qu'en namspace.
Bah en général je fait :
Vue = Un projet.
MC = un projet. où je sépare bien d'un poinst de vue composant dans mon archi le M et le C.
Enfin je fait ainsi par ce que l'accés à mes données est simple.
Donc si tu veux bien découper en MVC, alors faut faire trois projets.
Mais dans ce cas là tes classes assurant la liaison entres la vue le controleur et le modèle sont des classes de type interfaces. Donc utilise plutot les interfaces, ce sera moins galère.
Un gros projet s'appelle une solution :D
Avec les bonne dénomination tout est plus clair.
1 Solution -> plusieurs projet -> un namespace par projet -> 1 ou plusieurs classes par projet.
En général c'est comme cela.
Non. L'équivalent d'un package java est une assembly en .Net. La notion de projet est orienté IDE (même si dans la pratique, un projet = assembly, mais il y a des exceptions). Néanmoins un assembly peut exposer autant d'espace de nom qu'il veut (contrairement à Java il me semble) et un espace de nom donné peut être étendu sur plusieurs assembly.Citation:
Envoyé par dahtah
Par obligatoirement, tu peux en mettre trois, un seul ou quarante deux mille huit (un espace de nom peut inclure plusieurs projet/assembly et l'inverses est vrai aussi). L'Espace de nom a pour finalité d'offrir une arborescence de présentation des classes, qui n'est absolument pas lié à l'arborescence d'héritage des dites classes.Citation:
J'ai un projet, trois espaces de noms (model, vue, controller). Ensuite ma couche model est divisée en plusieurs sous packages. Avec à la racine de model une abstract factory in stanciant les objets de mes sous couches.
En .Net, faut-il faire trois projet (Model, Vue, Controleur) dans un même gros projet (Application).
Promis, après ça je me tais... ;)
Par exemple, imaginons que j'ai deux espaces de noms :
- MyNameSpace
- MyNameSpace.MySubnameSpace
Je peux avoir un projet qui implémente des classes dans MyNameSpace, un autre qui en implémente dans MyNameSpace et dans MyNameSpace.MySubnameSpace, et un autre dans MySubnameSpace uniquement si je le désire.
Maintenat imaginons que j'ai une classe A dans MyNameSpace.MySubnameSpace, rien ne m'empêche de créer une classe B qui hértite de A dans MyNameSpace : il n'y a aucun lien entre les namespace et l'héritage des classes.
Oui c'est sur, mais je pense qu'il reste moins galère de faire un namespace par projet.
Sinon après faut bien maitriser ce que l'on fait, sinon c'est vite galère.
1 solution contient un ou plusieurs projet, qui sont au final des assembly : c'est le découpage "physique" de ton application.
Les namespace sont purement sémantique.
Tu peux avoir 2 projets Winforms différents (deux applications différentes) et un projet dll de User/CustomControls référencé par les 2 projets (ils utilisent les meme UserControls propre à ton appli)
Ils peuvent pourtant tous travailler sous le meme namespace : View.
Déjà fait,Citation:
Envoyé par ced600
Ok, merci,Citation:
Envoyé par ced600
Mais d'après ce que disait Chubyone :
1 solution -> plusieurs namespace -> plusieurs projets par namespace.Citation:
En fait le namespace est un niveau d'abstraction et de découpage au dessus de l'assembly : 2 projet peuvent travailler dans un seul meme namespace...
En fait la Solution est juste une organisation de tes projets : tu peux très bien avoir autant de solution que de projets et référencés les dll à la mano :aie:Citation:
Envoyé par dahtah
En fait je dirais qu'il faut oublier le namespace, il pourrait ce placer n'importe où :D
En fait c'est :
1 solution -> 1 ou x projets
Et tu peux placer le namespace où tu veux.
Quand tu regardes les namespaces de ms tu peux voir :
System.Collections.Specialized;
Collections contiens des piles, des arraylist, et des interfaces.
Spécialized contiens des collections spécialisé qui implémentent les interfaces de Collections.
Et à vérifier, mais is je ne me trompe pas Collections et Spécialized sont des namespaces et pas des objets de Systems.
Enfin j'ai jamais eu l'idée de créer une instance de Spécialized :D
PS : Je suis en framework 1.1, en 2.0 tu ne trouves plus la même organisation.
Exemple interessant, je vais regarder.Citation:
Envoyé par ced600
Un grand merci à tous.