Salut à tous,
 
Je débute en C# et je me pose quelques questions... J'ai regardé un peu sur le Net mais je n'ai jamais vraiment trouvé d'explications claires, je compte donc sur vous pour m'éclairer sur les points suivants :
 
1) Quelle est la différence entre :

et  

2) Quelle est la différence entre Collection<T>, List<T>, ICollection<T>, IList<T> ?
Si vous avez une bonne source qui explique ça, ça m'interesse.
 
3) N'ayant pas connaissance des autres options j'étais parti sur des Collections et j'aurais aimer créer ma propre class Collection et y ajoutant des fonctions de recherche sur Name (car toutes mes classes ont un attribut Name), mais je n'arrive pas à faire un truc générique, comment faire :
(De mémoire car je n'ai plus mon code sous les yeux)

Mais dans ce cas T.Name n'existe pas (logique) donc impossible de compiler.
 
En espérant que celà inspire certains d'entre-vous, merci d'avance pour vos réponses.

1/ Je ne saurais répondre, mise à part que dans le premier cas, l'allocation de mémoire pour l'objet liste se fait avant le déclenchement du contructeur. après aucune idée de l'impact, perso je préfère tout coller les déclarations dans le contructeur.

2/ Ixxxx c'est des interfaces. Donc d'entrée de jeu, c'est pas pareil que xxxx, qui est une classe, donc instanciable. Ensuite, entre Collection et List, c'est juste les méthodes qui sont différentes à l'intérieur. List est une liste chaînée. Collection est une collection, c'est à dire une sorte de array à dimension et indexation dynamique.
PS : Avec VS 2008, j'ai pas trouvé "Collection<T>", j'aiu peut-être mal cherché.

3/ Je passerait par une interface :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            collec<MaClasse> c = new collec<MaClasse>();
            c.Add(new MaClasse("A", 1));
            c.Add(new MaClasse("B", 2));
            c.Add(new MaClasse("C", 4));
            c.Add(new MaClasse("D", 8));
 
            Console.WriteLine(c.GetByName("C" ));
            Console.ReadKey(true);
        }
    }
 
    public class MaClasse : INamedClass
    {
        public int value;
        public string name;
 
        public MaClasse(string Name, int Value)
        {
            this.name = Name;
            this.value = Value;
        }
 
        public string GetName()
        {
            return name;
        }
 
        public override string ToString()
        {
            return string.Format("{0}\t= {1}", name, value);
        }
    }
 
    public class collec<T> : List<T>
    {
        public T GetByName(string Name)
        {
            foreach (T el in this)
            {
                if ((el as INamedClass).GetName() == Name)
                {
                    return el;
                }
            }
 
            return default(T);
        }
    }
 
    public interface INamedClass
    {
        string GetName();
    }
}

Grmpf, grillé. le "where T : Ixxx" est plus joli effectivement que mon truc ^^

Merci pour cette réponse rapide, je n'ai pas les moyens de tester ça au boulot mais je m'y remets ce soir.
 
Entre temps je vais trainer sur le Net bien comprendre les Interfaces car je pense que c'est ça qui m'échappe.

PS pour Harko : pourquoi cet empaffé de compilateur m'a refusé l'utilisation d'un filed dans une interface ??? J'ai été obligé de tout modifier pour utiliser une méthode GetName() à la place, ce qui est quand même moins sympa...

Une interface, c'est un contrat que tu imposes à ton objet qui en hérite.
 
Ainsi, tu impose à ton objet, dans l'exemple d'Harko, d'avoir une propriété "string Name", et dans mon exemple, une méthode "string GetName()".
Contrairement à un héritage de classe, tu peux hériter d'autant d'interfaces que tu veux. Genre tu peux hériter de l'interface d'Harko et de la mienne si tu veux.

System.Collections.ObjectModel ?
Pour ma part je suis sous C# Express (2005) et j'utilise le Framework 2.
 
En tout cas merci encore pour les réponses.
(Décidement ces interfaces, faut que je m'y mette )

Moi j'utilise "using System.Collections.Generic;" ça doit être pour ça

Ben j'ai du merder à priori, moi il me disait que j'avais pas le droit de mettre une proriété dans une interface (je crois que c'est le terme property qui était utilisé)

Correction : C'est bien de "field" qu'il est question :

(super la capture d'écran qui n'apporte rien... en fait, je suis en .NET 3.5 SP1 avec VS 2008 version "9.0.30729.4056 QFE" )

Ok, donc c'est une propriété qu'il faut
 
Bon, du coup c'est pas plus lourd avec mon exemple de GetName()

string Name { get; set; }

c'est pas beaucoup plus lourd que

string GetName();

(c'est pas exactement équivalent non plus: ça génère aussi un setter)

Ah mais ça j'ai pas dit le contraire
 
Juste que vu que j'ai fais avec un GetName(), c'est pas spécialement utile de passer par une propriété à la place, surtout pour un exemple.
 
Après, il y a le pour et le contre de Setter sous forme de méthode ou de propriété.

Fred82 > oups, depuis le début je te confond avec harko désolé ^^

string Name { get; set; }

Ce ne serait pas limité au framework 3 ce truc la ?
(Je parle de la synthaxe hein.)

Au framework non, au langage (C# 3.0) oui.

 
il me semble lavoir deja vu il y a quelques annés en c# 2, voir 1 (j'apppelais ca des attributs abstrait dans UML)

Il y avait des properties, mais pas les versions auto

Donc il fallait écrire ça:

string name;
string Name {
    get { return name; }
    set { name = value; }
}

edit:
voir en dessous, dans le cadre des interfaces kadreg a raison

Arf, je croyais que c'était un prototype le "string Name { get; set; }"

En fait, là il crée automatiquement le field privé + le getter et le setter ?

Si c'est le cas, ok, c'est carrément sympa comme raccourci !

Après plus de recherches, c'est les deux en fait en fonction du contexte (et donc kadreg a raison dans le cadre d'une interface):

• Dans une interface, ça déclare une property et son accessibilité ({get;} pour readonly, {set;} pour write-only et {get; set;} pour read-write) depuis ... longtemps (C# 1.0?)
• Dans une classe, ça déclare une automatic property (depuis C# 3.0)

Légère confusion de ma part donc.

Remplacer :

string Name;

 
Par :

string Name { get; set; }

 
Ca n'a effectivement aucun intérêt. Tout du moins, si on n'y touche plus après.
Habituellement, on n'aime pas les field public (y'a d'ailleurs un langage objet qui l'interdit).
En C#, un field est géré en interne de toute façon comme une propriété avec un set et un get par défaut (donc ça n'a aucun intérêt d'un point de vue performance ou autre de le faire explicitement)
 
En revanche, pour l'évolution du code, faire une propriété, c'est s'accorder la possibilité plus tard de modifier le get ou le set (voir les deux) sans devoir modifier la moitié du code de l'application, et contrôler à 100% l'impact que ça peut avoir.

• Si tu commences par utiliser des champs publiques, il faut tout recompiler si tu veux en faire des properties (pas juste la classe définissant le field/la property, mais aussi tous les callers)
• Le remplacement n'est pas transparent au niveau nommage, puisque les conventions C# sont camelCase pour les fields et PascalCase pour les properties (et methods)
• Un field ne peut faire partie d'une interface

Si tu utilises des properties, tu peux les faire évoluer par la suite et tu peux les mettre dans des interfaces

Les properties C# ne sont vraiment rien de plus que des getters/setters avec une syntaxe moins pourrie et (depuis 3.0) une déclaration triviale pour le cas dégénéré.

Afin de ne pas ouvrir un nouveau topic je poste ma nouvelle question ici :
 
J'ai une classe serialisable, je génère un fichier xml correspondant, j'ai un xls qui va bien. Mon but, sortir avec tout ça un fichier Word mis en page. Est-ce possible "simplement" ?
 
Merci d'avance.
 
Edit : j'ai peut-être trouvé http://www.codeproject.com/KB/offi [...] ports.aspx

J'ai une nouvelle question : dans une Form1 j'ai une liste de n objets, je souhaite que, lorsqu'on clique sur un objet, cela ouvre une seconde Form qui détaille l'objet en question. Pour cette partie, pas de problème particulier mais mon problème c'est que je veux qu'on ne puisse ouvrir qu'unê Form par objet. Donc si la Form de l'objet en queston existe déjà, je veux juste qu'elle repasse au premier plan.
 
Avez-vous une idée pour réaliser celà ?

Merci pour cette réponse. Effectivement j'ai compris le principe, je vais essayer de le mettre en application. Pour tester si la Form existe, le plus propre c'est quoi if(maForm == nothing) ?

Merci, faut que je regarde ça...

Je suis en train de tester mais finallement ça ne correspond pas tout à fait à ce qu'il me faut...
 
L'idéal serait de gérer, au sein de l'application, une List<Form> et d'y ajouter/retirer au fur et à mesure les forms que j'ouvre et je ferme.

J'identifie par un nom, unique, mes forms (ok c'est crade, si vous avez mieux...). Mais comment gérer la List<Form> correctement pour qu'elle soit unique mais accéssible de toutes les forms ouvertes ?

Le but c'est que j'ai une multitude d'objets différents, à chaque type d'objet je vais associer une FormX différente. Chacune des nouvelles form possèdera sa propre liste d'objet dont certains pourront être identiques à ceux de la liste principale. Donc chaque form devra permettre l'affichage d'un nouvelle objet mais chaque objet ne doit posséder qu'une form.
Le nombre d'objets étant important et variable, je pense qu'il est plus interessant de pouvoir ajouter/retirer un objet d'une collection plutôt que de gérer un tableau...
 
Qu'en penses-tu ?