Voila, je poste ce sujet pour vous demander des conseils
Je ne cherche pas à savoir si vous buvez du café ou si vous posez vos pieds sur un(e) pouf(fe) en meme temps. Non, je veux savoir comment vous réagissez pour les cas suivant:
 
nota: je poste le code en C-like mais j'aimerai bien des réponses aussi dans le cas de Java, PHP, XSLT ... enfin n'importe quoi que vous maitrisiez
 
Lorsque vous avez affaire à une pure exécution conditionnelle à savoir que suivant A ou non-A vous ferez deux choses différentes, que préférez vous entre la syntaxe
 

 
et la syntaxe
 

 
 
Pour ce qui est de la programmation objet, je ne sais jamais si pour la classe
 

 
je dois:
1)
Utiliser un getter et un setter privé pour _attributSuperPriveTopSecret, afin de respecter l'encapsulation dans ma classe meme, au risque de l'allourdir et de bourrer la pile des appels.

 
2)
Réutiliser mes setter/getter lorsque je modifie Propriété dans mon code (même problematique plus ou moins)
Par exemple je ferai:

 
Voila, je pense que ce sont des questions un peu betes mais c'est vrai que je ne sais jamais faire mon choix (encore si j'étais dans du pure compilé, je laisserai le boulot au compilo, quitte à lui cracher dessus ensuite, mais quid des languages interprétés ?)  

Pour la première question, il est habituellement conseillé de n'avoir qu'un seul point de sortie par fonction, mais l'essentiel est :
 
 a) que le programme marche comme voulu,
 b) que le programme soit lisible (ce qui implique, entre autres choses, de ne pas choisir des noms qui pourraient prêter à confusion, et donc de ne pas choisir des noms commençant par "_", ne pas choisir des noms qui ressemblent à des mots clés comme "propriete" ).
 
Le reste est secondaire, à mon avis de vieux programmeur.  

j'trouve ca bien de prefixer les membres privés d'un _

Le problème est que cela peut prêter à confusion avec les variables en C qui sont aussi préfixées par un underscore. Mais, ce n'est pas très important (donc pas la peine de se disputer sur ce point avec des smileys rouges).

ah bah ca dépend du langage dans lequel tu développes aussi (:o)

Heu je précise: les noms bidons c'est pour l'exemple, hein
 
C'est vrai que l'unique point de sortie me parait aussi etre une meilleure idée.  
 
Le "_" devant les noms, on me l'a appris comme ca pour les attributs privates (edit: haa je comprend mieux pourquoi il y en a qui suffixent au lieu de préfixer !)
 
Enfin, est ce que le principe du "le principal c'est que le programme marche comme voulu" n'est pas un peu une excuse à un développement peu ou mal réfléchi, justement ?
 
 

C'est juste mon avis, et certains ici sont bien plus experts
 
Pour le premier je préfère un if/else.
 
Pour le second (si j'ai bien compris), pour autant qu'il n'y ait qu'une variable affectée et pas 36, je préfère l'attaquer directement sinon ça alourdit pas mal le code, je trouve ça moins lisible.
Si c'est plus complexe et utilisé pas mal de fois, une méthode viendra remplacer le truc (mais probablement pas juste un getter/setter).
 
Et comme c'est pour une utilisation interne ça n'aura pas de répercussion ailleurs.
 
En python on met des '__' devant pour "priver" (enfin privatiser, privater... ).

 
J'ai bien compris le reste mais cette partie me demeure obscure: pourquoi une classe mal concue n'aurait pas de repercussions en dehors d'elle même ? Je veux dire: les repercussions, dans ce cas précis, elles se comptent en terme de performance, donc si ma classe fait ramer la machine, je vois pas ce que le probleme à d'interne à ma classe.
 
A moins que tu parles d'utilisation uniquement dans mon code, mais alors ca tombe à l'eau puisque je code principalement pour des exercices de cours, et donc en suivant des spécifications que je n'ai pas conçu, puis en subissant un test unitaire auquel je n'ai pas touché (bon, j'avouerai qu'ils ne nous mettent aucun benchmark pour l'instant, mais bon je préfère prendre des bonnes habitudes dès maintenant)

Ca depends du language, mais les getter/setter n'existe que parce que la variable est privé c'est tout et que l'on veut quelle soit visible en public.
 
En interne les utilisé est une hérésie vu qu'on vois l'attribue, autant l'attaquer directement.

C'est pas faux, mais dans certains cas il n'y a pas de visibilité directe sur l'attribut, sans pour autant qu'il soit forcément completement accessible de l'exterieur (exemple: A et B sont visibles et C se calcule par rapport aux deux autres, bien entendu pour que ce soit rigolo il faut s'imaginer qu'on est forcé d'utiliser C quasiment tout le temps)
 
Mais c'est vrai que je pousse peut etre le coté objet là ou il n'a pas vocation à se loger: dans la classe elle même
I'll think about it ...

C'est pas un attribut si ça se calcul a partir de deux attribut.
 
Genre si t'as longueur et largeur, getSurface c'est pas un attribut mais bel et bien une methode d'instance. (au sens strict du terme. )
 
Après y'a des language ou "property" est une notion avec read/write des attribut/fonctions

Le sens strict ? Le sens dépend de la norme et, je suis désolé, mais en UML on parle d'attribut. Attribut calculé, certes...
 
Enfin, disons que je n'ai pas posé correctement les bases de ce que je disais
 
Et donc, pour l'autre attribut (le non calculé), tu es pour l'attaque frontale si j'ai bien compris ?! Mais c'est sur que ca pose jamais de problème (je pense nottament à des projets modularisés à la va vite, ou chacun gère une partie de la classe)? Personne à jamais eu de problème du genre ?

Les bonnes habitudes consistent justement a ne pas se poser de questions de performances avant que le programme ne fonctionne, sauf bien sur celles qui concernent la complexite de ton algorithme (cf. la fameuse phrase "premature optimization is the root of all evil" ).  
Et ne t'inquiete pas pour tes getters/setters un bon compilo ne generera pas un appel de fonction pour si peu.
Quant au return en milieu de fonction ... c'est tres genant quand tu debugges, puisque tu ne sais a priori pas ou/quand tu vas sortir de la fonction, ce qui t'oblige a mettre un point d'arret sur chaque return.  

Le probleme n'est pas le nombre de personnes qui travaillent sur le projet. Le probleme est que n'importe qui, toi y compris, peut l'espace d'un instant, oublier la convention qui regle l'etat interne de ton objet, et par consequent, corrompre l'objet par l'innocente mise a jour d'un attribut.  
Alors que si tu passes par un accesseur ... il peut se charger pour toi de modifier les membres qui dependent de ce que tu es en train de modifier.
L'important est de faire la difference avec les variables membres qui sont des outils avec lesquels tu modelises l'ensemble des etats possibles de ton objet, et les attributs, qui font partie de cet etat.
Enfin bon, ce n'est que mon avis    

 
Mais justement, ce n'est pas une question sur un programme en particulier, c'est un cas de tout les jours, et je ne pense pas que c'est tirer des plans sur la comete que de vouloir prendre de bonnes habitudes
 

 
C'est ce que je me suis dit, mais là MEI et toi n'etes pas du même avis  
En fait, comme on parle du compilo, je me demandais si en Java le compilateur pouvait justement faire ce genre de petites optimisation, ou si en PHP l'interpreteur le faisait également (là ca m'étonnerait mais bon)
 

 
Ca en tout cas, c'est noté, je ne ferai pas de multiples points de sortie pour mes fonctions, promis
 

Sauf si tu veut du code lent, il ne faut jamais faire d'appel de fonction inutile.

Un compilateur n'as pas a transformer un appel a un getter/setter par l'access direct à l'attribut.
 
Ou alors c'est de l'inlining et ça augmente le temps de compilation et la taille de code généré pour rien. (et encore y'a des langages où l'inlining doit être explicite par un mot clef dans la signature de la fonction). Et pour le cas du Java, non un get() c'est un get().
 
Faut arrettez de dire de la merde des fois, dans une classe on access toujours à ses attribut par l'attribut privé.

Et puis donner une même classe à développer à deux personnes en même temps c'est un peu curieux. On peut généralement découper en plusieurs classes dans ce cas.

Hola! Reste poli stp.  
 
Je ne dis pas de la merde, figure toi que je bosse precisemment sur l'etude du code genere par le compilo C++ qu'utilise ma boite, et que je sais tres bien de quoi je parle. Ce compilateur transforme un appel de getter/setter par l'acces direct (dans le cas ou l'accesseur ne fait rien d'autre evidemment).
Si ta fonction n'a pas d'autre interet que de faire "return this->m_Attribute", je ne vois pas comment le fait de remplacer l'appel par un mov peut generer du code plus gros.....  
 
Et pour ton info, les compilos C++ en general ne sont pas tenus de respecter les directives d'inlining.
 
edit : Je precise que je parle pour le cas des langages compiles uniquement.

Ca depends du compilo C++ et de ces options pour l'inlining.
 
Et ça n'empeche qu'utiliser un get au sein de la classe c'est faux et digne d'un neuneux qu'a pas fait d'étude en informatique.
 
(genre le mec qui fait : )

Ma remarque concernait les "sets"  
edit : faut arreter de te reposer sur l'absence de competences des autres pour justifier les tiennes. Ta phrase ne comporte aucune information interessante, sauf le fait que tu snobbes les debutants.

 
Je t'avouerai que je pensais plutot à des projets de cours, du genre vite fait réfléchi par un prof sur un coin de table: "Par équipe de 15 concevez une classe jeu d'echec, vous avez 4 heures" (sisi, on me l'a fait )
 

 
En même temps, c'est un peu le pourquoi de ma question: aucune formation n'est sans défauts, spa ? et mes profs ne m'ont jamais sanctionné ni meme averti lorsque j'utilisais des getter privés. Tu sera gentil de te modérer un peu, parce que je n'ai pas l'impression d'avoir été aggressif et que tu me semble très clairement l'etre
Au fait: effectivement il y a peu, j'aurai fait des erreurs du type de celle que tu viens d'énoncer, et c'est sans doutes grace à mes questions que j'ai appris à les éviter.
 
Bon je pense que le sujet peut être arreté ici, j'ai eu quelques réponses à mes questions.  
 
Je vous remercie d'avoir pris le temps de me répondre.  

Pas de quoi

Dans ces cas c'est plutôt une analyse, un découpage en classes/méthodes etc. ensemble et pas plusieurs personnes qui développent un truc dans leur coin non ?
 
C'est le tableau blanc le plus utile.

Quand on apprends okay on peut faire des erreurs. Mais quand on conseille de faire comme on le sens alors que le bon sens et les regles communes dans l'enseignement sont de n'utiliser les getter/setter qui si on est pas dans le scope public là sa devient limite.
 
Idealement pour un attribut protected, une classe fille devrait egalement utiliser les attribut directement par exemple...

 
C'est censé être ca, encore faut-il avoir quelques projets à son actif ou au moins des notions de travail en groupe.
Pour info, ca a effectivement été un découpage à la dégueu(pas d'analyse, on avait jamais fait d'ACSI, premiere annee oblige) suiv de quelques heures de codages en tentant de ne pas trop se disperser. Le résultat ? A deux avec quelques compétences on faisait un truc mieux en moins de temps.  
Au moins j'aurai appris qu'il peut etre plus utile de poser un probleme et d'y réfléchir tranquillement que de se lancer dans le code les yeux fermés.
 

 
Heu oui, mais je n'ai jamais conseillé quoi que ce soit, j'ai juste tenté de pousser le raisonnement pour voir s'il tenait debout.  
Ensuite heuu je vois pas pourquoi cette reference au principe du protected: je ne me rappelle pas avoir de grosse lacune dans la notion d'héritage.
 
Enfin, je suppose que j'ai posé des questions qui parraissent trop simple, voire simpliste. D'ou le ton condescendant de certaines réponses
 
Bon mais heu maintenant, c'est bon, hein; je crois que j'ai plus ou moins résolu mes probleme tout ca, donc merci encore, fin.

-> Bapho13 : je crois que c'est juste MEI et Ace17 qui papotent parce qu'ils ne sont pas d'accord.
Accède directement aux variables privées, à part si c'est un appel de méthode qui peut évoluer (mais ça n'est plus un accesseur).
 
Edit : Et pour l'exercice, c'est probable que le prof ait voulu vous montrer comme il peut être difficile de partager un projet, et qu'on ne gagne pas toujours du temps à le faire.

Justement, si, ca peut toujours etre un accesseur. Voici un exemple :
 

 
Je passe sous silence le reste de l'implementation, c'est pas le but. Maintenant imaginons que l'implementation change, et que le programmeur de la classe Date decide de stocker le jour non pas sous la forme annee/mois/jour mais annee/jour_dans_l'annee. Evidemment, il ne faut pas que l'interface change!
Ce qui nous fait :
 

 
 
Voila. On remarque plusieurs choses :  
- setDay dans la premiere version est un accesseur meme s'il ne se contente pas uniquement de faire une simple affectation.
- dans la deuxieme version l'interface de Date n'a pas change, mais l'implementation oui. m_Month et m_Day ont disparu ce qui a amene a changer le statut d'accesseur de setDay et getMonth. Cela implique que l'utilisateur de la classe ne doit pas avoir besoin de savoir si la methode qu'il utilise est un accesseur ou pas.
- au cours de ce changement, la methode isItMyBirthday n'a pas eu a etre modifiee. Si elle avait utilise directement les variables privees m_Day et m_Month, il aurait fallu l'adapter. MEI, si tu n'es toujours pas convaincu par cet exemple, j'attends ton argumentation.
 
 

C'est pas au niveau de la classe qu'on veut s'abstraire de l'implementation, mais au niveau des classe qui vont l'utiliser. (c'est là le but des getter/setter).
 
Dans le premier cas si on avait utilisé les champs privé, on aurai du modifier lors du passage vers le deuxieme cas, mais c'est normal et ce qu'on doit faire.
 
Enfin bon en principe on change pas l'implementation d'une classe comme ça de toutes facons.