Gérer les objets avec des classes - Page 5

(je voudrais pas troller, mais les chercheurs sont pas particulierement reputes pour etre de bons codeurs...)

Zerosquare (./117) :
C'est rigolo, l'opposition JackosKing/la plupart des autres participants me rappelle l'opposition chercheur/ingénieur.

Moi elle me rappelle l'opposition casse-couilles/gens normaux.
Et j'inclus KK dans les gens normaux, c'est dire!

Rah ça m’énerve cette dichotomie entre chercheurs et ingénieurs…
Oui certains chercheurs ne sont pas de bons codeurs, mais je peux vous assurer que ce n’est pas le cas dans l’équipe de recherche où je suis actuellement ( http://www.irisa.fr/triskell ). Et quand ils ne sont pas de bons codeurs, c’est simplement parce qu’ils n’ont pas besoin de l’être, leurs activités de recherche ne tournent pas forcément uniquement autour du code, ils réfléchissent à un niveau d’abstraction plus élevé et délèguent le boulot de codage à des ingénieurs justement.

Faut pas oublier que la plupart des technologies que les ingénieurs utilisent, ce sont des chercheurs qui les ont conçues…

C'est pas forcément un défaut de ne pas savoir coder proprement hein, mais ça n'en reste pas moins vrai en général pour moi
J'ai un pote dans mon école d'ingé tu vois tout de suite qu'il est un level au-dessus, il est super bon en algo il pense à des trucs que perso je vais pas aussi loin par contre il code comme un porc. Mais alors c'est peu de le dire (sans parler de ses "µML" comme j'aime à les appeler, sur lesquels il est absolument impossible de distinguer les lettres entres elles: en fait c'est comme s'il écrivait des 'nnnnn' à longueur variable pour moi). En plus il adore jouer avec tout ce qui permet de bypasser l'objet tout en ayant l'air propre (notamment les classes internes et la visibilité sur les membres privés de la classe englobante).

Je vois pas en quoi le fait d'utiliser les classes imbriquées pour accéder aux membres privés de classes englobante est dégueu. Ça a plus ou moins été fait pour ça, et au contraire d'affaiblir les règles d'encapsulation, ça les renforce. (Les classes à l'extérieur ne peuvent toujours pas accéder à ces données, contrairement à tous les autres modèles où pour obtenir le même résultat, tu devrais augmenter la visibilité de tes membres d'une manière ou d'une autre…)

(PS: d'ailleurs c'est un truc dont je me sert très souvent. C'est dommage que la fonctionnalité soit cassée sous C++. En fait c'est un truc qui a été marqué comme interdit sans grande réflexion derrière, mais corrigé depuis, sauf que g++ ne le supporte toujours pas (à moins que ce ne soit MSVC, je sais plus))
[EDIT] Non en fait c'est juste un defect report qui sera corrigé plus tard je me suis trompé
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#494

Moi j’ai remarqué que souvent les traitements qui étaient faits dans les classes internes avaient plutôt leur place dans la classe englobante.

Parce que de toute façon l'objet englobant possède celui qu'il englobe ? J'ai tendance à vouloir faire trop de séparations en créant des objets alors que ça se résume souvent à de bêtes variables initialisées.

./126 > Les classes internes sont pas vraiment faites pour faire des traitements (enfin, c'est au cas par cas après) pour moi non plus, mais plutôt pour exposer de manière plus spécifique les détails du fonctionnement de l'objet englobant.
Tu peux aussi t'en servir pour catégoriser certaines opérations. Par exemple un fictif TextBox.Selection.Erase() au lieu d'un tout aussi fictif TextBox.EraseSelection() qui est quand même moins cool.

J'ai plus d'exemple en tête mais ça permet de faire des trucs vraiment dégueus et pas vraiment réutilisables. D'ailleurs le C# n'a pas jugé bon d'inclure les classes internes au langage, perso j'ai pas eu bcp de peine à comprendre pourquoi ^^
(en étant quand même très déçu)

Classe interne/classe imbriquée c'est la même chose à un détail près. Quasiment tous les langages supportent ça. ; } }En C#:public class Master { public class Slave { private Master master; internal Slave(Master master) { this.master = master; } } public Slave GetSlave() { return new Slave(this)En fait le fait de devoir l'écrire de manière explicite contribue probablement à rendre le code un peu plus propre, et ça ne coûte pas grand chose.

Ah j'avais pas pensé à utiliser ça comme ça, moi je parlais de classe qui instancie une autre classe en tant que membre.

Une deuxième différence que tu as oublié c'est que Master et Slave n'ont pas de visibilité sur les trucs privés de l'un et l'autre avec cette méthode.
Bref la sémantique n'est pas du tout la même (ta méthode c'est plus une histoire de namespace), en particulier quand tu vois les possibilités qu'offrent les classes internes anonymes en Java. Par exemple, le code d'une clôture en C# par ce biais est beaucoup moins évident.

Sisi ils ont une visibilité justement. Je sais quand même un peu de quoi je parle hein.
Le maître n'a pas accès au champs privés de l'esclave (normal, c'est dans une portée différente) mais l'esclave a accès aux champs privés du maitre (normal, sa porté inclut la portée du maitre).
La seule vraie différence c'est que tu dois expliciter le passage de la classe parent. Par contre tu peux lui passer plusieurs parents ou même changer le parent, ça marchera aussi bien l'un que l'autre. (Et évidemment, si tu ne fais rien de cela, c'est juste une classe normale que tu aurais pu déclarer en dehors)
Après pour ce qui est des closure heu, je te laisse regarder ce magnifique bout de code. using System; using System.Collections.Generic; public static class Program { private sealed class NumberRange : IEnumerable<int> { private int n; public NumberRange(int n) { if (n <= 0) throw new ArgumentOutOfRangeException("n"); this.n = n; } public IEnumerator<int> GetEnumerator() { for (int i = 0; i <= n; i++) yield return i; } System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return GetEnumerator(); } // Rétro-compatibilité à la con :( } private static void Main() { var list = new List<int>(new NumberRange(99)); // Liste de nombres de 0 à 99 int max = int.MinValue; list.ForEach(i => { if (i > max) max = i; }); // Oh une closure Console.WriteLine(max); // Oh ça affiche 99 } }(Bon désolé pour tous ces posts, sinon on peur ouvrir un topic « La propagande de GoldenCrystal » si besoin )

Ha j'avais pas compris ça comme ça alors, je pensais que la classe fille n'avait pas de visibilité sur la classe parente, my bad sorry.
Sinon pour les générateurs / yield (c'est ce que ça a l'air d'être, dur de bien voir sur mon téléphone) je connaissais, mais c'est de la triche puisque tu utilises une autre fonctionnalité du langage ^^

Bah, en C++, on peut donner des visibilités à n'importe quelle classe avec friend, pas besoin de les imbriquer, c'est beaucoup plus flexible. De plus, si on veut absolument avoir du Classe1::Classe2, on peut avoir cet effet avec un typedef dans Classe1 même si Classe2 est autonome.

Bah de toutes façon, le fait que l'imbrication soit foireuse ets un défaut reconnu officiellement par ceux qui normalisent le C++, donc bon…
Et puis, le comportement marche comme attendu sous MSVC, c'est juste g++ qui fait chier
Sinon je me souviens avoir eu des emmerdes en utilisant des classes imbriquées en C++. Je crois que c'était qu'on ne pouvait pas déclarer friend une classe imbriquée, mais faudrait que je reteste voir si c'est bien ça. (En tout cas ça concernait ces deux fonctionnalités j'en suis quasi certain).
Sinon, un truc dont tu ne tiens pas compte, c'est qu'une classe imbriquée peut avoir une visibilité privée, contrairement à une classe déclarée à l'extérieur (la visibilité en C++ c'est pas très souple… )

Brunni > L'énumérateur ne me sert que pour initialiser la liste. C'est plus rapide et plus propre que d'écrire var list = new List<int> { 0, 1, 2, […], 98, 99 };

Mouarf friend est le genre de truc qu'il faut absolument eviter. Tout comme mutable...
La notion objet de Kevin me fait peur. ^^

friend n'est en effet pas un ami.

Sinon je donnerai une autre distinction: curieux de comprendre ce qu'il fait et vouloir faire mieux/se contenter du minimum.
Il y a des nuls en recherche et en prog, et des bons des deux côtés aussi.

Bah en même temps, friend est quand même la seule façon de faire coopérer (de manière « privée » ) des classes entre elles en C++. De là à dire que le langage est mal fichu, il n'y a qu'un pas, que je n'hésiterais pas à franchir…
Mais si tu regardes à côté, les modèles de visibilité ne sont pas non plus idéaux, genre internal en C# ou la visibilité par défaut (équivalent de internal) en Java. C'est bien car tu ne partages pas tous tes champs, donc ça limite énormément la casse, mais par contre tu les partage avec toutes les classes qui sont dans le même ensemble (package en java ou assembly en C#)
Ce qui serait utile c'est d'avoir un mix entre les deux (=> pouvoir partager les variables internal avec juste certaines classes), mais je ne sais pas si il y a des langages qui proposent ça.

GoldenCrystal (./139) :
pouvoir partager les variables internal avec juste certaines classes

J'ai pensé que ça manquait aussi, ya pas moyen de faire ça avec de l'héritage multiple ? Mais ça devient vite la merde...