Discussion :

[dahtah]

Bonjour,
Question simple, dont je trouve pas la réponse
Comment faire :

Code :

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

using Espace1.Espace2.*;

C'est à dire utiliser tous les sous-espaces de noms de Espace2 ?
Merci.

[theMonz31]

salut

Raccourcis impossible...

Tout doit être explicite

The Monz, Toulouse

[dahtah]

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 :

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

using test = Espace1.Espace2.t, Espace1.Espace2.e;

[dahtah]

La réponse est non.
ça, c'est très chiant...

[Chubyone]

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

[edit] au passage il est possible de faire :
using Diagn = System.Diagnostics;

Ensuite il faudra taper : Diagn.Debug...

[ced600]

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

[dahtah]

Je vois plus l'intéret du namespace si c'est pour que tout le monde puisse faire using *.*

C'est dans le cas où tu utilises tes propres espaces de noms.
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 forme

Code :

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

using Materiel.*;

dans un contexte où l'espace de noms est crée par le développeur. Celà évite de les importer tous un part un.

[Bluedeep]

dans un contexte où l'espace de noms est crée par le développeur. Celà évite de les importer tous un part un.

C'est surtout une source intarissable d'ambiguïtées.

[dahtah]

C'est surtout une source intarissable d'ambiguïtées.

Pourquoi?
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.

[ced600]

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

[dahtah]

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

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

[ced600]

Si tu le dis je te crois, je n'ai pas assez d'expérience pour contredire tes propos en java.
En ce qui concerne ton problème, bah ce n'est pas possible en .Net désolé

[Bluedeep]

Je trouve pas, c'est juste un moyen d'organiser son code,

Ben non, je ne suis pas d'accord.
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 IMNSHO

et de faciliter les imports. Tu as parfois besoin de l'ensemble des sous-packages.

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

[dahtah]

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

Par exemple, tu as un packet avec des sous packets où tu as les classes permettant de crée tes objets.
ex :

Code :

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

1
2
3
4
namespace Animal
namespace Animal.Chien
namespace Animal.Chat
namespace Animal.Renard

Plus loin tu as une classe chargé de les instancier (abstract factory par exemple...)
Et bien dans ta classe déportée tu fais juste

Code :

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

using Animal.*;

En fait mon exemple est pourri, il fait penser à de l'héritage...
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...

[ced600]

Code :

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

1
2
3
4
using Animal.Chien.roux;
using Animal.Chien.brun;
using Animal.Chien.belge;
using Animal.Chien.noix_de_coco;

Tu voulais dire un truc comme cela.
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 :

Code :

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

using Animal.Chien.*;

maintenant dis moi, qu'est ce que ta classe mère ferait dans un namespace différent de ses enfants ?

Normalement tu devrais avoir :

Code :

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

using Animal.Chien;

et puis un truc comme :

Code :

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

List.add(chien.roux);

[Chubyone]

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.

[dahtah]

maintenant dis moi, qu'est ce que ta classe mère ferait dans un namespace différent de ses enfants ?

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.

Ce n'est pas exatement ca pour moi un namespace : vous cherchez a le définir EXACTEMENT par rapport à ce qu'il contient....

Je suis d'accord, mais quand il ya beaucoup de classes?

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.

J'ai pas tout saisi, mais ça à l'air interressant. Peux-tu développer un peu plus.

[ced600]

Envoyé par ced600
maintenant dis moi, qu'est ce que ta classe mère ferait dans un namespace différent de ses enfants ?

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.

Non !!!! Je pensais me planter quand j'ai dit cela. C'est pas beau cela.
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.

[Chubyone]

J'ai pas tout saisi, mais ça à l'air interressant. Peux-tu développer un peu plus.

En utilisant la reflexion tu peux choisir de quel namespace tu choisis d'instancier Chien...
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

[dahtah]

Enfin moi je vois que l'on crée un namespace par projet. Pour un même projet difficille de justifier plusieurs namespace.

Je pense pas. Par exemple, dans une architecture MVC, il est conseillé d'avoir une couche par package (en Java).
Merci Chubyone pour tes éclaircissement.
Je crois que un projet en C# correspond à un package Java.

2 projet peuvent travailler dans un seul meme namespace...

C'est là où je me gourre.Si quelsu'un pouvait me dire si ce que j'ai fait est correct au sen .Net :
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...