Création d'un constructeur

Citation:

---

Envoyé par kheironn

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.

---

Sauf qu'en C# on peut transformer un champ en propriété à tout moment sans compromettre la compilation. Autant en C++ il y a de bonnes raisons pour forcer dès le départ l'introduction de getter et setters, quand bien-même ceux-ci seraient triviaux, puisque la syntaxe pour appeler ces méthodes est différente de l'accès à un champ, autant en C# force est de reconnaître que les arguments sont plus minces et c'est souvent un simple choix esthétique. A ce titre, la remarque de StringBuilder à laquelle tu réagissais était justifiée.

Citation:

---

Je t'invite à lire l'article mis en lien sur les antipattern. Il n'est pas question de religion, mais de propreté du code.

---

Si l'on parle du plat de spaghetti, de yagni ou autres, oui. Mais quand je vois le terme antipattern appliqué à tout et n'importe quoi comme le singleton, non, là ce sont des foutaises et on tombe dans la rhétorique religieuse et les arguments bidons.

Par ailleurs tu devrais y réfléchir à deux fois avant de te poser en donneur de leçons. Ma réponse n'appelait pas de critique mais elle t'a poussé à te poser en "professeur de propreté du code".

Citation:

---

Envoyé par sisqo60

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.

---

Surtout qu'il y en a déjà un, que j'ai créé.

Et que kheironn réponds à côté de la plaque, j'ai jamais parlé de code auto-généré. Mais de Propriété auto-implémentée, ce qui est loin d'être la même chose.

Désolé bilou_12 pour le détournement !

Le C# n'est-il pas sensible à l'orthographe et à la casse ? ExpirationDate, ExpirationdDate, expirationdDate et expirationDate c'est pas pareil !
Ah ! je pensais que le C# avait hérité de la rigueur du C++ !
On m'aurait menti :mouarf:

Du coup, depuis le début, j'ai l'impression que ce n'était pas un problème de get\set mais un problème de clavier qui écrit n'importe quoi ! Ah ces claviers quand même !

Un sujet si long juste parce que bilou ne relit pas son code ! Eh ben !

Pour le constructeur,
la pratique Delphi veut qu'un
paramètre comme par A comme argurment, en C#, c'est une minuscule en 1ère lette
F comme Field pour un membre privé d'une classe, en C#, il me semblait que c'était m_ comme en C++
Rien pour une property, en C#, une majuscule en 1ère lettre
enfin T comme Type équivalent du C comme class du C++ !

Delphi n'est pas sensible à la casse, voilà comment un détail syntaxique influence tout la façon de bien écrire son code !

La POO subit le même travers ! Déformée par le langage !

Code:

---

1 2 3 4

constructor TWeb.Create(TDateTime AExpirationDate); begin FExpirationDate := AExpirationDate; end;

---

Code:

---

1 2 3 4

CWeb::CWeb(TDateTime AExpirationDate) : m_ExpirationDate(AExpirationDate) { }

---

Rien ne t'empêche d'avoir ce type de règle, cela peut éviter ce genre de soucis lié à la porté des noms !

D'ailleurs, le fait qu'une propriété doit commencer par une majuscule et un paramètre par une minuscule ne doit pas être un hasard, c'est dans les règles de code C#

Code:

---

1 2 3 4 5 6 7

Use proper casing for members ? Identifier Casing Example Private field Camel listItem Protected field Pascal MainPanel Parameter Camel typeName Type Parameter Pascal TView Property Pascal BackColor

---

Pour le Hors Sujet :

Un débat à troller :mur:

Tout ça ce n'est qu'une question de langage et de facilité syntaxique !

Voici, ce que cela donne en Delphi puisque ce langage a été cité !

Citation:

---

Envoyé par kheironn

Ces derniers sont regroupés en propriétés en .Net (ce n'est pas le cas dans tous les langage POO (Delphi, java(il me semble), etc.)

---

Euh, En Delphi\C++Builder ça fait plus de 15 ans que l'on utilise le terme property !
Ne pas oublier que le .NET a été conçu par le concepteur du Delphi ! Ce n'est pas un hasard !
property c'est aussi une extension MSC++ et standard de Visual Basic ! C'est un concept finalement très MS, de toute façon Borland et MS ont passé 10 ans à se copier mutuellement !
Les deux ayant fait leur propre vision de la POO !

En fait, le terme Propriété c'est pas un terme POO mais Accesseurs l'est !

Perso, je ne mets en publique uniquement des property !
Par habitude et que 100% du Framework Delphi est écrit ainsi ! je fais pareil par pur mimétisme ! Après tout, quand tu es à Rome, fait comme les Romains
Et puis à l'école, on t'apprend qu'il faut protéger l'intégrité des données au sein d'un objet par des accesseurs !

En Delphi, on a deux façon, tient un extrait de mon code actuel :
__property TPollingEvent OnPolling = {read=FOnPolling, write=FOnPolling};.

C'est un accès direct à FOnPolling, c'est juste encaspuler.
En Delphi ou C++Builder, ce n'est pas implicite, on DOIT créer notre membre privé ou protégé FOnPolling (quelques parts ailleurs dans la classe)

En terme de perf, c'est directement l'utilisation de la référence (qui d'ailleurs peut amener des failles en C++Builder avec des objets à allocation statique et leur opérateurs)
Cela empêche d'utiliser la variable par pointeur (oui oui, je sais) et donc force une utilisation plus propre qu'un membre publique

En Delphi, les RTTI (Reflexion) n'existent que pour les property (published)
L'exemple ci-dessus c'est typiquement pour un évènement, TPollingEvent étant un pointeur de méthode, de plus la propriété publiée que l'on peut définir dans le Screen Designer (le clicodrome)

Demain, je pourrais vouloir effectuer un contrôle à l'affectation

__property TPollingEvent OnPolling = {read=GetOnPolling, write=FOnPolling};.
GetOnPolling est une fonction, on peut faire aussi une SetOnPolling ... ou pas mettre de write pour un read-only !

Effectivement, toujours ce problème de l'AntiPatten "Ancre de bateau", je prépare le terrain pour plus tard !
La POO sans Pattern, cela peut devenir n'importe quoi !
La POO est moyen, les Design Pattenrs c'est des méthodes pour bien utiliser la POO !
Sinon le singleton, c'est une Pattern de Base ! Elle n'est en rien proscrite ! Faut pas non plus raconter n'importe quoi !

Mais, il y a peut-être des limites à l'extrémisme dogmatique de la POO !
Bon, même si je trouve que ce "{get;set;}" cela fait un peu option pour flémard !

Après comme le dit BenoitM, c'est toujours le problème de l'analyse, de la modélisation, ...
Perso, je code selon la météo, je n'ai pas fait d'UML depuis les cours, même si j'ai appris le MERISE !
Dans les 6 boites que j'ai traversé, c'est des specs écrites sur un coin table et encore, si elles sont écrites c'est déjà un exploit
Pendant 5 ans, j'ai utilisé Mantis comme bug tracker mais aussi pour la gestion de spec, même si ça tient en "modifier l'écran bidule et faire ça sur le bouton machin", on moins on sait qu'on l'a fait, même si il n'y a pas plus de détail !
Je dirais que coder à l'arrache, en urgence, la veille de la livraison, c'est un classique ! En puis, la documentation, elle fini toujours pas être fausse parce que personne ne l'a maintient ... le commercial, il n'en a rien à battre de la doc technique, il n'y a rien à vendre !

En fait, ce qu'il vous manque StringBuilder et kheironn pour vous mettre d'accord, c'est une déclaration intermédiaire anticipant le développement en spirale
... je voulais dire en "Itération" comme dirait un programmeur agile

Code:

---

1 2 3

// Propriétés public int propriete1 { get;set; {private int _backfield1} }

---

C'est l'éternelle différence entre la pratique et la théorie !
En Théorie, on modélise
En Pratique, on fait comme on peut !

Citation:

---

Envoyé par BenoitM

Mais la réflexion doit se faire a chaque fois : Est-il utile ou non de passer par le backfield à ce moment si...
Je pense que même a l'interieur d'une classe, tu dois utiliser le moins possible le backfield...

---

:plusser:

Citation:

---

Envoyé par ShaiLeTroll

Code:

---

1 2 3

// Propriétés public int propriete1 { get;set; {private int _backfield1} }

---

---

Ça reprend effectivement de façon plus simple ce que j'avais imaginé avec la structure que je proposais.

Bon, je pense que le débat est clos :ccool: