Classe, Constructeur et objet, une question toute bête

Bonjour à tous,

Pour situer mon soucis, j'ai des notions en programmation construites d'après de multiples cours et tutoriels trouvés ici et là via internet mais certaines des notions, élémentaires pour les développeurs, m'échappent.
La plupart du temps, certaines de ces notions ne sont tout simplement pas expliquées ou alors expliquées arrivé au 3/4 d'un cours. Or, je suis incapable d'avancer correctement dans l'apprentissage d'un cours si je n'ai pas le contexte élémentaire clairement explicité.

Bref, je suis en train d'apprendre le C# et surtout sa logique et je me suis rendu compte que là où j'en étais j'étais incapable de savoir et de trouver réponse à ceci :

1. Est-ce qu'un objet est égal à TOUTE LA CLASSE dont il découle ? Donc en INCLUANT les variables et fonctions hors constructeurs.
   
2. Est-ce qu'un objet est égal à TOUS LES CONSTRUCTEURS de la classe dont il découle ? Donc EXCLUANT les variables et fonctions hors constructeurs.
   
3. Est-ce qu'un objet est égal à UN SEUL DES CONSTRUCTEURS de la classe dont il découle ?

Je suis persuadé que cela doit être évident pour la plupart d'entre vous mais pas pour moi.
Merci de ne pas répondre par du code, je cherche juste à comprendre la notion, je ne cherche pas d'exemple de code (si possible) mais juste une formulation de la règle qui est appliquée.
Merci pour votre aide :)

Un objet est souvent une instance d'une classe.
Les constructeurs, au sein d'une même classe, sont autant de moyen d'instancier le même objet.

La classe personne est une description (couleur de peau, type de cheveux). L'instance d'une personne est unique. A chaque personne sa couleur de peau et son type de cheveux... parce que tu le vaux bien!

la question ne veut pas dire grand chose
une classe c'est une description (variables, propriétés, méthodes ...)
une instance c'est un objet en mémoire répondant à cette description
le constructeur est la méthode appelée au moment d'instancier un objet, on peut avoir plusieurs constructeurs sur une classe, l'appelant (développeur) choisit laquelle il appelle

après les variables et propriétés appartiennent à l'instance, chaque instance a ses propres variables

En effet la question n'était pas correcte, je m'en suis rendu compte en discutant avec un ami développeur. Je n'avais pas bien compris ce qu'était un constructeur.

J'ai été trompé par le nom "constructeur" qui laisse entendre que le constructeur est en gros le "plan de construction" ou "la machine capable de créer" l'objet d'une classe.
Or ce n'est absolument pas ça, c'est une série d'actions qui seront exécutée au moment de la construction d'un objet découlant de la classe dont le constructeur fait parti.
Et c'est donc ce qui est HORS constructeur qui est conservé dans l'objet créé.

Je ne vois pas trop ce que tu appelles "hors".

Si tu parles du contexte des variables (globales et locales), que ce soit dans un constructeur ou toute autre méthode, seuls les attributs de l'objet (donc les variables définies au niveau de l'objet, ainsi que les propriétés) sont conservés en mémoire, et toutes les variables déclarées à l'intérieur de quel que bout de code que ce soit disparaît.

C'est valable aussi bien pour les constructeurs que les méthodes, mais aussi les accesseurs de propriétés :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

class Personne { // Propriétés, avec ou sans accesseur : une fois l'objet instancié, leurs valeurs sont conservées, tant qu'il y a un référence à l'instance. public string Nom; public string Prenom { get; set; } private string Civilite;   public string NomComplet { get { // Variable locale : dès qu'on sort du bloc entre accolade, elle est détruite et inaccessible. string tmp = string.Format("{0} {1} {2}", this.Civilite, this.Prenom, this.Nom); return tmp; } }   // Constructeur : accessible qu'au moment de la création d'une instance. N'est plus appelable une fois l'instance créée. public Personne(string civilite, string nom, string prenom) { this.Civilite = civilite; this.Nom = nom; this.Pernom = prenom; }   public void ChangerNom(string nouveaunom) { // Variable détruite à la sortie de la méthode string old = this.Nom; if (old != nouveaunom) { this.Nom = nouveaunom; } } }

---

Je sais pas si c'est plus clair comme ça.

Après, on parle pas des private, public, protected, sealed, static, etc.

Citation:

---

Envoyé par StringBuilder

Je ne vois pas trop ce que tu appelles "hors".

---

Je voulais dire ce qui est en dehors des accolades du constructeur et à l'intérieur de la classe.

Citation:

---

Envoyé par StringBuilder

Je sais pas si c'est plus clair comme ça.

---

Certaines choses oui, d'autres non mais c'est parce que je n'ai pas vu certains aspects que tu as utilisé. Comme l'intérêt et le fonctionnement du "this".
Et les get et set, j'ai vu brièvement.

Par contre, comment le développeur choisi le constructeur qu'il souhaite appeler s'ils ont tous le même nom (le même que la classe).
Par exemple s'il y a 2 constructeurs qui prennent en paramètre une chaine de caractères ?

this désigne l'instance qui exécute actuellement le code

quand tu créés un form en windows forms visual studio te créé une classe Form1
si tu poses un bouton et que tu veux coder dans l'event Click du bouton, tu peux écrire this.text = "test";
ce qui signifie l'instance du form actuelle
vu qu'il peut y avoir plusieurs instances de cette classe (donc plusieurs fois la même fenetre) ca n'agit que sur celle où le bouton a été cliqué


concernant les multiples constructeurs, si tu en écris 2 qui prennent chacun un string visual studio va te dire que tu n'as le droit, car justement il ne pourra pas déterminer lequel doit être utilisé
par contre si tu en fais un qui ne demande rien, un qui demande un string, et un qui demande 2 integer visual studio saura lequel tu appelles selon le nombre et le types des paramètres

Citation:

---

Envoyé par Pol63

quand tu créés un form en windows forms visual studio te créé une classe Form1
si tu poses un bouton et que tu veux coder dans l'event Click du bouton, tu peux écrire this.text = "test";
ce qui signifie l'instance du form actuelle
vu qu'il peut y avoir plusieurs instances de cette classe (donc plusieurs fois la même fenetre) ca n'agit que sur celle où le bouton a été cliqué

---

Je ne crées pas de Windows Form pour le moment et ça m'étonnerait que je m'y mette pour un projet de jeu (enfin je verrai).

Citation:

---

Envoyé par Pol63

this désigne l'instance qui exécute actuellement le code

---

En fait, j'ai du à mal comprendre parce que je ne comprends pas comment this accède à la bonne variable. Par exemple dans ton exemple de form, s'il y a 3 boutons, tu arrives à utiliser this en accédant au bouton voulu ?
Ou bien this n'est "utile" (perso je trouve que ça sème la confusion dans la lecture) que lorsque tu n'as qu'une seule instance ?
Ou alors this est là pour accéder à une instance qui va disparaitre ?
Désolé, c'est très difficle car je n'ai pas encore assimilé tout le vocabulaire et que j'ai besoin de visualiser ce qu'il se passe.

Citation:

---

Envoyé par Pol63

concernant les multiples constructeurs, si tu en écris 2 qui prennent chacun un string visual studio va te dire que tu n'as le droit, car justement il ne pourra pas déterminer lequel doit être utilisé
par contre si tu en fais un qui ne demande rien, un qui demande un string, et un qui demande 2 integer visual studio saura lequel tu appelles selon le nombre et le types des paramètres

---

Génial c'est une info que je n'arrivais pas à trouver !

this désigne l'instance exécutant dans la classe où l'on se trouve
dans mon exemple de form si tu poses 3 boutons tu peux écrire
this.button1 ou this.button2 ou this.button3 etc...


si tu veux un exemple plus gaming
tu as une classe projectile
propriété location de type point
propriété vecteur (pour le déplacement)
une méthode deplacement qui calcule la nouvelle position
une méthode de dessin

ton moteur va faire le tour de toutes les instances de projectiles pour leur dire de se déplacer
donc la méthode déplacement va être appelée sur toutes les instances de projectile avec du code genre
this.location = this.location + this.vecteur
(en général on range plusieurs instances d'objet dans une collection permettant de faire une boucle dessus)
quand un projectile arrive en bout de courses tu le retires de la collection (en c# les objets qui ne sont plus référencés sont détruits automatiquement) et il ne sera plus traité

au passage une autre info liée à la POO, tu peux dans ce cas faire une classe projectile mustinherit (je ne connais pas le terme en c#)
dans la classe de base tu déclares les 2 méthodes citées en mustoverride (je n'ai pas non plus le mot clé c# en tête mais ca veut dire qu'il n'y a pas de code et que les héritiers définissent le code)
à partir de là tu peux faire une classe projectile_deplacement_vecteur et une autre projectile_deplacement_aleatoire
sur la 1ère tu mets les 2 propriétés précédemment citées et sur l'autre rien
chaque classe a sa méthode de calcul et sa méthode de dessin, et le moteur lui ne fait pas la différence, il parcours tous les projectiles pour appeler déplacement (qui ne fera pas forcément la même chose selon le type (et donc la classe) de l'instance)

Code:

---

1 2 3 4 5

class projectile class projectile_vecteur:projectile class projectile_aleat:projectile   list<projectile> _projectiles

---

"this" permet d'utiliser explicitement une propriété de l'instance.

Si tu n'utilises pas "this", alors le programme va tenter d'utiliser en priorité une variable déclarée localement.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

class Personne { public string Nom;   public void Personne(string Nom) { this.Nom = Nom;   // "this.Nom" indique le "Nom" déclaré au niveau de la classe // "Nom" indique le "Nom" passé en paramètre }   public void ChangerNom(string nom) { Nom = nom; // "Nom" indique le "Nom" déclaré au niveau de la classe, puisqu'il n'y en a pas de déclaré en local // "nom" indique le "nom" passé en paramètre }   public void RemplacerNomSansA(string nom) { string Nom = nom.Replace("a", string.Empty); this.Nom = Nom;   // "this.Nom" indique le "Nom" déclaré au niveau de la classe // "Nom" indique le "Nom" déclaré en local // "nom" indique le "nom" passé en paramètre } }

---

On voit donc, dans le premier exemple, qu'en l'absence de "this", on ne pourrait rien faire.

Maintenant, si on regarde de plus près les deux antres exemples : le premier n'utilise pas "this" qui est à priori inutile, puisqu'on n'a pas d'autre variable "Nom" en local (ni en paramètre, ni déclaré localement).
Cependant, si on fait évoluer la fonction comme le dernière exemple, on se retrouve avec :

Code:

---

1 2 3 4 5 6

public void ChangerNom(string nom) { string Nom = nom.replace("a", string.Empty); Nom = nom; }

---

Et là c'est le drame : pas de problème de compilation. Pourtant, ça ne fait pas ce qu'on veut ! Je te laisse comprendre ce qu'il se passe.
Et quand tu auras compris ça, tu comprendras pourquoi il faut toujours préfixer les méthodes, propriétés et attributs d'une classe par "this", si on ne veut pas avoir de surprise lors d'une modification ultérieure du code.

Sinon, pour les différentes méthodes de même nom (constructeur ou non) c'est très simple : la signature doit impérativement être différente, sinon ça compile pas.

Ensuite, le développeur passe simplement les bons paramètres du bon type dans le bon ordre, et le compilateur, en fonction de la signature d'appel, choisi la méthode qui va bien.

Le seul cas un peu étrange, à tester (pas le courage) c'est quand tu as une signature avec le mot clé "params".

Là, c'est plus compliqué, car la signature n'est pas figée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class Personne { public void FaitDesTrucs(params string[] str) { // 1 }   public void FaitDesTrucs(params object[] obj) { // 2 }   public void FaitDesTrucs(string str, params object[] obj) { // 3 }   public void FaitDesTrucs(string str, object obj) { // 4 } }

---

Là, je pense que soit :
- Ça compile pas (j'en doute)
- Le compilateur va choisir la signature qui est la plus proche de l'appelante

Code:

---

1 2 3 4 5 6 7 8 9

p.FaitDesTrucs(); // Là, aucune idée de celle appelée. Ca doit pas compiler, ou alors ça pourrait éventuellement appeler la 2 qui est la plus générique p.FaitDesTrucs("toto"); // En toute logique, la 1 p.FaitDesTrucs(1); // En toute logique, la 2 p.FaitDesTrucs("toto", 1, "titi"); // En toute logique, la 3 p.FaitDesTrucs("toto", 1, 2); // En toute logique, la 3 p.FaitDesTrucs("toto", "tata", "titi"); // En toute logique, la 1 p.FaitDesTrucs("toto", 1); // En toute logique, la 4 p.FaitDesTrucs(1, "toto"); // En toute logique, la 2

---

A vérifier, car j'ai un doute, notamment à cause de la première ligne, je vois pas comment le compilateur peut décider entre la 1 et la 2, à moins qu'il existe une règle précise, mais à ce moment, je ne vois pas comment différencier "params Personne p" et "params Voiture v" qui sont deux types de référence que rien ne permet de priorisé (contrairement à "object" et "string" par exemple, puisque "string" hérite de "object", donc y'a une priorisation possible.

Citation:

---

Envoyé par StringBuilder

Et quand tu auras compris ça, tu comprendras pourquoi il faut toujours préfixer les méthodes, propriétés et attributs d'une classe par "this", si on ne veut pas avoir de surprise lors d'une modification ultérieure du code.

---

Et bien disons que je n'ai pas le "syndrome du semeur de confusion" comme j'aime l'appeler chez le programmeur qui adore nommer tout de la même façon et qui se retrouve à devoir utiliser des "this".
Moi, j'aurais écrit pour ton exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

class Personne { public string QuelNom;   public Personne(string Nom) // tu avais mis un type sur le constructeur alors qu'il n'en faut pas je crois { QuelNom = Nom; Console.WriteLine(Nom); }   public void ChangerNom(string NouveauNom) { QuelNom = NouveauNom; }   public void RemplacerNomSansA(string NomSansA) { QuelNom = NomSansA.Replace("a", string.Empty);   //je ne suis pas sur de ça là parce que je voyais pas l'intéret de ta dernière ligne, ptet parce que je suis un noob en prog   } }

---

Cela me parait plus clair que d'utiliser this avec le même nom utilisé partout.

Au temps pour moi pour le type sur le constructeur, c'est une erreur effectivement.

Sinon, connais-tu le proverbe "L'enfer est pavé de bonnes intentions" ?

C'est une très bonne intention de vouloir différencier le nom des propriétés, attributs, paramètres, variables locales, etc.

Seulement, tu peux être certain que :
- Des règles de nommage trop restrictives sont les plus rapidement abandonnées : par conséquent, on se retrouve avec un code suivant à moitié des règles de nommage, ce qui est incompréhensible
- Au moment de la création (v0.0.1 du programme) quand t'es tout seul au fond de ta cave, t'as tout bien en tête, pas de souci, tu penses à bien différencier les noms des variables. Mais qu'en est-il du gougnafier qui va se pointer derrière toi dans 6 mois ? Non seulement il ne va pas forcément comprendre/suivre tes règles de nommage, mais en plus va pourrir ton code avec des variables ne suivant aucune règle : toi-même, derrière, tu ne sauras dans quel sens prendre le code.
- Une fois que tu auras écrit un bout de code dans une méthode d'une classe donnée, tu seras tenté de faire des copier/coller de quelques lignes dans une autre méthode d'une autre classe. Et là, le drame, si tu as déjà des paramètres et variables déclarées un peu partout.

L'avantage d'utiliser "this", c'est que tu sais, sans te poser la moindre question, d'où vient la variable. Et non seulement tu le sais en lisant son nom, mais en plus tu en es sûr, ce que ne garanti pas une règle de nommage, aussi stricte soit-elle, puisqu'elle n'est pas vérifiée par le compilateur, alors que "this", lui, l'est.

Alors forcément, aujourd'hui, avec des classes de 5 lignes, tu n'en vois aucun intérêt. Mais quand tu auras des classes contenant des dizaines d'attributs, avec des méthodes de plusieurs centaines de lignes, tu regretteras amèrement de ne pas avoir utilisé "this".

En effet, ce que tu dis est compréhensible.
A mon niveau, je t'avoue que this = confusion et que tout mon code à un sens extrêmement plus clair avec un nommage plus explicite.
Ensuite, même si cela changera peut être dans le futur, je ne serais probablement pas amené à coder en équipe mais on ne sait jamais. Je code pour être autonome et réaliser mes concepts pas vraiment par envie.

En fait ce qui me gène avec this, ce n'est pas de savoir d'où vient la variable à laquelle il fait référence, c'est de me retrouver avec des noms de variables qui n'expriment pas le fonctionnement de mon code. Avec this et, comme tu le dis, des centaines de lignes de code, si je reprends mon code des mois après, certes mon programme saura exactement quoi faire mais moi, j'ai le sentiment que je devrais ré-appréhender tout le fonctionnement de ce que j'avais écris au lieu de le lire simplement grâce à l'explicité de ma règle de nommage.

Citation:

---

Envoyé par OurPleasure

1. Est-ce qu'un objet est égal à TOUTE LA CLASSE dont il découle ? Donc en INCLUANT les variables et fonctions hors constructeurs.
   
2. Est-ce qu'un objet est égal à TOUS LES CONSTRUCTEURS de la classe dont il découle ? Donc EXCLUANT les variables et fonctions hors constructeurs.
   
3. Est-ce qu'un objet est égal à UN SEUL DES CONSTRUCTEURS de la classe dont il découle ?

---

Je n'ai peut être pas saisis l'intégralité de ce que tu cherches mais je vais tenter d'expliquer selon ce que j'ai compris de ta demande.

Tu as une classe exemple Véhicule, la classe va être en quelque sorte le patron de l'objet. Tu vas donc définir ta classe avec des attributs en private afin que seuls les fonctions de la classe puissent interagir avec.

Le constructeur de permet d'initialiser une instance de ta classe c est à dire créer un objet. Tu vas donc pouvoir manipuler les données de ton véhicule grâce aux fonctions ce sont donc des méthodes dites d'objets.

par exemple v1 est un objet de Vehicule v1.getPasserVitesse(); Modifiera l'attribut vitesse de ton véhicule.
Tu as des classes static qui elles sont des méthodes de classe. Elle ne modifieront donc pas ton objet mais intéragira avec Vehicule. Vehicule.Fonction() c'est à dire que toutes fonctions qui ne sera pas static sera utilisable par ton objet.

Dans une classe tu peux avoir "plusieurs" constructeurs on appelle sa la surcharge tu peux faire en sorte que ton Véhicule soit créer selon les données qu'il a par exemple

Code:

---

1 2 3 4 5 6 7

public Vehicule(){ this.nom = "unknow"; }   public Vehicule( string nom) { this.nom = nom; }

---

this permettant d'indique que cela concerne l'objet courant.

Ici tu as donc deux façons de construire ton objet.

Citation:

---

Envoyé par OurPleasure

A mon niveau, je t'avoue que this = confusion

---

Quand tu fais de l'objet, quand tu utilises this.nom par exemple tu indiques au programme que c'est le nom de ton objet comme ca si tu prends par exemple un mutateur :

Code:

---

1 2 3 4

public void setNom(string nom) { this.nom = nom; }

---

Pour toi tu es sur que tes variables correspondent bien et si quelqu'un passe derrière il n'y aura pas trop de soucis. Le this permet au compilateur de faire la diffèrence entre l'attribut de ton objet et la valeur fournie. This = objet que tu utilises

Après test de compilation, voici le résultat pour les surcharges avec "params" :

http://i.imgur.com/GoATBIr.png
http://prntscr.com/5scvaf

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks;   namespace TestSurcharge { class Program { static void Main(string[] args) { Personne p = new Personne("test"); p.FaitAutrechose(); p.FaitUnTruc("test1"); p.FaitUnTruc("test1", "test2"); p.FaitUnTruc("test1", "test2", "test3"); p.FaitUnTruc(1); p.FaitUnTruc(1, 2); p.FaitUnTruc(1, "test1"); p.FaitUnTruc(1, "test1", "test2"); p.FaitUnTruc(1, "test1", 2); Console.ReadKey(true); } }   class Personne { public string Nom;   public Personne(string nom) { this.Nom = nom; }   public void FaitUnTruc(params string[] str) { Console.WriteLine("FaitUnTruc(params string[] str)"); }   public void FaitUnTruc(params object[] str) { Console.WriteLine("FaitUnTruc(params object[] str)"); }   public void FaitUnTruc(object str1, params string[] str) { Console.WriteLine("FaitUnTruc(object str1, params string[] str)"); }   public void FaitUnTruc(string str1, string str2) { Console.WriteLine("FaitUnTruc(string str1, string str2)"); }   public void FaitAutrechose(params string[] str) { Console.WriteLine("FaitAutrechose(params string[] str)"); } } }

---

Et un appel à FaitUnTruc() ne compile pas, car appel ambigu.