Création d'un constructeur

Bonjour,

Je cherche à créer un constructeur. Je suis les tutoriels mis à la disposition des débutants mais j'ai encore un pb... :aie:

Pouvez-vous me dire qu'est ce qu'il ne va pas dans le code ci-dessous sachant que this.ExpirationDate = expirationDate; est souligné en rouge...

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Web:Account { //Propriété public DateTime ExpirationdDate { get; set; }     //Constructeur public Web(DateTime expirationdDate); this.ExpirationDate = expirationDate;   }

---

Merci d'avance! :ccool:

Bonjour,

je te conseilles de lire un tutoriel sur les bases de la programmation orienté objet (POO). Tu en trouveras sur ce site.

Aussi non pour répondre à ta question :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Web:Account { //Propriété public DateTime ExpirationdDate { get; set; }     //Constructeur public Web(DateTime expirationdDate) { ExpirationDate = expirationDate; }   }

---

et en plus "propre" :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class Web : Account { private DateTime _expirationDate;   public DateTime ExpirationdDate { get { return _expirationDate; } set { _expirationDate = value; } }   public Web(DateTime expirationDate) { ExpirationdDate = expirationDate; }   }

---

Merci! :merci:

J'y suis en plein dans les tuto 8O

C'est normal que ça me souligne encore en rouge? :cry:

Autant pour moi pour la première version, je n'avais pas fait attention

tu passes une variable nommée expirationdDate dans ton constructeur, et tu utilise expirationDate dans ton constructeur, tu as tout simplement un d en trop dans le passage de paramètre.


Voici le code correct :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Web:Account { //Propriété public DateTime ExpirationdDate { get; set; }     //Constructeur public Web(DateTime expirationDate) { ExpirationDate = expirationDate; }   }

---

Bonjour,

c'est quoi ta classe Account?
ça reste souligné en rouge, ça veut rien dire...
C'est quoi l'erreur affichée à la compilation?

PS : Aeronia les codes suivants sont équivalents:

Code:

---

public DateTime ExpirationdDate { get; set; }

---

Code:

---

1 2 3 4 5 6 7

private DateTime _expirationDate;   public DateTime ExpirationdDate { get { return _expirationDate; } set { _expirationDate = value; } }

---

Super! Merci de votre patience! :)

Citation:

---

Envoyé par sisqo60

Bonjour,

c'est quoi ta classe Account?
ça reste souligné en rouge, ça veut rien dire...
C'est quoi l'erreur affichée à la compilation?

PS : Aeronia les codes suivants sont équivalents:

Code:

---

public DateTime ExpirationdDate { get; set; }

---

Code:

---

1 2 3 4 5 6 7

private DateTime _expirationDate;   public DateTime ExpirationdDate { get { return _expirationDate; } set { _expirationDate = value; } }

---

---

Ca revient à la même chose oui sauf que je trouve que c'est un meilleur réflexe à avoir dans le cas ou tu as des accesseurs particuliers.

Autant utiliser la même philosophie dans toutes les classes et pour toutes les propriétés.

+1, je ne vois pas l'intérêt des get/set sans corps.
=> Si un jour il doit y avoir un corps, on a autant de boulot que si on n'a pas utilisé de propriété, donc l'intérêt me semble très compromis...

Citation:

---

Envoyé par StringBuilder

+1, je ne vois pas l'intérêt des get/set sans corps.
=> Si un jour il doit y avoir un corps, on a autant de boulot que si on n'a pas utilisé de propriété, donc l'intérêt me semble très compromis...

---

Code:

---

1 2 3 4 5 6 7

private DateTime _expirationDate;   public DateTime ExpirationDate { get { return _expirationDate; } set { _expirationDate = value; } }

---

ne présente pas d'intérêt car il donne la même chose que

Code:

---

public DateTime ExpirationdDate { get; set; }

---

Ce dernier est juste une facilité syntaxique.
J'imagine que tu fais Int32 et pas int, que tu n'utilises aucune expression lambda tu fais des méthodes anonymes, etc..

L'intérêt est la rapidité , quand tu crées un petit projet ou quand tu donnes un exemple et que tu veux quand même avoir des Propriétés plutôt que l'accès direct aux champs

Personnellement je ne l'utilise pas très souvent dans de vrai projet


ps: et quand tu dois changer le nom d'une propriété tu n'as que elle a changer sinon tu dois changer le nom de la propriété et du Field. Vive les fautes d'orthographe dans le nom d’une propriété :p

Citation:

---

Envoyé par StringBuilder

+1, je ne vois pas l'intérêt des get/set sans corps.
=> Si un jour il doit y avoir un corps, on a autant de boulot que si on n'a pas utilisé de propriété, donc l'intérêt me semble très compromis...

---

Donc il ne sert à rien de s'économiser du boulot qu'on n'a pas besoin de faire parce qu'il se pourrait, peut-être, qu'un jour on ait à le faire ? :aie:

Accessoirement cela rend le code plus concis et plus clair : on distingue tout de suite les propriétés simples des propriétés plus complexes.

Au pire :

Code:

---

1 2	public int propriete1 {get;set;}

---

S'écrait aussi bien :

Code:

---

1 2 3 4 5 6

// Propriétés public int propriete1 { get { return _backfield1; } set { _backfiekd1 = value } }   // BackFields private int _backfield1;

---

Je trouve pas que la seconde syntaxe soit moins lisible. Certes, ça fait quelques lignes de plus mais bon... au moins si demain j'ai un corps à ma propriété, le code est déjà près à l'emploi...

Citation:

---

Envoyé par StringBuilder

[...]au moins si demain j'ai un corps à ma propriété, le code est déjà près à l'emploi...

---

Ca s'appelle un Antipattern !
Donc FAUTE de conception de code. Ce que tu dis va à l'encontre du principe YAGNI.
On ne fais pas du code parce qu'on aura un jour à la modifier, on le fait pour des besoins actuels.
Rien ne t'empêche par contre de faire un découpage qui te permet la ré-utilisabilité.

Si je suis ton architecte et que je vois ce genre de chose, je te pourri comme c'est pas possible !

Ben c'est toute la conception POO qui ne te convient pas alors...

Parce que sans entrer dans une énumération, pour ne reprendre que l'exemple des champs vs propriétés, ma seule raison pour laquelle il est préconisé d'utiliser des propriétés plutôt que des champs publics, c'est parce que "peut-être un jour" on aura besoin de faire des contrôles/traitements dans les accesseurs.

Aussi, cette syntaxe n'existe que depuis C# 3.0
=> Donc avant cette version, il fallait s'interdire de suivre les recommandations POO sous prétexte que c'était anti-chais-pas-quoi ?

Citation:

---

Envoyé par kheironn

Si je suis ton architecte et que je vois ce genre de chose, je te pourri comme c'est pas possible !

---

Si je tombe sur un supérieur qui veut me "pourrir" au lieu de me faire des remarques constructives, je pars chercher un autre job, le travail ne manque pas. ;)

Pour le reste, je suis d'accord avec toi, Yagni est un bon principe. Par contre je hais le mot "antipattern", trop souvent utilisé pour proscrire au nom de raisons religieuses des choses qui ont leur intérêt (singleton, variables statiques, etc).

Citation:

---

Envoyé par StringBuilder

Parce que sans entrer dans une énumération, pour ne reprendre que l'exemple des champs vs propriétés, ma seule raison pour laquelle il est préconisé d'utiliser des propriétés plutôt que des champs publics, c'est parce que "peut-être un jour" on aura besoin de faire des contrôles/traitements dans les accesseurs.

---

FAUX ! C'est au non de l'encapsulation des données (=variables) qu'il y a des interfaces de valeur. La POO préconise de ne pas rendre accessible des variables et de les faire modifier par des traitements (procédure et fonction), si je C#ise des méthodes.
Au final on ajoute des accesseurs et mutateurs qui te permettent de manipuler des variables en ayant la possibilité d'y inclure un code de contrôle ; d'où les corps de get/set. Ces derniers sont regroupés en propriétés en .Net (ce n'est pas le cas dans tous les langage POO (Delphi (il me semble), java, etc.)

Maintenant il faut savoir que le 3.0 ne fait qu'AJOUTER UNE FACILITATION SYNTAXIQUE. Le compilateur génère le MEME CODE IL à partir de ces deux versions.

La question est donc de ne pas écrire des lignes qui ne servent à rien. ton get/set ne faisant rien, inutile d'alourdir le code. Le moment venu, on ajoutera le code de contrôle (ça ne prendra pas plus de temps que d'effacer celui qui existe d'éjà !)


@DonQuiche. Je t'invite à lire l'article mis en lien sur les antipattern. Il n'est pas question de religion, mais de propreté du code. Faire un plat de nouille avec de l'héritage d'implémentation et la réinvention de la roue carrée n'est pas une bonne chose.
Faire un beau code facile à maintenir n'est pas une honte, il faut juste se déchirer un peu plus au moment de sa réalisation, ne pas coder à la vas-vite, comme un porc. J'ai fais des bouts de code en 2 semaines alors qu'il m'aurait fallu 3 jours en mode porc. Par contre, en cout de maintenance et évolutivité c'était 100% de gain de temps. Donc, à la longue on y gagne.
J'applique la rigueur que j'attends des autres à mon propre travail ;). dernièrement j'ai fait un code de porc que je ne voyais pas comment améliorer et je n'ai pas hésité à demander comment l'améliorer :mouarf:

Citation:

---

Envoyé par kheironn

Maintenant il faut savoir que le 3.0 ne fait qu'AJOUTER UNE FACILITATION SYNTAXIQUE. Le compilateur génère le MEME CODE IL à partir de ces deux versions.

La question est donc de ne pas écrire des lignes qui ne servent à rien. ton get/set ne faisant rien, inutile d'alourdir le code. Le moment venu, on ajoutera le code de contrôle (ça ne prendra pas plus de temps que d'effacer celui qui existe d'éjà !)

---

Tu oublies tout de même que parfois (ça m'est déjà arrivé en tout cas), ton get/set peut modifier la valeur du backfield lors de leur accès.
Dans d'autres projets, le contrôle de validité de la valeur sera très lourd (requête dans une base de données, accès à un fichier réseau, etc.)

Ainsi, dans les méthodes de ta classe, si tu ne veux pas modifier la valeur, ou perdre de temps à vérifier inutilement une variable, alors il faut travailler directement sur le backfield.

Faire une propriété auto-implémentée n'apportera absolument rien en terme de gain de maintenance, au contraire, puisqu'il faudra se re-pallucher toutes les méthodes de la classe pour déterminer si oui ou non on doit utiliser le backfield ou la propriété.

Donc à ce moment, je trouve tout de même plus propre et plus évolutif de créer manuellement un backfield dès le début, et l'utiliser dans les méthodes où on est certain qu'aucune modification ne sera toléré ou qu'aucune vérification n'est nécessaire.

Imagine une classe "produit".

On décide au bout d'un moment, afin de simplifier certains traitements de :

- Dans le set de "Code", si le code n'existe pas en base de données, on crée un enregistrement dans la base.
- Dans le get de "Code", on charge dans les champs de l'objet tous les champs de la base de données correspondant au code.

Si je suis dans une méthode qui va faire des modifications dans des champs, et que j'ai besoin de relire le code produit (pour chercher dans une table de correspondance) j'ai l'air malin si le get vient m'écraser tout ce que j'ai déjà modifié par exemple.
Donc travailler dès le départ avec un backfield m'évitera de modifier mes traitements si je modifie les accesseurs de ma propriété.

En revanche, j'ai eu d'autres arguments en faveur des propriétés auto-implémentées dans l'autre topic dédié à ce sujet que j'ai créé hier. Mais je persiste et signe sur ce point : pour ce cas que vous me décrivez, ça n'apporte absolument rien du tout, peut-être même au contraire, certain d'avoir un truc "propre et évolutif", on va peut-être oublié de faire le tour des méthodes de la classe, et passer à côté de bugs potentiels.

Citation:

---

Envoyé par StringBuilder

On décide au bout d'un moment, afin de simplifier certains traitements de :

- Dans le set de "Code", si le code n'existe pas en base de données, on crée un enregistrement dans la base.
- Dans le get de "Code", on charge dans les champs de l'objet tous les champs de la base de données correspondant au code.

---

Euh c'est surtout que c'est mal designé :roll:
Tu crée une methode Save() et non sauvegarder quand tu changes un champ 8O

On pourrait prétexté que quand tu fais le set du champ tu n'aurai peut-être pas besoin de lancer la vérification (exemple un clone d'un objet). Mais la réflexion doit se faire a chaque fois : Est-il utile ou non de passer par le backfield à ce moment si
Que tu utilises des property définies normalement ou auto-implémentées le problème reste le même

Par exemple tu peux donner l'exemple inverse ou tu aurais utilisé un backfield et donc fait tout un traitement alors que la donnée n'est pas correcte mais vu que tu utilises le backfield et non la propriété tu ne t'en ai pas appercu.

Je pense que même a l'interieur d'une classe, tu dois utiliser le moins possible le backfield. Un Check supplémentaire ne doit pas tellement couter en temps tandis qu'une donnée invalide peut poser problème.

StringBuilder, tu connais les snippets ?
il y en a un qui génère ton code avec get et set déclaré, donc quand tu me parle de code auto-généré, ça me fait doucement rigoler.

BenoitM, tout à fait d'accord avec toi utiliser la variable privée dans la classe peut être une source d'erreur. même dans la classe j'utilise la prop.

salut les gars,

C'était pas le sujet de sa discussion. Si vous voulez en discuter, pourquoi par ouvrir un nouveau fil ;)
Je pensais pas que ma petite remarque devienne un sujet de polémique.

Cependant c'est intéressant de voir vos points de vue.